Quantum Audit Logo

Is Recall Safe?

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

Recall RECALL
0x1f16…0671
Base Not verifiedLast checked 3d ago 2 audits on record
DexScreener ↗
How is this score calculated? → Critical Risk
Executive SummaryAI Copilot

The Recall token contract is an upgradeable ERC20 token leveraging OpenZeppelin's battle-tested libraries for access control, pausability, and UUPS proxy functionality. It also integrates with the Axelar Interchain Token Standard. While the code quality is high and standard patterns are followed, the initial configuration assigns all critical administrative, minting, and pausing roles to a single deployer address. This centralization introduces significant single points of failure, elevating the overall risk level.

1 High2 Medium1 Low1 Informational
Volume 24h
$414.0K
Liquidity
$561.3K
Price
$0.04058
Token Age
1y
Top 10 Holders
62.1%

Security Findings

1 High2 Med1 Low1 Info
High

Centralized Control of Critical Roles

H-01The `initialize` function assigns the `ADMIN_ROLE`, `MINTER_ROLE`, and `PAUSER_ROLE` to the `msg.sender` (deployer EOA). The `ADMIN_ROLE` has the ability to manage all other roles, unpause the contract, and authorize contract upgrades. This creates a single point of failure where a compromise of the deployer's EOA could lead to complete control over the token's functionality, including arbitrary minting, halting operations, and deploying malicious contract logic (7.3 Access Control, 7.5 Governance, 7.8 Operations).
IssueThe `initialize` function assigns the `ADMIN_ROLE`, `MINTER_ROLE`, and `PAUSER_ROLE` to the `msg.sender` (deployer EOA). The `ADMIN_ROLE` has the ability to manage all other roles, unpause the contract, and authorize contract upgrades. This creates a single point of failure where a compromise of the deployer's EOA could lead to complete control over the token's functionality, including arbitrary minting, halting operations, and deploying malicious contract logic (7.3 Access Control, 7.5 Governance, 7.8 Operations).
FixTransfer the `ADMIN_ROLE`, `MINTER_ROLE`, and `PAUSER_ROLE` to a multi-signature wallet or a robust DAO governance contract immediately after deployment and initialization. This distributes control and significantly reduces the risk associated with a single compromised private key.
StatusUnresolved
Medium

Pausability as a Centralized Denial-of-Service Vector

M-01The `PAUSER_ROLE` has the ability to call `pause()`, which halts all token transfers, minting, and burning operations. While the `ADMIN_ROLE` can `unpause()`, the unilateral ability of a single `PAUSER_ROLE` holder to stop all token activity presents a significant centralization risk and potential for denial of service (7.3 Access Control, 7.4 Economic). A malicious or compromised `PAUSER_ROLE` could disrupt the protocol's operations.
IssueThe `PAUSER_ROLE` has the ability to call `pause()`, which halts all token transfers, minting, and burning operations. While the `ADMIN_ROLE` can `unpause()`, the unilateral ability of a single `PAUSER_ROLE` holder to stop all token activity presents a significant centralization risk and potential for denial of service (7.3 Access Control, 7.4 Economic). A malicious or compromised `PAUSER_ROLE` could disrupt the protocol's operations.
FixConsider implementing a timelock for the `pause()` function or requiring multiple parties (e.g., a multi-signature wallet) to approve pausing. Alternatively, restrict the `PAUSER_ROLE` to a trusted, highly secure entity or a governance mechanism with appropriate checks and balances.
StatusUnresolved
Medium

Centralized Minting Authority

M-02The `MINTER_ROLE` has the authority to mint an arbitrary amount of new tokens to any address. If the `MINTER_ROLE` is controlled by a single EOA and that EOA is compromised, an attacker could mint an unlimited supply of tokens, leading to hyperinflation and severe devaluation of existing tokens (7.4 Economic). This centralized control over token supply poses a significant economic risk.
IssueThe `MINTER_ROLE` has the authority to mint an arbitrary amount of new tokens to any address. If the `MINTER_ROLE` is controlled by a single EOA and that EOA is compromised, an attacker could mint an unlimited supply of tokens, leading to hyperinflation and severe devaluation of existing tokens (7.4 Economic). This centralized control over token supply poses a significant economic risk.
FixImplement a minting cap, rate limit, or transfer the `MINTER_ROLE` to a multi-signature wallet or a controlled contract that enforces specific minting policies. This would introduce checks and balances to prevent uncontrolled token issuance.
StatusUnresolved
Low

Reliance on External Axelar Interchain Token Service

