Quantum Audit Logo

Is Ampleforth Governance Safe?

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

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

Ampleforth Governance FORTH
0x77fb…0ce0
Ethereum
Not verifiedThis 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 9d ago 1 audit on record
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

The Forth token contract implements an ERC-20 compliant token with additional governance features, including delegation and vote checkpoints. It incorporates a controlled minting mechanism and burning functionalities. The contract demonstrates good code quality, utilizing SafeMath and EIP-712 for signed operations. Key areas of concern include the centralized control held by the `minter` address and the use of an older Solidity compiler version with experimental features. The contract is not upgradeable, which eliminates upgrade-specific risks.

1 High1 Medium2 Low1 Informational
Volume 24h
$318.6K
Liquidity
$454.4K
Price
$0.3369
Token Age
5y
Top 10 Holders
69.7%

Security Findings

1 High1 Med2 Low1 Info
High

Centralized Minter Control

H-01The `minter` address has significant centralized control over the token supply. This address can mint new tokens up to the `mintCap` (2% of total supply) annually and can also change the `minter` address itself via the `setMinter` function. A compromise of this single address could lead to uncontrolled inflation or a complete loss of control over the token's minting mechanism, directly impacting the token's economic stability and trust (7.3 Access Control, 7.4 Economic, 7.5 Governance).
IssueThe `minter` address has significant centralized control over the token supply. This address can mint new tokens up to the `mintCap` (2% of total supply) annually and can also change the `minter` address itself via the `setMinter` function. A compromise of this single address could lead to uncontrolled inflation or a complete loss of control over the token's minting mechanism, directly impacting the token's economic stability and trust (7.3 Access Control, 7.4 Economic, 7.5 Governance).
FixImplement a multi-signature wallet (e.g., Gnosis Safe) or a time-locked contract for the `minter` role. This would require multiple trusted parties to approve critical operations like minting or changing the minter, significantly reducing the risk of a single point of failure.
StatusUnresolved
Medium

Minter's Ability to Manipulate Minting Schedule

M-01The `mintingAllowedAfter` timestamp is updated to `block.timestamp + minimumTimeBetweenMints` after every `mint` operation. This means the `minter` can effectively reset the cooldown period by performing a small, insignificant mint. If the `minter` wishes to delay a larger, scheduled mint, they could execute a minimal mint transaction, pushing the next available minting window back by `minimumTimeBetweenMints` (one year). This could lead to unexpected delays in token distribution or inflation schedule (7.4 Economic, 7.8 Operations).
IssueThe `mintingAllowedAfter` timestamp is updated to `block.timestamp + minimumTimeBetweenMints` after every `mint` operation. This means the `minter` can effectively reset the cooldown period by performing a small, insignificant mint. If the `minter` wishes to delay a larger, scheduled mint, they could execute a minimal mint transaction, pushing the next available minting window back by `minimumTimeBetweenMints` (one year). This could lead to unexpected delays in token distribution or inflation schedule (7.4 Economic, 7.8 Operations).
FixConsider modifying the `mintingAllowedAfter` logic to be less susceptible to manipulation. For example, `mintingAllowedAfter` could be set to `max(mintingAllowedAfter, block.timestamp) + minimumTimeBetweenMints` or a more robust schedule could be implemented that is not solely dependent on the last minting event.
StatusUnresolved
Low

Use of Experimental ABIEncoderV2

L-01The contract uses `pragma experimental ABIEncoderV2;` with Solidity 0.6.11. While `ABIEncoderV2` has become standard and is widely used, its 'experimental' tag in older compiler versions implies that it might have had less rigorous auditing or could contain subtle bugs compared to fully stable features. Although unlikely to be a critical issue today, it's generally safer to use stable features or newer compiler versions where `ABIEncoderV2` is no longer experimental (7.2 Code Security).
IssueThe contract uses `pragma experimental ABIEncoderV2;` with Solidity 0.6.11. While `ABIEncoderV2` has become standard and is widely used, its 'experimental' tag in older compiler versions implies that it might have had less rigorous auditing or could contain subtle bugs compared to fully stable features. Although unlikely to be a critical issue today, it's generally safer to use stable features or newer compiler versions where `ABIEncoderV2` is no longer experimental (7.2 Code Security).
FixFor future deployments or upgrades, consider migrating to a newer Solidity compiler version (e.g., 0.8.x) where `ABIEncoderV2` is stable and no longer requires the experimental pragma. This would also benefit from other security enhancements in newer compilers.
StatusUnresolved
Low

Older Solidity Compiler Version

L-02The contract is compiled with Solidity version 0.6.11. Newer Solidity versions (e.g., 0.8.x) include several security enhancements, such as built-in overflow/underflow checks for arithmetic operations, which reduce reliance on external libraries like SafeMath. While SafeMath is used here, migrating to a newer compiler could simplify the code and benefit from the latest compiler-level security features and optimizations (7.2 Code Security).
IssueThe contract is compiled with Solidity version 0.6.11. Newer Solidity versions (e.g., 0.8.x) include several security enhancements, such as built-in overflow/underflow checks for arithmetic operations, which reduce reliance on external libraries like SafeMath. While SafeMath is used here, migrating to a newer compiler could simplify the code and benefit from the latest compiler-level security features and optimizations (7.2 Code Security).
FixConsider upgrading the Solidity compiler version to 0.8.x or later. This would allow for the removal of SafeMath (as arithmetic operations would revert on overflow/underflow by default) and provide access to other modern language features and security improvements.
StatusUnresolved
Info

