Quantum Audit Logo
Launch App

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

Is Sally Safe?

A1CBase
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
Medium RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical5/10Governance3/10Upgrades1/10Checks passed4 of 7Findings1 Critical · 2 High · 2 Medium · 1 Low6
SummaryAI Copilot

The AgentKey contract, an upgradeable ERC20 token with staking and fee distribution mechanisms, leverages OpenZeppelin's secure libraries and reentrancy guards.

Read the full analysis
What raised the score
  • Ownership status UNKNOWN
  • Proxy contract
  • Non-standard proxy storage
  • Top-10 concentration > 20%
  • 1 Critical finding(s) from audit
  • 2 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)
  • Proxy contract (upgradeable — admin can replace logic)
  • Non-standard proxy storage (Etherscan-confirmed)
  • Top-10 concentration > 20% (56.1% total → 28.1% effective; 9.3% in EOAs, 46.8% in contracts — mild)
  • 1 Critical finding(s) from audit
  • 2 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 44 of 7 checks passed
Contract verifiedVerified
OwnershipUnknown
MintNo mint
Liquidity lockLocked
UpgradeabilityUpgradeable
HoneypotNone found
Buy / sell tax0% / 3%

Holders

as of audit · Sep 4, 2026
46.8%Contracts9.3%43.9%Everyone else
46.8%Contracts9.3%43.9%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
56.1%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking46.8%
  • Walletsanonymous holders, free to sell9.3%
  • Everyone elsethe rest of the supply43.9%
Effective concentrationwhat the score reads28.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$316.2K

The risk score reads depth across every pair.

LP tokensLocked

The LP tokens of the analysed pool are locked or burned.

Analysed pool$316.2KShare of depth100.0%
LP Burned100.0% · ≈ permanent lock
LP Locked100.0% · Null Address
Unlocked LP held by
0x16aa…7e1b0xd5fd…b81c0x2ee5…5e36

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

Security Findings

1 Critical2 High2 Medium1 Low
Critical

Critical Vulnerability: Incorrect _approve Function Signature

In the _swapToETH function, the call _approve(address(this), address(router), _amount, false) attempts to approve tokens for the Uniswap router. However, the standard OpenZeppelin ERC20Upgradeable._approve function, which this contract inherits, only accepts three arguments (owner, spender, value). The inclusion of a fourth false argument results in an incorrect function signature. This will cause a compilation error or, if a custom _approve with this signature exists (which is not provided in the standard imports), it would lead to an unintended and potentially insecure behavior. This is a fundamental bug that prevents the core fee-swapping mechanism from functioning correc…C-01

Issue

In the _swapToETH function, the call _approve(address(this), address(router), _amount, false) attempts to approve tokens for the Uniswap router. However, the standard OpenZeppelin ERC20Upgradeable._approve function, which this contract inherits, only accepts three arguments (owner, spender, value). The inclusion of a fourth false argument results in an incorrect function signature. This will cause a compilation error or, if a custom _approve with this signature exists (which is not provided in the standard imports), it would lead to an unintended and potentially insecure behavior. This is a fundamental bug that prevents the core fee-swapping mechanism from functioning correc…

Fix

Correct the _approve call to match the standard OpenZeppelin ERC20Upgradeable._approve signature: _approve(address(this), address(router), _amount). If a custom _approve is intended, its implementation must be provided and thoroughly reviewed.

Status

Unresolved

High

Reentrancy Vulnerability in Fee Distribution

The _update function, which is called by transfer and transferFrom, is not protected by a reentrancy guard. Inside _update, if _to == pair, it performs a super._update call, then calls _handleFee, and then another super._update. The _handleFee function itself is protected by nonReentrant, but it makes external calls (_feeHandler.pay, _safeETHTransfer, router.swapExactTokensForETH) between internal state updates. An attacker could re-enter the transfer or transferFrom function during these external calls, potentially manipulating balances or fees before the full _update sequence is completed, leading to double-spending of tokens or incorrect fee calculations.H-01

Issue

The _update function, which is called by transfer and transferFrom, is not protected by a reentrancy guard. Inside _update, if _to == pair, it performs a super._update call, then calls _handleFee, and then another super._update. The _handleFee function itself is protected by nonReentrant, but it makes external calls (_feeHandler.pay, _safeETHTransfer, router.swapExactTokensForETH) between internal state updates. An attacker could re-enter the transfer or transferFrom function during these external calls, potentially manipulating balances or fees before the full _update sequence is completed, leading to double-spending of tokens or incorrect fee calculations.