L-01The contract integrates with the Axelar Interchain Token Standard and relies on the `_interchainTokenService` address for interchain functionality, specifically for deriving the `interchainTokenId`. The security and availability of this external service are critical to the token's cross-chain operations (7.6 External). Any vulnerabilities or disruptions in the Axelar service could indirectly impact the token's intended functionality.
IssueThe contract integrates with the Axelar Interchain Token Standard and relies on the `_interchainTokenService` address for interchain functionality, specifically for deriving the `interchainTokenId`. The security and availability of this external service are critical to the token's cross-chain operations (7.6 External). Any vulnerabilities or disruptions in the Axelar service could indirectly impact the token's intended functionality.
FixAcknowledge and continuously monitor the security and operational status of the Axelar Interchain Token Service. While this is an inherent dependency and not a direct vulnerability in the Recall contract's logic, understanding and managing this external risk is crucial.
StatusUnresolved
Info

Fixed Deployer Address for Interchain Token ID Derivation

I-01The `deployer` address is set once during `initialize` to `msg.sender` and is subsequently used in the `interchainTokenId()` function to derive the unique token identifier via the Axelar Interchain Token Service. This means the `deployer` address is a permanently fixed component in the token's interchain identity (7.1 Architecture).
IssueThe `deployer` address is set once during `initialize` to `msg.sender` and is subsequently used in the `interchainTokenId()` function to derive the unique token identifier via the Axelar Interchain Token Service. This means the `deployer` address is a permanently fixed component in the token's interchain identity (7.1 Architecture).
FixNo direct security recommendation. This is an architectural design choice for Axelar integration. Ensure that the `deployer` address used during initialization is a stable and known entity, as its identity is permanently linked to the token's interchain ID.
StatusUnresolved

Category Ratings

TechnicalMedium6/10

The contract demonstrates strong technical foundations (7.1 Architecture, 7.2 Code Security). It utilizes OpenZeppelin's upgradeable contracts for ERC20, AccessControl, Pausable, and UUPS, ensuring robust and audited components. The implementation of `_spendAllowance` correctly handles `type(uint256).max` for infinite allowances, preventing potential underflow issues. No reentrancy vectors or complex arithmetic vulnerabilities were identified.

GovernanceHigh1/10

The contract implements robust access control via OpenZeppelin's `AccessControlUpgradeable` (7.3 Access Control). However, all critical roles (ADMIN_ROLE, MINTER_ROLE, PAUSER_ROLE) are initially granted to the deployer's EOA (7.5 Governance). This centralization creates a single point of failure for upgrades, unpausing, and token minting (7.4 Economic). A compromise of this single address could lead to full control over the token supply and contract logic.

UpgradesHigh1/10

The contract correctly implements the UUPSUpgradeable proxy pattern (7.7 Upgrades), which is a secure and widely adopted standard for upgradeability. The `_authorizeUpgrade` function is appropriately restricted to the `ADMIN_ROLE`, ensuring that only authorized entities can initiate upgrades. The primary risk associated with upgrades stems from the centralized control of the `ADMIN_ROLE`, which could allow a compromised address to deploy malicious logic.

Security Checklist

1/5 checks passed
Contract VerifiedPass
Ownership Renounced?
No Mint FunctionFail
Liquidity LockedFail
Not a ProxyFail

Proxy Upgrade Controls

Proxy TypeEip1967 Uups
ImplementationVerified source
Upgrades (30d)0 · stable

Holder Composition

62.1% in top 10
28.9% in wallets33.2% in contracts
Effective Concentration42.1%

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

$562.2K across 7 pairs
AerodromeUSDCanalysed$561.3K99.8%AerodromeUSDC$7860.1%Hydrex CLAMMUSDC$1190.0%Uniswap v4ETH$490.0%AerodromeUSDC$50.0%Uniswap v4ETH$10.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 Holder54.9%
Top-3 Unlocked100.0%

Key Addresses

4 addresses
Deployer
0xe863…17dc
Unlocked LP Held By
0xfa2b…52bb0x73e5…91ad0xaf7b…00ea

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

What Raised This Score

10 factors
  • Ownership status UNKNOWN (owner could not be resolved)
  • Mintable supply — no cap found, dilution unbounded
  • Proxy contract (upgradeable — admin can replace logic)
  • Top-10 concentration > 30% (62.1% total → 42.1% effective; 28.9% in EOAs, 33.2% in contracts — moderate)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 54.9% (independent LP — depth risk, pool = 100% of DEX liquidity)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 100% of DEX liquidity)
  • 1 High finding(s) from audit
  • 2 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

Frequently Asked Questions

Is Recall a scam?

Based on automated analysis, Recall scores 64/100 (High Risk) on our risk scale. No honeypot was detected, but always verify independently before investing.

Is Recall safe to buy?

Our scanner flagged a risk score of 64/100. Ownership has not been renounced, which is a risk factor. DYOR before purchasing any token.

Has Recall been audited?

The contract has not been verified on-chain. Verification is not the same as a full security audit. Use Quantum Audit's free tool to run a deeper analysis of the contract code.

Related Audits

6 more on the record
VANRYCritical RiskXMAQUINA (DEUS)Critical RiskTownsCritical RiskICPCritical RiskGAME by Virtuals (GAME)Critical RiskThe White Wolf (WOLF)Critical Risk

Would You Like a More Detailed Audit of Recall?

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

Get Detailed Audit