Quantum Audit Logo

Is Memento a Scam?

Honeypot, rug-pull and ownership checks

Memento DEXTF
0xb69b…fa89
Base
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.
Last checked today 1 audit on record
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

The FactoryBurnMintERC20 contract implements a standard ERC20 token with additional burn and mint functionalities, managed by a role-based access control system. It incorporates OpenZeppelin's Ownable2Step for secure ownership management and includes a maximum supply limit. While the code demonstrates good practices like Solidity 0.8.x safety features and address validation, the highly centralized control over token supply and an inconsistency in initial supply validation present notable risks. The contract's integration with an external CCIP admin also introduces an external dependency that should be thoroughly understood.

1 High1 Medium1 Low1 Informational
i Our automated scanner reviewed Memento (DEXTF) on Base. 2 of 5 security checks passed — see the full breakdown below.
Volume 24h
$88.9K
Liquidity
$190.4K
Price
$0.05966
Age
11mo
Top 10 Holders
48.6%

Security Findings

1 High1 Med1 Low1 Info
High

Centralized Control over Token Supply and Critical Roles

H-01The `owner` address has complete control over granting and revoking `minter` and `burner` roles, as well as setting the `s_ccipAdmin` address. This centralization means a single compromised owner key or a malicious owner could manipulate the token supply (minting/burning) or redirect critical administrative functions through the `s_ccipAdmin` without any checks or balances. This introduces a significant single point of failure and trust assumption (7.3 Access Control, 7.4 Economic).
IssueThe `owner` address has complete control over granting and revoking `minter` and `burner` roles, as well as setting the `s_ccipAdmin` address. This centralization means a single compromised owner key or a malicious owner could manipulate the token supply (minting/burning) or redirect critical administrative functions through the `s_ccipAdmin` without any checks or balances. This introduces a significant single point of failure and trust assumption (7.3 Access Control, 7.4 Economic).
FixImplement a multi-signature wallet (e.g., Gnosis Safe) for the `owner` address to manage critical functions such as `grantMintRole`, `grantBurnRole`, `revokeMintRole`, `revokeBurnRole`, and `setCCIPAdmin`. This would require multiple approvals for sensitive operations, significantly reducing the risk of a single point of compromise or malicious action. Alternatively, explore a decentralized governance model if the project aims for greater decentralization.
StatusUnresolved
Medium

`preMint` can Exceed `maxSupply` in Constructor