Fix

Apply the nonReentrant modifier to the _update function or ensure that all external calls are made after all state changes are finalized within the _update and _handleFee logic. A common pattern is to use a 'checks-effects-interactions' approach.

Status

Unresolved

High

Lack of Slippage Protection in Uniswap Swaps

The _swapToETH function executes router.swapExactTokensForETH with minAmountOut set to 0. This means the contract accepts any amount of ETH in return for the swapped tokens, regardless of the current market price. This vulnerability exposes the contract to sandwich attacks, front-running, and general price manipulation, where malicious actors can exploit the lack of slippage protection to extract value from the fee collection mechanism, leading to significant financial losses for the protocol.H-02

Issue

The _swapToETH function executes router.swapExactTokensForETH with minAmountOut set to 0. This means the contract accepts any amount of ETH in return for the swapped tokens, regardless of the current market price. This vulnerability exposes the contract to sandwich attacks, front-running, and general price manipulation, where malicious actors can exploit the lack of slippage protection to extract value from the fee collection mechanism, leading to significant financial losses for the protocol.

Fix

Implement robust slippage protection by calculating a reasonable minAmountOut based on the expected exchange rate and a predefined slippage tolerance. This value should be passed to swapExactTokensForETH to ensure that swaps only execute if the received amount of ETH is above a certain threshold.

Status

Unresolved

Medium

Immutability of Critical Configuration Parameters

Several key operational parameters, including adminSellFeePercent, creatorSellFeePercent, treasury, router, and ansTokenID, are set during the initialize function and declared as public but without setter functions. This makes them immutable after deployment. While immutability can reduce governance attack surface, it also removes the flexibility to adjust fees in response to market changes, update the treasury address, or change the Uniswap router if a vulnerability or better alternative emerges. This could lead to operational rigidity or necessitate a full contract upgrade for minor parameter adjustments.M-01

Issue

Several key operational parameters, including adminSellFeePercent, creatorSellFeePercent, treasury, router, and ansTokenID, are set during the initialize function and declared as public but without setter functions. This makes them immutable after deployment. While immutability can reduce governance attack surface, it also removes the flexibility to adjust fees in response to market changes, update the treasury address, or change the Uniswap router if a vulnerability or better alternative emerges. This could lead to operational rigidity or necessitate a full contract upgrade for minor parameter adjustments.

Fix

Evaluate whether these parameters truly need to be immutable. For parameters that might require future adjustments (e.g., fee percentages, treasury address, router address), consider implementing controlled setter functions, possibly with a timelock, to allow for secure updates.

Status

Unresolved

Medium

Centralized Control and Potential Single Points of Failure

The _factory and bondingCurve addresses hold significant control over the contract's lifecycle and initial operations. initialize is restricted to _factory, while launch and setPair are restricted to bondingCurve. Additionally, pre-launch transferFrom is restricted to bondingCurve. If these controlling addresses are compromised, it could lead to unauthorized contract initialization, manipulation of the trading pair, or unauthorized token transfers before launch.M-02

Issue

The _factory and bondingCurve addresses hold significant control over the contract's lifecycle and initial operations. initialize is restricted to _factory, while launch and setPair are restricted to bondingCurve. Additionally, pre-launch transferFrom is restricted to bondingCurve. If these controlling addresses are compromised, it could lead to unauthorized contract initialization, manipulation of the trading pair, or unauthorized token transfers before launch.

Fix

Ensure that the private keys or multi-signature wallets controlling _factory and bondingCurve are secured with the highest standards. Consider implementing a multi-signature wallet for these critical roles to distribute control and reduce the risk associated with a single point of failure.

Status

Unresolved

Low

Potential Denial of Service in Fee Distribution

The _handleFee function attempts to pay the adminAmount to _feeHandler via _feeHandler.pay{value: adminAmount}(). If the _feeHandler contract is malicious, incorrectly implemented, or enters a state where its pay() function consistently reverts (e.g., due to an internal error or a block on receiving ETH), it could cause all transfers to the pair to fail, effectively halting the fee collection mechanism and disrupting normal token operations.L-01

Issue

The _handleFee function attempts to pay the adminAmount to _feeHandler via _feeHandler.pay{value: adminAmount}(). If the _feeHandler contract is malicious, incorrectly implemented, or enters a state where its pay() function consistently reverts (e.g., due to an internal error or a block on receiving ETH), it could cause all transfers to the pair to fail, effectively halting the fee collection mechanism and disrupting normal token operations.

