Quantum Audit Logo

Is Autonolas Safe?

On-chain security analysis — is it a scam or legit?

Is this your token? Publish your own audit on this page →

Autonolas OLAS
0x0001…5cb0
Ethereum Not verifiedLast checked 2d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Critical Risk
Executive SummaryAI Copilot

The OLAS token contract is an ERC20 implementation with custom minting and inflation control. It features a centralized owner and minter role. Key technical issues include an underflow vulnerability in `decreaseAllowance`, a potential long-term denial-of-service in the `inflationRemainder` function due to an unbounded loop, and an overflow vulnerability in `increaseAllowance`. The contract's economic model relies on a centralized minting authority and a specific inflation schedule.

1 Critical2 High1 Medium1 Low
Volume 24h
$12.5K
Liquidity
$1.33M
Price
$0.02521
Token Age
3y
Top 10 Holders
75.9%

Security Findings

1 Crit2 High1 Med1 Low
Critical

Underflow Vulnerability in `decreaseAllowance`

C-01The `decreaseAllowance` function does not check if `spenderAllowance` is greater than or equal to `amount` before performing the subtraction `spenderAllowance -= amount;`. If `amount` is greater than the current `spenderAllowance`, the subtraction will result in an underflow, causing `spenderAllowance` to wrap around to a very large value (e.g., `type(uint256).max - (amount - spenderAllowance)`). This allows a malicious user or an attacker to effectively grant themselves an arbitrarily large allowance by calling `decreaseAllowance` with an `amount` larger than the current allowance.
IssueThe `decreaseAllowance` function does not check if `spenderAllowance` is greater than or equal to `amount` before performing the subtraction `spenderAllowance -= amount;`. If `amount` is greater than the current `spenderAllowance`, the subtraction will result in an underflow, causing `spenderAllowance` to wrap around to a very large value (e.g., `type(uint256).max - (amount - spenderAllowance)`). This allows a malicious user or an attacker to effectively grant themselves an arbitrarily large allowance by calling `decreaseAllowance` with an `amount` larger than the current allowance.
FixAdd a require statement to ensure `spenderAllowance >= amount` before performing the subtraction. Alternatively, use OpenZeppelin's `SafeMath` or Solidity 0.8+ default checked arithmetic, but explicitly ensure the condition is met for `decreaseAllowance`'s logic.
StatusUnresolved
High

Centralized Control of Token Minting and Ownership

H-01The contract design grants significant centralized control to the `owner` and `minter` addresses. The `owner` can change both the `owner` and `minter` roles, and the `minter` has the sole authority to mint new tokens, subject only to the internal inflation control mechanism. This creates a single point of failure and a high trust assumption in these privileged addresses. A compromise of the `owner` or `minter` private key could lead to unauthorized token minting or loss of control over the contract.
IssueThe contract design grants significant centralized control to the `owner` and `minter` addresses. The `owner` can change both the `owner` and `minter` roles, and the `minter` has the sole authority to mint new tokens, subject only to the internal inflation control mechanism. This creates a single point of failure and a high trust assumption in these privileged addresses. A compromise of the `owner` or `minter` private key could lead to unauthorized token minting or loss of control over the contract.
FixConsider implementing a multi-signature wallet (e.g., Gnosis Safe) for the `owner` and `minter` roles to distribute control and reduce the risk associated with a single compromised key. For future iterations, explore decentralized governance mechanisms for critical functions like changing roles or adjusting inflation parameters.
StatusUnresolved
High

Potential Denial-of-Service in `inflationRemainder` Due to Unbounded Loop

H-02The `inflationRemainder` function contains a `for` loop that iterates `numYears - 9` times if `numYears` is greater than 9. The `numYears` variable is derived from `(block.timestamp - timeLaunch) / oneYear`, meaning it will continuously increase as time passes. If the contract remains active for many decades or centuries, `numYears` could become very large, causing the loop to consume an excessive amount of gas. This could eventually lead to the `mint` function (which calls `inflationControl`, which in turn calls `inflationRemainder`) exceeding the block gas limit, rendering minting operations permanently unusable.
IssueThe `inflationRemainder` function contains a `for` loop that iterates `numYears - 9` times if `numYears` is greater than 9. The `numYears` variable is derived from `(block.timestamp - timeLaunch) / oneYear`, meaning it will continuously increase as time passes. If the contract remains active for many decades or centuries, `numYears` could become very large, causing the loop to consume an excessive amount of gas. This could eventually lead to the `mint` function (which calls `inflationControl`, which in turn calls `inflationRemainder`) exceeding the block gas limit, rendering minting operations permanently unusable.
FixRedesign the `inflationRemainder` calculation to avoid a linear loop over time. This can be achieved by using a closed-form mathematical formula for compound interest or by capping the maximum number of iterations for the loop. For example, pre-calculate the `supplyCap` for a very distant future year and use that as a maximum, or implement a more efficient logarithmic calculation if possible.
StatusUnresolved
Medium

Overflow Vulnerability in `increaseAllowance`

