Quantum Audit Logo
Launch App

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

Is Ampleforth Safe?

AMPLEthereum
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
Technical6/10Governance1/10Upgrades1/10Checks passed4 of 7Findings1 High · 1 Medium · 1 Low · 1 Info4
SummaryAI Copilot

The UFragments (AMPL) contract implements a rebaseable ERC-20 token.

Read the full analysis
What raised the score
  • Ownership not renounced — owner is a contract
  • Proxy contract
  • Admin is unclassified contract
  • Top-10 concentration > 70%
  • Liquidity not locked
  • 1 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 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

Security Checklist

as of audit · Sep 44 of 7 checks passed
Contract verifiedVerified
OwnershipRetained
MintNo mint
Liquidity lockNot locked
UpgradeabilityUpgradeable
HoneypotNone found
Buy / sell tax0% / 0%

Holders

as of audit · Sep 4, 2026

How the supply is spread across holders could not be read — the indexer's holder list does not add up to the supply. Check the largest holders on a block explorer, which reads current balances.

Liquidity

as of audit · Sep 4$678.3K across 5 pairs

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$582.2KShare of depth85.8%
Top-1 Unlocked Holder37.0%
Top-3 Unlocked55.1%
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.

Security Findings

1 High1 Medium1 Low1 Info
High

Centralized Control over Token Supply

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

Issue

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

Fix

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

Status

Unresolved

Medium

Unused State Variables and Upgradeability Risk

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

Issue

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

Fix

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

Status

Unresolved

Low

transferAll and transferAllFrom use delete

The 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)L-01

Issue

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

Fix

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

Status

Unresolved

Info

MAX_SUPPLY Hard Cap

The _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)I-01

Issue

The _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)

Fix

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

Status

Unresolved

Analysis

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

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.

Technical6/10Medium risk

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

Governance1/10High risk

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.

Upgrades1/10High risk

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

Final RecommendationWhat to do about this score

To enhance the security and decentralization of the Ampleforth protocol, it is strongly recommended to implement a multi-signature wallet for the owner and monetaryPolicy roles.

This would distribute control over critical functions like setting the monetary policy and executing rebases, mitigating the risk associated with a single point of failure. Additionally, consider removing unused state variables to streamline the contract and reduce potential storage collision risks during future upgrades.

Contract & Record

1 audit on record
TypeAdminUpgradeabilityProxy
NetworkEthereum
Token age1y
Contract0xd46b…a161
Deployer0xd846…5c22
Proxy Upgrade Controls
Proxy TypeZeppelin Os Legacy
AdminOther-Contract
ImplementationVerified source
Upgrades (30d)0 · stable
Badge for your website
Ampleforth 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. Sep 4, 202669High
  2. Aug 31, 202660Medium

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

Related Audits

6 more on the recordAll audits
Gram (prev. Toncoin)GRAM · Ethereum69HighStarknetSTRK · Ethereum69HighAtoshiATOS · Ethereum69HighsnowmoonEthereum69HighREEthereum68HighZamaEthereum68High

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