Fix

Implement robust error handling for external calls. Consider using a try/catch block around the _feeHandler.pay() call to gracefully handle reverts, perhaps by logging the failure and attempting to send the funds to a fallback address or accumulating them for later manual recovery. Alternatively, ensure _feeHandler is a trusted and audited contract.

Status

Unresolved

Analysis

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

The AgentKey contract, an upgradeable ERC20 token with staking and fee distribution mechanisms, leverages OpenZeppelin's secure libraries and reentrancy guards. However, a critical vulnerability was identified where the _approve function is called with an incorrect signature, preventing the core fee-swapping functionality. Additionally, the fee distribution logic is susceptible to reentrancy, and Uniswap swaps lack slippage protection, exposing the protocol to significant financial risks. Centralized control points and immutable configuration parameters also present operational and governance considerations.

Technical5/10Medium risk

The contract leverages OpenZeppelin's ERC20BurnableUpgradeable and ReentrancyGuard for foundational security, and uses a specific Solidity version (0.8.27). However, a critical bug exists in the _swapToETH function where _approve is called with an incorrect number of arguments, which would prevent compilation or lead to unexpected behavior (7.2 Code Security). Additionally, the _update function, which handles token transfers and fee collection, is susceptible to reentrancy due to external calls within its execution flow (7.2 Code Security), and the Uniswap swap lacks slippage protection, exposing the protocol to significant value loss from front-running and sandwich attacks (7.4 Economic).

Governance3/10High risk

The contract's economic model includes a subscription/cooldown mechanism and a fee distribution system. Key parameters like fee percentages (adminSellFeePercent, creatorSellFeePercent) and the treasury address are immutable after initialization, which limits flexibility for future adjustments (7.4 Economic). Initial contract setup and critical operations like launch and setPair are controlled by specific _factory and bondingCurve addresses, introducing centralization risks (7.3 Access Control, 7.5 Governance).

Upgrades1/10High risk

The contract is designed as an upgradeable implementation using OpenZeppelin's ERC20BurnableUpgradeable and the initializer modifier, following standard proxy patterns. Immutable variables are correctly set in the constructor, while mutable state is handled in initialize. No immediate upgrade safety issues were identified, but the immutability of certain configuration parameters (e.g., fee percentages) means that any changes to these would necessitate a full contract upgrade, rather than a simple parameter adjustment (7.7 Upgrades).

Final RecommendationWhat to do about this score

Immediate attention is required to rectify the critical _approve function signature error, as this issue fundamentally breaks the contract's fee-swapping mechanism.

Furthermore, the reentrancy vulnerability in the fee distribution logic and the absence of slippage protection in Uniswap swaps must be addressed to safeguard against potential financial exploits and value erosion. Consider implementing controlled setter functions for critical parameters to enhance operational adaptability without compromising security, and strengthen the security protocols surrounding the centralized control addresses.

Contract & Record

1 audit on record
TypeVault, Router, Token
NetworkBase
Token age1y
Contract0x1f1c…ad69
Deployer0x675d…d25e
Proxy Upgrade Controls
Proxy TypeEtherscan Detected Custom
ImplementationVerified source
Upgrades (30d)0 · stable
Badge for your website
Sally 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, 202653Medium
  2. Aug 30, 202662Medium

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

Frequently Asked Questions

What is the A1C contract address?

The Sally (A1C) contract on Base is 0x1f1c695f6b4a3f8b05f2492cef9474afb6d6ad69. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.

Is Sally a scam?

Quantum Audit's risk score for Sally is 53/100 (Medium risk) as of Sep 4, 2026, computed by a deterministic function from on-chain facts — Contract verified: Verified; Mint: No mint; Liquidity lock: Locked; Upgradeability: Upgradeable; Honeypot: None found; Buy / sell tax: 0% / 3%. A score is a dated snapshot of those facts, not a guarantee; each one is listed on this page.

Is A1C liquidity locked?

Liquidity lock: Locked (as of Sep 4, 2026). Total DEX liquidity: $316.2K.

Who holds A1C?

As of Sep 4, 2026, the 10 largest holders own 56.1% of the supply. The Holders section on this page shows who they are by holder type.

Related Audits

6 more on the recordAll audits
AUTONOMOPOLYAUTONO · Base53MediumSolanaSOL · Base53MediumTAOTBase53MediumCheckmateCHECK · Base53MediumSoSoValueSOSO · Base53MediumOFCBase53Medium

Would You Like a More Detailed Audit of Sally?

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