Quantum Audit Logo
Launch App

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

Is Recall Safe?

RECALLBase
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 · 2 audits on record
Chart
High RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical6/10Governance1/10Upgrades1/10Checks passed1 of 5Findings1 High · 2 Medium · 1 Low · 1 Info5
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.

Read the full analysis
What raised the score
  • Ownership status UNKNOWN
  • Mintable supply — no cap found, dilution unbounded
  • Proxy contract
  • Top-10 concentration > 30%
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 54.9%
  • LP top3 unlocked holders = 100.0%
  • 1 High finding(s) from audit
  • 2 Medium finding(s) from audit
  • 1 Low finding(s) from audit
Exact 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

Security Checklist

as of audit · Sep 41 of 5 checks passed
Contract verifiedVerified
OwnershipUnknown
MintMintable
Liquidity lockNot locked
UpgradeabilityUpgradeable

Holders

as of audit · Sep 4, 2026
33.2%Contracts28.9%Wallets37.9%Everyone else
33.2%Contracts28.9%Wallets37.9%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
62.1%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking33.2%
  • Walletsanonymous holders, free to sell28.9%
  • Everyone elsethe rest of the supply37.9%
Effective concentrationwhat the score reads42.1%
How holder types affect the score

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.

Holder balances as recorded by the audit of Sep 4, 2026

Liquidity

as of audit · Sep 4$562.2K across 7 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$561.3KShare of depth99.8%
Top-1 Unlocked Holder54.9%
Top-3 Unlocked100.0%
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.

Security Findings

1 High2 Medium1 Low1 Info
High

Centralized Control of Critical Roles

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

Issue

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

Fix

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

Status

Unresolved

Medium

Pausability as a Centralized Denial-of-Service Vector

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

Issue

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

Fix

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

Status

Unresolved

Medium

Centralized Minting Authority

The 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.M-02

Issue

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

Fix

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

Status

Unresolved

Low

Reliance on External Axelar Interchain Token Service

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

Issue

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

Fix

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

Status

Unresolved

Info

Fixed Deployer Address for Interchain Token ID Derivation

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

Issue

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

Fix

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

Status

Unresolved

Analysis

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

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.

Technical6/10Medium risk

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.

Governance1/10High risk

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.

Upgrades1/10High risk

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.

Final RecommendationWhat to do about this score

To enhance the security posture of the Recall token contract, it is strongly recommended to decentralize control over critical administrative roles.

Transfer the ADMIN_ROLE, MINTER_ROLE, and PAUSER_ROLE from the initial deployer EOA to a robust multi-signature wallet or a decentralized autonomous organization (DAO) governance mechanism. This will mitigate the significant single-point-of-failure risks identified in this report and improve the overall resilience against malicious actors or key compromise.

Contract & Record

2 audits on record
TypeERC1967Proxy
NetworkBase
Token age1y
Contract0x1f16…0671
Deployer0xe863…17dc
Proxy Upgrade Controls
Proxy TypeEip1967 Uups
ImplementationVerified source
Upgrades (30d)0 · stable
Badge for your website
Recall 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, 202672High
  2. Jul 27, 202674High
  3. Jul 26, 202664Medium

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

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 recordAll audits
VANRYBase72HighWrapped iShares 0-3 Month Treasury Bond ETF ST0xWTSGOV · Base72HighConwayResearchCONWAY · Base72HighXMAQUINADEUS · Base71HighTownsBase71HighICPBase71High

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