Is Lingo Safe? Smart Contract Security Analysis

Security Findings

1 High2 Med1 Low1 Info

High

Centralized Control by DEFAULT_ADMIN_ROLE

H-01The `DEFAULT_ADMIN_ROLE` has extensive power, including setting critical addresses (`treasuryWallet`, `vestingContract`), managing transfer fees, and granting/revoking all custom roles (`MINTER_ROLE`, `INTERNAL_ROLE`, `EXTERNAL_ROLE`). This centralizes significant control, posing a single point of failure or compromise risk. A malicious or compromised admin key could lead to unauthorized minting (by granting MINTER_ROLE), redirection of fees, or disruption of token operations.

IssueThe `DEFAULT_ADMIN_ROLE` has extensive power, including setting critical addresses (`treasuryWallet`, `vestingContract`), managing transfer fees, and granting/revoking all custom roles (`MINTER_ROLE`, `INTERNAL_ROLE`, `EXTERNAL_ROLE`). This centralizes significant control, posing a single point of failure or compromise risk. A malicious or compromised admin key could lead to unauthorized minting (by granting MINTER_ROLE), redirection of fees, or disruption of token operations.

FixImplement a multi-signature wallet (e.g., Gnosis Safe) for the `DEFAULT_ADMIN_ROLE` to require multiple approvals for critical operations. For highly sensitive actions, consider adding a time-lock mechanism to allow for community review or emergency intervention.

StatusUnresolved

Medium

Gas Limit Risk for Bulk Role Management Functions

M-01The `addInternalAccess`, `addExternalAccess`, and `revokeAccess` functions iterate through an array of addresses to grant or revoke roles. If these arrays become very large, the transaction could exceed the block gas limit, rendering the functions unusable for bulk operations. This could hinder administrative efficiency and potentially lead to a denial of service for role management if a large number of addresses need to be processed simultaneously.

IssueThe `addInternalAccess`, `addExternalAccess`, and `revokeAccess` functions iterate through an array of addresses to grant or revoke roles. If these arrays become very large, the transaction could exceed the block gas limit, rendering the functions unusable for bulk operations. This could hinder administrative efficiency and potentially lead to a denial of service for role management if a large number of addresses need to be processed simultaneously.

FixImplement pagination or batching for these functions, allowing the admin to process addresses in smaller, gas-efficient chunks. Alternatively, ensure that the number of addresses processed in a single transaction is kept within practical gas limits, and document this limitation clearly.

StatusUnresolved

Medium

Irreversible Vesting Contract Assignment

M-02The `setVestingContractAddress` function can only be called once, as it reverts if `vestingContract` is not `address(0)`. While this prevents accidental re-assignment, it also means that if the initially set vesting contract becomes compromised, defunct, or needs to be replaced for legitimate reasons (e.g., contract upgrade), it cannot be updated. This introduces operational rigidity and potential long-term issues if the initial vesting contract becomes unsuitable.

IssueThe `setVestingContractAddress` function can only be called once, as it reverts if `vestingContract` is not `address(0)`. While this prevents accidental re-assignment, it also means that if the initially set vesting contract becomes compromised, defunct, or needs to be replaced for legitimate reasons (e.g., contract upgrade), it cannot be updated. This introduces operational rigidity and potential long-term issues if the initial vesting contract becomes unsuitable.

FixConsider adding a mechanism for the `DEFAULT_ADMIN_ROLE` (perhaps with a time-lock or multi-sig confirmation) to update the `vestingContract` address. Alternatively, implement a separate function to revoke the `MINTER_ROLE` from a compromised vesting contract and assign it to a new, approved one, allowing for flexibility without direct re-assignment of the `vestingContract` state variable.

StatusUnresolved

Low

Limited Role Revocation Granularity

L-01The `revokeAccess` function revokes *both* `INTERNAL_ROLE` and `EXTERNAL_ROLE` for a given address. There is no separate function to revoke only one of these roles. This might limit flexibility if an address needs to retain one role but lose another, requiring a more complex workaround (e.g., revoking both then re-granting the desired role).

IssueThe `revokeAccess` function revokes *both* `INTERNAL_ROLE` and `EXTERNAL_ROLE` for a given address. There is no separate function to revoke only one of these roles. This might limit flexibility if an address needs to retain one role but lose another, requiring a more complex workaround (e.g., revoking both then re-granting the desired role).

FixIf finer-grained control over role revocation is desired, consider implementing separate `revokeInternalAccess` and `revokeExternalAccess` functions. This would provide administrators with more precise control over access permissions.

StatusUnresolved

Info

