Quantum Audit Logo

Is Ampleforth Safe?

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

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

Ampleforth AMPL
0xd46b…a161
Ethereum Not verifiedLast checked 2d ago 1 audit on record
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

The UFragments (AMPL) contract implements a rebaseable ERC-20 token. It utilizes SafeMath for arithmetic safety and includes EIP-2612 permit functionality. The contract is upgradeable via an AdminUpgradeabilityProxy. A significant finding is the highly centralized control over the token's supply through the `monetaryPolicy` address, which can arbitrarily adjust `_totalSupply` via the `rebase` function. Additionally, unused state variables pose a minor risk for future upgrades.

1 High1 Medium1 Low1 Informational
Volume 24h
$948.6200
Liquidity
$582.2K
Price
$1.2300
Token Age
1y
Top 10 Holders
496.8%

Security Findings

1 High1 Med1 Low1 Info
High

Centralized Control over Token Supply

H-01The `owner` address has the ability to set the `monetaryPolicy` address. The `monetaryPolicy` address then has exclusive control over the `rebase` function, which can arbitrarily increase or decrease the token's `_totalSupply`. This grants a single external entity significant power to manipulate the token's supply, posing a high economic risk to token holders. (7.3 Access Control, 7.4 Economic, 7.5 Governance)
IssueThe `owner` address has the ability to set the `monetaryPolicy` address. The `monetaryPolicy` address then has exclusive control over the `rebase` function, which can arbitrarily increase or decrease the token's `_totalSupply`. This grants a single external entity significant power to manipulate the token's supply, posing a high economic risk to token holders. (7.3 Access Control, 7.4 Economic, 7.5 Governance)
FixConsider implementing a multi-signature wallet for the `owner` and `monetaryPolicy` roles to distribute control. Explore a time-locked mechanism or a decentralized governance process for critical supply adjustments to reduce single-point-of-failure risk.
StatusUnresolved
Medium

Unused State Variables and Upgradeability Risk

M-01The contract declares two private state variables, `rebasePausedDeprecated` and `tokenPausedDeprecated`, which are never used in the contract logic. While `private`, these variables still occupy storage slots. In an upgradeable contract using `AdminUpgradeabilityProxy`, changes to storage layout (e.g., removing these variables or changing their order/type in a future implementation) without careful slot management could lead to storage collisions, data corruption, or unexpected behavior in subsequent upgrades. (7.2 Code Security, 7.7 Upgrades)
IssueThe contract declares two private state variables, `rebasePausedDeprecated` and `tokenPausedDeprecated`, which are never used in the contract logic. While `private`, these variables still occupy storage slots. In an upgradeable contract using `AdminUpgradeabilityProxy`, changes to storage layout (e.g., removing these variables or changing their order/type in a future implementation) without careful slot management could lead to storage collisions, data corruption, or unexpected behavior in subsequent upgrades. (7.2 Code Security, 7.7 Upgrades)
FixRemove unused state variables to reduce contract complexity and potential for storage collisions during upgrades. If they are intended for future use, ensure their purpose is documented and their storage slots are explicitly managed across upgrades.
StatusUnresolved
Low

`transferAll` and `transferAllFrom` use `delete`

L-01The `transferAll` and `transferAllFrom` functions use `delete _gonBalances[msg.sender]` and `delete _gonBalances[from]` respectively to clear the sender's balance. While functionally correct and gas-efficient for transferring the entire balance, using `delete` explicitly clears the storage slot. This behavior, though not a direct vulnerability, might be unexpected for users accustomed to balances simply becoming zero through subtraction. (7.2 Code Security)
IssueThe `transferAll` and `transferAllFrom` functions use `delete _gonBalances[msg.sender]` and `delete _gonBalances[from]` respectively to clear the sender's balance. While functionally correct and gas-efficient for transferring the entire balance, using `delete` explicitly clears the storage slot. This behavior, though not a direct vulnerability, might be unexpected for users accustomed to balances simply becoming zero through subtraction. (7.2 Code Security)
FixDocument this behavior clearly for users. Alternatively, consider using `_gonBalances[sender] = 0;` for consistency with typical ERC-20 balance management, although `delete` is more gas-efficient for clearing a non-zero slot.
StatusUnresolved
Info

