Quantum Audit Logo
Launch App

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

Is Autonolas Safe?

OLASEthereum
Not verified This record has not gone through deep verification and is not being monitored. The score is a dated snapshot — the token’s risk can change at any time.Own this token? Put it under verification →
Last checked Sep 4, 2026 · 1 audit on record
Chart
High RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical4/10Governance1/10Upgrades3/10Checks passed2 of 5Findings1 Critical · 2 High · 1 Medium · 1 Low5
SummaryAI Copilot

The OLAS token contract is an ERC20 implementation with custom minting and inflation control.

Read the full analysis
What raised the score
  • Ownership not renounced — owner is a role-gated executor contract
  • Mintable supply — no cap found, dilution unbounded
  • Top-10 concentration > 30%
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 100.0%
  • LP top3 unlocked holders = 100.0%
  • 1 Critical finding(s) from audit
  • 2 High finding(s) from audit
  • 1 Medium finding(s) from audit
  • 1 Low finding(s) from audit
Exact 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

Security Checklist

as of audit · Sep 42 of 5 checks passed
Contract verifiedVerified
OwnershipRetained
MintMintable
Liquidity lockNot locked
UpgradeabilityFixed code

Holders

as of audit · Sep 4, 2026
75.9%Contracts24.1%Everyone else
75.9%Contracts24.1%Everyone else
ContractsEveryone elseBubble area = share of supply
75.9%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking75.9%
  • Everyone elsethe rest of the supply24.1%
Effective concentrationwhat the score reads30.3%
How holder types affect the score

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.

Holder balances as recorded by the audit of Sep 4, 2026

Liquidity

as of audit · Sep 4$1.33M

The risk score reads depth across every pair.

LP tokensNot locked

The LP tokens of the analysed pool are not locked or burned, so whoever holds them can withdraw that liquidity.

Analysed pool$1.33MShare of depth100.0%
Top-1 Unlocked Holder100.0%
Top-3 Unlocked100.0%
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.

Security Findings

1 Critical2 High1 Medium1 Low
Critical

Underflow Vulnerability in decreaseAllowance

The 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.C-01

Issue

The 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.

Fix

Add 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.

Status

Unresolved

High

Centralized Control of Token Minting and Ownership

The 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.H-01

Issue

The 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.

Fix

Consider 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.

Status

Unresolved

High

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

The 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.H-02

Issue

The 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.

Fix

Redesign 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.

Status

Unresolved

Medium

Overflow Vulnerability in increaseAllowance

The 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.M-01

Issue

The 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.

Fix

While 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.

Status

Unresolved

Low

Standard ERC20 approve Race Condition Still Present

While 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.L-01

Issue

While 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.

Fix

Strongly 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.

Status

Unresolved

Analysis

AI Copilotas of audit · Sep 4
Executive SummaryWhat the contract is and what the review found

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.

Technical4/10Medium risk

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.

Governance1/10High risk

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).

Upgrades3/10High risk

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.

Final RecommendationWhat to do about this score

Address the critical underflow vulnerability in decreaseAllowance by adding a proper check to ensure spenderAllowance >= amount before subtraction.

Mitigate the potential denial-of-service in inflationRemainder by either capping the loop iterations or redesigning the calculation to avoid a linear loop over time, ensuring long-term usability of the minting function. Consider implementing a multi-signature wallet for the owner and minter roles to decentralize control and reduce single points of failure. Educate users to exclusively use increaseAllowance and decreaseAllowance to avoid the standard ERC20 approve race condition.

Contract & Record

1 audit on record
TypeToken
NetworkEthereum
Token age3y
Contract0x0001…5cb0
Deployer0xeb2a…914e
Badge for your website
Autonolas security record badge

Free for any token on the record. It links to this page and always shows the current score and the date it was checked.

Audit History
  1. Aug 14, 202676High

Score changes are recorded as dated snapshots — history is append-only and cannot be edited.

Related Audits

6 more on the recordAll audits
SynapseSYN · Ethereum76HighChipEthereum76HighWoofEthereum76HighPortalEthereum77HighNillionNIL · Ethereum77HightrUSDEthereum75High

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 Is this your token? Publish your own audit on this page