Front-running Potential in EIP-712 Signature Functions

I-01Functions like `permit` and `delegateBySig` allow users to perform gasless transactions by providing a signed message. While `nonces` and `deadlines` are correctly implemented to prevent replay attacks, these functions are still susceptible to front-running. A malicious actor could observe a pending signed transaction, submit it with a higher gas price, and potentially cause the original user's transaction to fail or incur unnecessary gas costs. This is a common characteristic of EIP-712 signature schemes and not a direct vulnerability in the contract's logic (7.2 Code Security).
IssueFunctions like `permit` and `delegateBySig` allow users to perform gasless transactions by providing a signed message. While `nonces` and `deadlines` are correctly implemented to prevent replay attacks, these functions are still susceptible to front-running. A malicious actor could observe a pending signed transaction, submit it with a higher gas price, and potentially cause the original user's transaction to fail or incur unnecessary gas costs. This is a common characteristic of EIP-712 signature schemes and not a direct vulnerability in the contract's logic (7.2 Code Security).
FixEducate users about the potential for front-running when using signed messages for `permit` and `delegateBySig`. Advise them to use services that offer MEV protection or to be mindful of network congestion when submitting such transactions. No direct code change is required for this inherent characteristic.
StatusUnresolved

Category Ratings

TechnicalLow8/10

The contract demonstrates good adherence to ERC-20 standards and incorporates robust governance features like delegation and vote checkpoints (7.1 Architecture). It utilizes `SafeMath` for arithmetic operations and `uint96` for balances, which is gas-efficient and correctly implemented with `safe96` checks to prevent overflows (7.2 Code Security). However, the use of Solidity 0.6.11 and `experimental ABIEncoderV2` introduces minor technical debt and potential for subtle issues compared to newer compiler versions (7.2 Code Security). The EIP-712 signature functions (`permit`, `delegateBySig`) are correctly implemented, enhancing user experience (7.2 Code Security).

GovernanceHigh1/10

The token's economic model includes a controlled minting mechanism with a `minter` role, a `mintCap` of 2% of total supply, and a `minimumTimeBetweenMints` of one year (7.4 Economic). This provides a predictable inflation schedule. However, the `minter` address holds significant centralized power, including the ability to change the minter and control all minting operations (7.3 Access Control, 7.5 Governance). This centralization presents a single point of failure and potential for economic manipulation if the minter's key is compromised. The `minter` can also influence the minting schedule (7.8 Operations).

UpgradesMedium6/10

The Forth contract is implemented as a standard, non-upgradeable token contract (7.7 Upgrades). This design choice eliminates the complexities and risks associated with proxy patterns and upgradeability, such as storage collisions or faulty upgrade logic. Consequently, there are no upgrade-specific vulnerabilities to address, ensuring immutability of the contract's logic post-deployment.

Security Checklist

3/5 checks passed
Contract VerifiedPass
Ownership RenouncedFail
No Mint FunctionPass
Liquidity LockedFail
Not a ProxyPass
HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

69.7% in top 10
33.9% in wallets35.8% in contracts
Effective Concentration48.2%

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

$472.2K across 5 pairs
Uniswap v3WETHanalysed$454.4K96.2%Uniswap v2WETH$10.1K2.1%Uniswap v3WETH$4.4K0.9%Uniswap v2USDT$3.3K0.7%SushiswapWETH$70.0%

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 Holder59.9%
Top-3 Unlocked83.9%

Key Addresses

11 addresses
Deployer
0xfe23…7f98
Unlocked LP Held By
0xcde6…e4490xc7a9…5e760xb282…80a80xc239…9a700x1f6d…dd100x4bd7…bd7e0xda2f…aeeb0xb2e0…91d30x2ff5…47940x0ea2…03d0

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

What Raised This Score

8 factors
  • Ownership NOT renounced (admin/mint authority retained)
  • Top-10 concentration > 30% (69.7% total → 48.2% effective; 33.9% in EOAs, 35.8% in contracts — moderate)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 59.9% (independent LP — depth risk, pool = 96% of DEX liquidity)
  • LP top3 unlocked holders = 83.9% (independent LP — depth risk, pool = 96% of DEX liquidity)
  • 1 High finding(s) from audit
  • 1 Medium finding(s) from audit
  • 2 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
MorphoHigh RiskBeamHigh RiskSuperVerse (SUPER)High Risk00 Token (00)High RiskIxs Token (IXS)High RiskAlberich Token (ALBRH)High Risk

Would You Like a More Detailed Audit of Ampleforth Governance?

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

Get Detailed Audit