M-01The `preMint` amount provided in the constructor is minted directly using `_mint(newOwner, preMint)` without checking against the `i_maxSupply` value. The `MaxSupplyExceeded` check is only applied to subsequent calls to the `mint` function. This allows the initial token supply to potentially exceed the declared `i_maxSupply` at deployment, leading to an inconsistent state where `totalSupply()` is greater than `maxSupply()` (7.2 Code Security, 7.4 Economic).
IssueThe `preMint` amount provided in the constructor is minted directly using `_mint(newOwner, preMint)` without checking against the `i_maxSupply` value. The `MaxSupplyExceeded` check is only applied to subsequent calls to the `mint` function. This allows the initial token supply to potentially exceed the declared `i_maxSupply` at deployment, leading to an inconsistent state where `totalSupply()` is greater than `maxSupply()` (7.2 Code Security, 7.4 Economic).
FixAdd a check in the constructor to ensure that `preMint` does not exceed `maxSupply_` if `maxSupply_` is not zero. For example: ```solidity constructor( // ... other params uint256 maxSupply_, uint256 preMint, // ... other params ) ERC20(name, symbol) { // ... i_maxSupply = maxSupply_; if (maxSupply_ != 0 && preMint > maxSupply_) { revert MaxSupplyExceeded(preMint); // Or a custom error for constructor } if (preMint != 0) _mint(newOwner, preMint);…
StatusUnresolved
Low

Unclear Role and Privileges of `s_ccipAdmin`

L-01The contract allows the `owner` to set an address for `s_ccipAdmin` via `setCCIPAdmin`. While this contract only provides a getter (`getCCIPAdmin`) and setter for this address, its actual privileges and interactions with other components of the Cross-Chain Interoperability Protocol (CCIP) are not defined within this codebase. This creates an implicit external dependency, and the security of the overall system relies on the proper management and behavior of the `s_ccipAdmin` in external contracts (7.6 External, 7.8 Operations).
IssueThe contract allows the `owner` to set an address for `s_ccipAdmin` via `setCCIPAdmin`. While this contract only provides a getter (`getCCIPAdmin`) and setter for this address, its actual privileges and interactions with other components of the Cross-Chain Interoperability Protocol (CCIP) are not defined within this codebase. This creates an implicit external dependency, and the security of the overall system relies on the proper management and behavior of the `s_ccipAdmin` in external contracts (7.6 External, 7.8 Operations).
FixClearly document the intended role, responsibilities, and specific privileges of the `s_ccipAdmin` address within the broader CCIP ecosystem. Ensure that the entity controlling this address is highly secure and follows robust operational procedures. Consider adding comments in the code or external documentation to clarify its purpose.
StatusUnresolved
Info

Redundant `decreaseApproval` and `increaseApproval` Aliases

I-01The contract includes `decreaseApproval` and `increaseApproval` functions that internally call `decreaseAllowance` and `increaseAllowance` respectively. While harmless, these aliases are not part of the standard ERC20 interface and might introduce slight confusion or redundancy without providing additional functionality (7.2 Code Security).
IssueThe contract includes `decreaseApproval` and `increaseApproval` functions that internally call `decreaseAllowance` and `increaseAllowance` respectively. While harmless, these aliases are not part of the standard ERC20 interface and might introduce slight confusion or redundancy without providing additional functionality (7.2 Code Security).
FixConsider removing these alias functions if they do not serve a specific purpose beyond simply calling the standard `decreaseAllowance` and `increaseAllowance`. If they are intended for backward compatibility or specific integration, document their purpose clearly.
StatusUnresolved

Category Ratings

TechnicalLow7/10

The contract leverages well-audited OpenZeppelin libraries (v4.8.3) and Solidity 0.8.x, benefiting from built-in overflow/underflow checks (7.2 Code Security). The `validAddress` modifier prevents transfers to the contract itself, enhancing robustness. However, a technical inconsistency exists where the `preMint` amount in the constructor is not validated against the `i_maxSupply`, potentially allowing the initial token supply to exceed the declared maximum (7.2 Code Security).

GovernanceHigh3/10

The contract's economic model is highly centralized, with the owner having complete control over granting and revoking minter/burner roles, directly impacting token supply (7.4 Economic). While a `maxSupply` limits total minting, the owner's ability to manipulate roles represents a significant trust assumption (7.3 Access Control). The `s_ccipAdmin` address, controllable by the owner, introduces an external dependency whose privileges are not defined within this contract, posing a potential governance risk if not properly managed (7.5 Governance, 7.6 External).

UpgradesHigh3/10

The FactoryBurnMintERC20 contract is not designed as an upgradeable proxy (7.7 Upgrades). This means its logic cannot be modified post-deployment, eliminating upgrade-specific risks but requiring careful initial deployment and immutable design considerations.

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

48.6% in top 10
21.6% in wallets27.1% in contracts
Effective Concentration32.4%

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

$190.4K across 2 pairs
Hydrex CLAMMWETHanalysed$190.4K100.0%AerodromeWETH$630.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 Holder27.7%
Top-3 Unlocked68.5%

Key Addresses

6 addresses
Deployer
0xc391…8127
Unlocked LP Held By
0x2777…a0360x8815…288b0x5c3b…25af0xaf7b…00ea0x3662…ba86

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

What Raised This Score

7 factors
  • Ownership NOT renounced — owner is an EOA (single private key)
  • Mintable supply — no cap found, dilution unbounded
  • Top-10 concentration > 30% (48.6% total → 32.4% effective; 21.6% in EOAs, 27.1% in contracts — moderate)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug 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
EURCHigh RiskCoinbase Wrapped BTC (CBBTC)High RiskDotHigh RiskSekuya (SKYA)High Risk717ai by Virtuals (WIRE)High RiskRibbita by Virtuals (TIBBIR)High Risk

Would You Like a More Detailed Audit of Memento?

Paste the contract address into our AI-powered scanner for a deeper real-time report — free, with every scoring factor shown.

Get Detailed Audit