Quantum Audit Logo

Is Amp Safe?

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

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

Amp AMP
0xff20…95c2
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 today 1 audit on record
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

This audit covers core components of the Amp token, including its ownership mechanism, ERC-1820 compliance, and utility libraries. The contract utilizes `SafeMath` for arithmetic safety and a robust two-step ownership transfer. Key findings include centralization risks associated with owner privileges, dependencies on the external ERC-1820 registry, and the potential for malicious interface implementers if not properly managed by the main token contract. Recommendations focus on enhancing access control and considering compiler upgrades.

1 High2 Medium3 Informational
Volume 24h
$240.7K
Liquidity
$89.5K
Price
$0.0006914
Token Age
6y
Top 10 Holders
62.0%

Security Findings

1 High2 Med3 Info
High

Centralization Risk via Owner Privileges

H-01The `Ownable` contract grants significant control to a single `owner` address, including the ability to authorize a new owner. While the two-step ownership transfer (`authorizeOwnershipTransfer` and `assumeOwnership`) is a good security practice, the owner retains ultimate control over critical functions, including those interacting with the ERC-1820 registry (e.g., `setInterfaceImplementation`, `delegateManagement` if exposed in the main contract). A compromise of the owner's private key could lead to full control over the contract's configurable aspects (7.3 Access Control, 7.5 Governance).
IssueThe `Ownable` contract grants significant control to a single `owner` address, including the ability to authorize a new owner. While the two-step ownership transfer (`authorizeOwnershipTransfer` and `assumeOwnership`) is a good security practice, the owner retains ultimate control over critical functions, including those interacting with the ERC-1820 registry (e.g., `setInterfaceImplementation`, `delegateManagement` if exposed in the main contract). A compromise of the owner's private key could lead to full control over the contract's configurable aspects (7.3 Access Control, 7.5 Governance).
FixConsider implementing a multi-signature wallet for the `owner` address to distribute control and reduce the single point of failure. For highly sensitive operations, explore time-locks or a decentralized governance mechanism to introduce a delay or broader consensus for critical changes.
StatusUnresolved
Medium

Dependency on External ERC-1820 Registry

M-01The contract hardcodes the address of the ERC-1820 Registry (0x1820…aD24). While this is the standard and widely adopted registry on mainnet, any future compromise, malfunction, or unexpected behavior of this external contract could directly impact the functionality and security of the `Amp` token's ERC-1820 compliance and interface management (7.6 External).
IssueThe contract hardcodes the address of the ERC-1820 Registry (). While this is the standard and widely adopted registry on mainnet, any future compromise, malfunction, or unexpected behavior of this external contract could directly impact the functionality and security of the `Amp` token's ERC-1820 compliance and interface management (7.6 External).
FixAcknowledge this inherent dependency. While the ERC-1820 registry is a well-established standard, ensure robust monitoring of its status and consider contingency plans if its integrity were ever compromised (though this is a low probability event for such a foundational contract).
StatusUnresolved
Medium

Risk of Malicious ERC-1820 Interface Implementers

M-02The `ERC1820Client` allows setting arbitrary addresses as implementers for specific interfaces via `setInterfaceImplementation`. While this function is `internal` in the provided snippet, its eventual exposure in the main `Amp` contract (likely via an `onlyOwner` function) means that a malicious or compromised implementer contract could be registered. Such an implementer could then intercept or manipulate calls intended for the declared interface, potentially leading to unauthorized actions or unexpected behavior within the token's ecosystem (7.2 Code Security, 7.6 External).
IssueThe `ERC1820Client` allows setting arbitrary addresses as implementers for specific interfaces via `setInterfaceImplementation`. While this function is `internal` in the provided snippet, its eventual exposure in the main `Amp` contract (likely via an `onlyOwner` function) means that a malicious or compromised implementer contract could be registered. Such an implementer could then intercept or manipulate calls intended for the declared interface, potentially leading to unauthorized actions or unexpected behavior within the token's ecosystem (7.2 Code Security, 7.6 External).
FixImplement strict validation and control over which addresses can be set as interface implementers. Ideally, only trusted, audited, and immutable contracts should be registered. Consider a whitelist or a governance-controlled approval process for new implementers.
StatusUnresolved
Info

Incomplete Context for Internal ERC-1820 Functions

I-01The `ERC1820Client` functions `setInterfaceImplementation` and `delegateManagement` are declared as `internal`. Their security and potential impact are entirely dependent on how they are called and what access control mechanisms are applied to them within the main `Amp` contract, which was not provided for this audit. Without the full context, it's impossible to fully assess the risks associated with their usage (7.1 Architecture).
IssueThe `ERC1820Client` functions `setInterfaceImplementation` and `delegateManagement` are declared as `internal`. Their security and potential impact are entirely dependent on how they are called and what access control mechanisms are applied to them within the main `Amp` contract, which was not provided for this audit. Without the full context, it's impossible to fully assess the risks associated with their usage (7.1 Architecture).
FixEnsure that any public or external functions that call these internal ERC-1820 management functions are adequately protected with appropriate access control (e.g., `onlyOwner` or multi-sig governance) and input validation.
StatusUnresolved
Info

Use of `abi.encodePacked` for `keccak256`