M-01The `increaseAllowance` function performs `spenderAllowance += amount;` without checking for potential overflow. If the sum of `spenderAllowance` and `amount` exceeds `type(uint256).max`, the value will wrap around to a very small number (close to zero). While less critical than an underflow, this unexpected behavior could lead to an allowance being set much lower than intended, causing operational issues for users or integrated protocols.
IssueThe `increaseAllowance` function performs `spenderAllowance += amount;` without checking for potential overflow. If the sum of `spenderAllowance` and `amount` exceeds `type(uint256).max`, the value will wrap around to a very small number (close to zero). While less critical than an underflow, this unexpected behavior could lead to an allowance being set much lower than intended, causing operational issues for users or integrated protocols.
FixWhile Solidity 0.8+ provides default checked arithmetic, it's good practice to be explicit about expected behavior. Ensure that the sum `spenderAllowance + amount` does not exceed `type(uint256).max`. If `spenderAllowance` is already `type(uint256).max`, the function should ideally revert or simply return true without modification, as it cannot be increased further.
StatusUnresolved
Low

Standard ERC20 `approve` Race Condition Still Present

L-01While the contract provides `increaseAllowance` and `decreaseAllowance` functions to mitigate the known ERC20 `approve` race condition, the standard `approve` function inherited from Solmate's ERC20 is still available. Users who are unaware of the race condition or the safer alternatives might still use `approve`, potentially exposing themselves to front-running attacks where an attacker can exploit a pending `approve` transaction to drain funds.
IssueWhile the contract provides `increaseAllowance` and `decreaseAllowance` functions to mitigate the known ERC20 `approve` race condition, the standard `approve` function inherited from Solmate's ERC20 is still available. Users who are unaware of the race condition or the safer alternatives might still use `approve`, potentially exposing themselves to front-running attacks where an attacker can exploit a pending `approve` transaction to drain funds.
FixStrongly advise users to exclusively use `increaseAllowance` and `decreaseAllowance` instead of `approve`. Consider adding a comment in the contract or documentation to highlight this. While not strictly a contract vulnerability, it's a common user-side security concern that can be mitigated by clear guidance.
StatusUnresolved

Category Ratings

TechnicalMedium4/10

The contract utilizes Solmate's ERC20 implementation, generally known for its efficiency and security (7.2 Code Security). However, custom implementations for `decreaseAllowance` and `increaseAllowance` introduce an underflow vulnerability (C-01) and an overflow vulnerability (M-01) respectively. A significant design flaw exists in the `inflationRemainder` function, where an unbounded loop could lead to a denial-of-service for minting operations in the long term (H-02), impacting 7.8 Operations. The contract's architecture (7.1 Architecture) is straightforward, but these specific function implementations require attention.

GovernanceHigh1/10

The contract exhibits a high degree of centralization, with a single `owner` address controlling the ability to change the `minter` and the `minter` having sole authority to mint new tokens (7.3 Access Control). This creates a significant trust assumption in the deployer or subsequent owner (H-01). The economic model (7.4 Economic) includes a custom inflation schedule with a `tenYearSupplyCap` and a 2% annual increase after 9 years, which is transparently defined. However, the long-term viability of the inflation calculation is threatened by the potential DoS issue (H-02).

UpgradesHigh3/10

The contract is not designed to be upgradeable (7.7 Upgrades). It is a standard, non-proxy ERC20 implementation, meaning its logic is immutable once deployed. This eliminates upgrade-related risks such as proxy misconfigurations or logic mismatches between proxy and implementation contracts.

Security Checklist

2/5 checks passed
Contract VerifiedPass
Ownership RenouncedFail
No Mint FunctionFail
Liquidity LockedFail
Not a ProxyPass

Holder Composition

75.9% in top 10
0.0% in wallets75.9% in contracts
Effective Concentration30.3%

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

$1.33M

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 Holder100.0%
Top-3 Unlocked100.0%

Key Addresses

11 addresses
Deployer
0xeb2a…914e
Unlocked LP Held By
0xa0da…0f820x7328…36bc0xa9e7…6ee70x5b67…1d5f0xdf23…e3780xc860…44380xdfee…9ad10x902e…9c140xb3ac…68a00x7425…5a35

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

What Raised This Score

10 factors
  • Ownership NOT renounced — owner is a role-gated executor contract
  • Mintable supply — no cap found, dilution unbounded
  • Top-10 concentration > 30% (75.9% total → 30.3% effective; 0.0% in EOAs, 75.9% in contracts — moderate)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 100.0% (independent LP — depth risk)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk)
  • 1 Critical finding(s) from audit
  • 2 High finding(s) from audit
  • 1 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

Related Audits

6 more on the record
Synapse (SYN)Critical RiskChipCritical RiskPortalCritical RiskNillion (NIL)Critical RisktrUSDCritical RiskMain Street USD (MSUSD)Critical Risk

Would You Like a More Detailed Audit of Autonolas?

Our AI-powered scanner gives you a deeper, real-time smart contract analysis — free, with every scoring factor shown.

Get Detailed Audit