`MAX_SUPPLY` Hard Cap

I-01The `_totalSupply` of the token is capped at `type(uint128).max` (approximately 3.4 * 10^38) by the `MAX_SUPPLY` constant. This hard cap is enforced within the `rebase` function. While a very large number, it represents a fixed upper limit on the token's total supply. (7.4 Economic)
IssueThe `_totalSupply` of the token is capped at `type(uint128).max` (approximately 3.4 * 10^38) by the `MAX_SUPPLY` constant. This hard cap is enforced within the `rebase` function. While a very large number, it represents a fixed upper limit on the token's total supply. (7.4 Economic)
FixEnsure that all stakeholders and users are aware of this hard cap and its implications for the token's long-term economic model. This is a design decision rather than a vulnerability, but transparency is key.
StatusUnresolved

Category Ratings

TechnicalMedium6/10

The contract demonstrates good technical practices, including the use of SafeMath for robust arithmetic operations and adherence to the ERC-20 standard, along with EIP-712 for permit functionality. The `validRecipient` modifier prevents transfers to zero address or the contract itself. However, the presence of unused state variables (`rebasePausedDeprecated`, `tokenPausedDeprecated`) introduces minor code clutter and potential for storage collision risks in future upgrades (7.2 Code Security).

GovernanceHigh1/10

The economic model centers around a rebase mechanism, allowing the `monetaryPolicy` address to adjust the token's total supply. This mechanism is a core design feature of Ampleforth. However, the control over the `monetaryPolicy` address, which dictates supply changes, is highly centralized, initially set by the `owner` (7.3 Access Control, 7.4 Economic, 7.5 Governance). This centralization presents a significant economic risk, as a single entity can arbitrarily influence token supply and value.

UpgradesHigh1/10

The contract is designed for upgradeability using the `Initializable` pattern and is deployed behind an `AdminUpgradeabilityProxy`. The `ERC20Detailed` base contract includes a `______gap` variable, which is good practice for storage slot management during upgrades. However, the unused `rebasePausedDeprecated` and `tokenPausedDeprecated` variables, while private, occupy storage slots and could lead to storage collisions or unexpected behavior if not carefully managed in future upgrades (7.7 Upgrades).

Security Checklist

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

Proxy Upgrade Controls

Proxy TypeZeppelin Os Legacy
AdminOther-Contract
ImplementationVerified source
Upgrades (30d)0 · stable

Liquidity Depth

$678.3K across 5 pairs
Uniswap v2WETHanalysed$582.2K85.8%SushiswapWETH$61.0K9.0%Uniswap v4USDC$25.4K3.7%Uniswap v4ETH$9.7K1.4%Uniswap v3USDC$1020.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 Holder37.0%
Top-3 Unlocked55.1%

Key Addresses

11 addresses
Deployer
0xd846…5c22
Unlocked LP Held By
0x2235…39a90xe062…497c0xb46c…c00a0x1522…3cca0x7e18…40450xb740…033a0xd135…5cb20xebec…5b8b0xe295…3f770xce12…c034

A privileged address — the deployer, the owner, or the token contract itself — is among these holders, so that party can withdraw liquidity.

What Raised This Score

8 factors
  • Ownership NOT renounced — owner is a contract (governance/executor, not an EOA)
  • Proxy contract (upgradeable — admin can replace logic)
  • Admin is unclassified contract
  • Top-10 concentration > 70% (496.8% total → 458.7% effective; 433.2% in EOAs, 63.6% in contracts — extreme)
  • Liquidity NOT locked (owner can withdraw — rug-pull risk)
  • 1 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
Gram (prev. Toncoin) (GRAM)High RiskREHigh RiskZamaHigh RiskUNICURVEHigh RiskOpenServ (SERV)High RiskChain (XCN)High Risk

Would You Like a More Detailed Audit of Ampleforth?

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

Get Detailed Audit