Initial Supply Minted to Deployer

I-01The constructor mints `_initialSupply` directly to `_msgSender()`, which is the contract deployer. Depending on the `_initialSupply` value, this could result in the deployer holding a significant portion of the token's initial circulating supply. While not a vulnerability, this design choice impacts token distribution and decentralization from the outset.

IssueThe constructor mints `_initialSupply` directly to `_msgSender()`, which is the contract deployer. Depending on the `_initialSupply` value, this could result in the deployer holding a significant portion of the token's initial circulating supply. While not a vulnerability, this design choice impacts token distribution and decentralization from the outset.

FixEnsure the initial supply distribution aligns with the project's tokenomics and decentralization goals. For future deployments, consider distributing the initial supply to multiple addresses, a timelock contract, or a vesting contract directly from the constructor to promote broader distribution.

StatusUnresolved

Category Ratings

TechnicalMedium6/10

The contract leverages OpenZeppelin's battle-tested `ERC20Burnable` and `AccessControl` libraries, enhancing code security and adherence to standards (7.2 Code Security). Solidity 0.8.20 mitigates common integer overflow/underflow risks. However, the centralized `DEFAULT_ADMIN_ROLE` presents a single point of failure for critical operations (7.3 Access Control). Additionally, role management functions using array iteration could face gas limit issues for large inputs (7.2 Code Security).

GovernanceHigh1/10

The tokenomics include a configurable transfer fee directed to a `treasuryWallet`, with exemptions for `INTERNAL_ROLE` and `EXTERNAL_ROLE` addresses, providing flexibility for ecosystem operations (7.4 Economic). The `MINTER_ROLE` is assigned to a `vestingContract` with specific minting limits, ensuring controlled supply expansion. However, the `DEFAULT_ADMIN_ROLE` holds significant power over critical parameters and roles, centralizing economic control and posing a single point of failure (7.5 Governance).

UpgradesHigh3/10

The `LingoToken` contract is deployed as a standard, non-upgradeable implementation. This design choice eliminates the complexities and potential risks associated with proxy patterns, such as storage collisions or upgrade path vulnerabilities. However, it means that any future bug fixes, feature enhancements, or parameter changes would require a complete redeployment and migration of token holders (7.7 Upgrades).

Security Checklist

2/5 checks passed

Contract VerifiedPass

Ownership RenouncedFail

No Mint FunctionFail

Liquidity LockedFail

Not a ProxyPass

HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

88.8% in top 10

16.0% in wallets72.8% in contracts

Effective Concentration45.1%

Share held by contracts — treasury, vesting, bridge or staking — is discounted against share held by wallets when the score is computed: a contract cannot decide to sell the way an anonymous holder can, though it can still be drained or voted to sell. Effective concentration is the figure the risk score is actually calculated from.

Liquidity Depth

$117.7K across 2 pairs

Uniswap v3WETHanalysed$117.7K Uniswap v2WETH$33

The risk score reads depth across every pair. The volume figure and the volume-to-liquidity ratio elsewhere on this page describe only the pair this audit analysed, so the two are not directly comparable.

LP Distribution

Top-1 Unlocked Holder99.4%

Top-3 Unlocked100.0%

Key Addresses

7 addresses

Deployer

0xc588…0e2a

Unlocked LP Held By

0x6f58…36560x6dd9…b00d0x6a22…72280x9dbf…62140xc03c…3c230xb14d…adb9

No privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.

What Raised This Score

9 factors

Ownership NOT renounced (admin/mint authority retained)
Mintable supply — no cap found, dilution unbounded
Top-10 concentration > 30% (88.8% total → 45.1% effective; 16.0% in EOAs, 72.8% in contracts — moderate)
Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
LP top1 unlocked holder = 99.4% (independent LP — depth risk)
LP top3 unlocked holders = 100.0% (independent LP — depth risk)
1 High finding(s) from audit
2 Medium finding(s) from audit
1 Low finding(s) from audit

Each factor is an on-chain fact recorded at the time of this analysis. The score is computed from them by a deterministic function, so the same contract returns the same score for anyone who runs the audit. How scores are computed

Not Signed In

Is Lingo Safe?

Security Findings

Centralized Control by DEFAULT_ADMIN_ROLE

Gas Limit Risk for Bulk Role Management Functions

Irreversible Vesting Contract Assignment

Limited Role Revocation Granularity

Initial Supply Minted to Deployer

Category Ratings

Security Checklist

Holder Composition

Liquidity Depth

LP Distribution

Key Addresses

What Raised This Score

Related Audits

Would You Like a More Detailed Audit of Lingo?