I-02The contract uses `abi.encodePacked` for hashing strings (e.g., `_interfaceLabel`, `ERC1820_ACCEPT_MAGIC`) before applying `keccak256`. While this is acceptable for single, fixed-length strings, `abi.encodePacked` can lead to hash collisions or unexpected behavior when concatenating multiple dynamic types due to its non-standard padding. For single strings, `abi.encode` is generally safer and more explicit, though `abi.encodePacked` is commonly used for interface hashes in ERC-1820 (7.2 Code Security).
IssueThe contract uses `abi.encodePacked` for hashing strings (e.g., `_interfaceLabel`, `ERC1820_ACCEPT_MAGIC`) before applying `keccak256`. While this is acceptable for single, fixed-length strings, `abi.encodePacked` can lead to hash collisions or unexpected behavior when concatenating multiple dynamic types due to its non-standard padding. For single strings, `abi.encode` is generally safer and more explicit, though `abi.encodePacked` is commonly used for interface hashes in ERC-1820 (7.2 Code Security).
FixFor future development, consider using `abi.encode` instead of `abi.encodePacked` for hashing, especially when dealing with multiple or dynamic arguments, to ensure explicit and unambiguous encoding. For the current use case with single strings, the risk is minimal.
StatusUnresolved
Info

Older Solidity Compiler Version

I-03The contract is compiled with `pragma solidity 0.6.10`. While this version is functional, newer Solidity versions (e.g., 0.8.x) introduce several security enhancements, including built-in overflow/underflow checks for arithmetic operations (removing the need for `SafeMath`), custom error types for more gas-efficient error handling, and improved optimizer behavior (7.2 Code Security).
IssueThe contract is compiled with `pragma solidity 0.6.10`. While this version is functional, newer Solidity versions (e.g., 0.8.x) introduce several security enhancements, including built-in overflow/underflow checks for arithmetic operations (removing the need for `SafeMath`), custom error types for more gas-efficient error handling, and improved optimizer behavior (7.2 Code Security).
FixConsider upgrading the Solidity compiler version to a more recent release (e.g., 0.8.x) to benefit from the latest security features and gas optimizations. This would also allow removing the `SafeMath` library, simplifying the code. Thorough testing would be required after such an upgrade.
StatusUnresolved

Category Ratings

TechnicalMedium6/10

The contract demonstrates good technical practices, including the use of `SafeMath` to prevent integer overflows/underflows (7.2 Code Security) and a well-structured `Ownable` pattern with a two-step transfer mechanism (7.3 Access Control). The implementation of ERC-1820 client and implementer interfaces is standard and enables robust introspection (7.1 Architecture). However, the security of setting ERC-1820 implementers relies heavily on the main contract's access control, which is not fully provided (7.2 Code Security). Additionally, the use of an older Solidity compiler version (0.6.10) means foregoing some modern security features (7.2 Code Security).

GovernanceHigh3/10

The `Ownable` contract centralizes significant control under a single owner address (7.3 Access Control, 7.5 Governance). While the two-step ownership transfer mechanism is a strong security feature, the owner retains ultimate authority over critical configurations, including the ability to authorize a new owner. This introduces a single point of failure where a compromised owner key could lead to unauthorized changes. The contract's economic model is not fully visible in this snippet (7.4 Economic), but the foundational access control is a key governance aspect.

UpgradesMedium4/10

The provided contract snippet does not implement a traditional proxy upgrade pattern (7.7 Upgrades). However, its adherence to the ERC-1820 standard allows for a form of modularity and 'upgradeability' by enabling the contract to declare and change its interface implementers. This allows for flexible integration with other contracts and potential future extensions of functionality by registering new implementers. The security of this mechanism depends on the access control around setting these implementers.

Security Checklist

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

Holder Composition

62.0% in top 10
38.1% in wallets23.9% in contracts
Effective Concentration47.7%

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

$156.3K across 9 pairs
SushiswapWETHanalysed$89.5K57.3%Uniswap v2WETH$60.5K38.8%Uniswap v3WETH$3.7K2.4%SushiswapDAI$1.6K1.0%ShibaswapWETH$6930.4%ShibaswapSHIB$1770.1%
Show 3 more pairsShow less
BalancerUSDC$350.0%ShibaswapDAI$100.0%Uniswap v4ETH$80.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 Holder75.5%
Top-3 Unlocked99.6%

Key Addresses

11 addresses
Deployer
0x8ebe…7c87
Unlocked LP Held By
0x3887…7f1c0xd7e8…dc890xbe69…c3ef0x0f55…96be0x4c8c…1cac0xe12d…5fb60x6ea4…57860x1d2a…158c0x9247…8f500x743e…7415

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 — owner is a contract (governance/executor, not an EOA)
  • Mintable supply — no cap found, dilution unbounded
  • Top-10 concentration > 30% (62.0% total → 47.7% effective; 38.1% in EOAs, 23.9% in contracts — moderate)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 75.5% (independent LP — depth risk, pool = 57% of DEX liquidity)
  • LP top3 unlocked holders = 99.6% (independent LP — depth risk, pool = 57% of DEX liquidity)
  • 1 High finding(s) from audit
  • 2 Medium 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
Wrapped Pulse from PulseChain (WPLS)High RiskFLOKIHigh RiskStargate Finance (STG)High RiskEspresso (ESP)High RiskPRDCTR (PRD)High RiskAXGTHigh Risk

Would You Like a More Detailed Audit of Amp?

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

Get Detailed Audit