Quantum Audit Logo

Is Motoswap a Scam?

Early-stage security check — honeypot & rug-pull analysis

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

Motoswap MOTO
0xbd96…35e0
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 7d ago 1 audit on record New Launch · 14h old
DexScreener ↗
How is this score calculated? → Critical Risk
Executive SummaryAI Copilot

The MotoToken contract implements an ERC20 token with a unique 'gate' mechanism designed to control trading access. The audit identified critical issues related to the misuse of EIP-1153 transient storage for authorization, which undermines the intended persistence of authorizations, and a potential bypass in the gate mechanism if not properly initialized. High-severity concerns include the irreversible nature of authorization revocation once trading commences and significant centralized control held by the DEPLOYER address. Addressing these findings is crucial for the security and intended functionality of the token.

2 Critical2 High1 Medium1 Low1 Informational
! Early-stage analysis. This token has limited on-chain history (14h old). New tokens carry elevated risk — data may change rapidly. Always verify independently before investing.
Volume 24h
$5.83M
Liquidity
$752.3K
Price
$0.003339
Token Age
14h
Top 10 Holders
78.8%

Security Findings

2 Crit2 High1 Med1 Low1 Info
Critical

Misuse of Transient Storage for Persistent Authorization State

C-01The `_authorize` function, which is used to grant authorization, stores the authorization state in transient storage (`tstore(slot, 1)`). Transient storage is cleared at the end of each transaction. This means an authorization granted via `_authorize` is only valid for the *current transaction* in which it was called. This fundamentally contradicts the presence of `authDeadline` (a timestamp for persistent validity) and the `authorizationRevoked` mapping (for persistent revocation), which imply a desire for authorizations to persist across transactions. If the intent was for authorizations to persist until their deadline or revocation, transient storage is the incorrect mechanism, leading t…
IssueThe `_authorize` function, which is used to grant authorization, stores the authorization state in transient storage (`tstore(slot, 1)`). Transient storage is cleared at the end of each transaction. This means an authorization granted via `_authorize` is only valid for the *current transaction* in which it was called. This fundamentally contradicts the presence of `authDeadline` (a timestamp for persistent validity) and the `authorizationRevoked` mapping (for persistent revocation), which imply a desire for authorizations to persist across transactions. If the intent was for authorizations to persist until their deadline or revocation, transient storage is the incorrect mechanism, leading t…
FixIf persistent authorization is required, use regular storage (`sstore`/`sload`) to store authorization status and deadlines. If per-transaction authorization is the explicit intent, clarify this in documentation and remove misleading elements like `authDeadline` and `authorizationRevoked` from persistent storage, as they would not effectively control the transient authorization.
StatusUnresolved
Critical

Gate Mechanism Bypass if `armGate` Not Called

C-02The `tradingOpen()` function contains the logic `if (!gateArmed) return true;`. This means if the `armGate` function is never called by the `DEPLOYER`, the `gateArmed` flag remains `false`, and `tradingOpen()` will always return `true`. This effectively bypasses all gate mechanisms, including `HARD_OPEN` and `openAt`, allowing trading to commence immediately upon deployment, contrary to the apparent intent of a controlled opening.
IssueThe `tradingOpen()` function contains the logic `if (!gateArmed) return true;`. This means if the `armGate` function is never called by the `DEPLOYER`, the `gateArmed` flag remains `false`, and `tradingOpen()` will always return `true`. This effectively bypasses all gate mechanisms, including `HARD_OPEN` and `openAt`, allowing trading to commence immediately upon deployment, contrary to the apparent intent of a controlled opening.
FixEnsure `armGate` is called as part of the deployment and initialization process. Consider modifying `tradingOpen` to only return `true` if `gateArmed` is true AND other conditions are met, e.g., `return gateArmed && (block.timestamp >= HARD_OPEN || (o != 0 && block.timestamp >= o));`
StatusUnresolved
High

Irreversible Authorization Revocation After Trading Opens

H-01The `setAuthorizationRevoked` function, which allows the `DEPLOYER` to revoke authorizations, includes the check `if (tradingOpen()) revert AlreadyOpen();`. This means that once `tradingOpen()` returns `true` (either due to `HARD_OPEN` being reached, `openAt` being set and passed, or `armGate` not being called), the `DEPLOYER` loses the ability to revoke any authorizations. Given that the `_authorize` function itself becomes inactive once `tradingOpen()` is true, the `setAuthorizationRevoked` function is only relevant *before* trading opens. If the `GATE_SIGNER` key is compromised *before* trading opens, and malicious accounts are authorized, these authorizations cannot be persistently revo…
IssueThe `setAuthorizationRevoked` function, which allows the `DEPLOYER` to revoke authorizations, includes the check `if (tradingOpen()) revert AlreadyOpen();`. This means that once `tradingOpen()` returns `true` (either due to `HARD_OPEN` being reached, `openAt` being set and passed, or `armGate` not being called), the `DEPLOYER` loses the ability to revoke any authorizations. Given that the `_authorize` function itself becomes inactive once `tradingOpen()` is true, the `setAuthorizationRevoked` function is only relevant *before* trading opens. If the `GATE_SIGNER` key is compromised *before* trading opens, and malicious accounts are authorized, these authorizations cannot be persistently revo…
FixRemove the `if (tradingOpen()) revert AlreadyOpen();` check from `setAuthorizationRevoked` to allow the `DEPLOYER` to revoke authorizations at any time, regardless of the trading status. This provides a crucial emergency mechanism in case of `GATE_SIGNER` compromise during the pre-trading phase.
StatusUnresolved
High

Centralized Control by `DEPLOYER`

H-02The `DEPLOYER` address holds significant centralized control over critical aspects of the token's gate mechanism, including `armGate`, `renounceArmPower`, `openNow`, and `setAuthorizationRevoked`. While `renounceArmPower` exists, the initial concentration of power in a single EOA (Externally Owned Account) represents a single point of failure. A compromise of the `DEPLOYER`'s private key could lead to unauthorized manipulation of the gate, premature opening of trading, or inability to revoke authorizations (as per H-01).
IssueThe `DEPLOYER` address holds significant centralized control over critical aspects of the token's gate mechanism, including `armGate`, `renounceArmPower`, `openNow`, and `setAuthorizationRevoked`. While `renounceArmPower` exists, the initial concentration of power in a single EOA (Externally Owned Account) represents a single point of failure. A compromise of the `DEPLOYER`'s private key could lead to unauthorized manipulation of the gate, premature opening of trading, or inability to revoke authorizations (as per H-01).
FixImplement a multi-signature wallet (e.g., Gnosis Safe) for the `DEPLOYER` role to distribute control and reduce the risk associated with a single point of failure. Consider a timelock for sensitive operations to allow for community review or emergency intervention.
StatusUnresolved
Medium

`GATE_SIGNER` Single Point of Failure

M-01The `GATE_SIGNER` is a single address responsible for signing off-chain authorizations. If this key is compromised, an attacker could sign arbitrary authorizations, potentially granting access to unauthorized accounts. While `authDeadline` provides a time limit for each signature, and `setAuthorizationRevoked` (if fixed, see H-01) could revoke persistent authorizations, the immediate impact of a compromised `GATE_SIGNER` is high.
IssueThe `GATE_SIGNER` is a single address responsible for signing off-chain authorizations. If this key is compromised, an attacker could sign arbitrary authorizations, potentially granting access to unauthorized accounts. While `authDeadline` provides a time limit for each signature, and `setAuthorizationRevoked` (if fixed, see H-01) could revoke persistent authorizations, the immediate impact of a compromised `GATE_SIGNER` is high.
FixConsider implementing a multi-signature scheme for the `GATE_SIGNER` role or a mechanism to rotate the `GATE_SIGNER` address by a trusted entity (e.g., the `DEPLOYER` or a governance contract).
StatusUnresolved
Low

`Reentrancy()` Error Defined but No Guard Implemented

L-01The contract defines a `Reentrancy()` error and a `_LOCK_SLOT` constant, suggesting an intention to implement a reentrancy guard. However, no reentrancy guard mechanism (e.g., using `_LOCK_SLOT` with `tstore`/`tload` or a mutex pattern) is observed in the provided functions, particularly around external calls like `_transfer` (which calls `_callOptionalReturn` in ERC20). While no immediate reentrancy vulnerability is apparent in the provided snippet, the absence of an explicit guard despite the error definition could indicate an incomplete implementation or an oversight.
IssueThe contract defines a `Reentrancy()` error and a `_LOCK_SLOT` constant, suggesting an intention to implement a reentrancy guard. However, no reentrancy guard mechanism (e.g., using `_LOCK_SLOT` with `tstore`/`tload` or a mutex pattern) is observed in the provided functions, particularly around external calls like `_transfer` (which calls `_callOptionalReturn` in ERC20). While no immediate reentrancy vulnerability is apparent in the provided snippet, the absence of an explicit guard despite the error definition could indicate an incomplete implementation or an oversight.
FixIf reentrancy protection is intended, implement a robust reentrancy guard for functions that make external calls and modify state. If not intended, remove the unused error and slot definition to avoid confusion.
StatusUnresolved
Info

`owner()` Function Returns `address(0)`

I-01The `owner()` function is overridden to always return `address(0)`. This deviates from the common `Ownable` pattern where `owner()` typically returns the address with administrative privileges. While a valid design choice, it might lead to confusion for users or tools expecting a standard `Ownable` implementation, especially given the presence of a `DEPLOYER` role with significant control.
IssueThe `owner()` function is overridden to always return `address(0)`. This deviates from the common `Ownable` pattern where `owner()` typically returns the address with administrative privileges. While a valid design choice, it might lead to confusion for users or tools expecting a standard `Ownable` implementation, especially given the presence of a `DEPLOYER` role with significant control.
FixDocument this design choice clearly to avoid confusion. Ensure that any external integrations or tools are aware that `address(0)` is the intended return value for `owner()`.
StatusUnresolved

Category Ratings

TechnicalMedium4/10

The contract demonstrates good adherence to OpenZeppelin standards for ERC20 and ERC20Permit, and includes robust checks for Uniswap V2 pair derivation in `armGate`. EIP-1153 transient storage availability is also verified. However, critical technical flaws exist, such as the misuse of transient storage for authorization, rendering persistent authorization ineffective (7.2 Code Security). Additionally, the `tradingOpen()` logic can be bypassed if the `armGate` function is not called, allowing premature trading (7.1 Architecture).

GovernanceHigh3/10

The contract's economic model centers around a controlled token launch via a 'gate' mechanism. The `DEPLOYER` holds significant power to arm the gate, open trading, and initially revoke authorizations (7.5 Governance). This centralization, while intended for launch control, presents a single point of failure. A critical economic risk arises from the inability to revoke authorizations once trading is open, potentially allowing a compromised `GATE_SIGNER` to grant unlimited access (7.4 Economic).

UpgradesMedium6/10

The MotoToken contract is not designed as an upgradeable proxy. It is a standard implementation contract, meaning its logic cannot be modified after deployment. This eliminates upgrade-related risks such as proxy misconfigurations or logic bugs introduced during upgrades (7.7 Upgrades).

Security Checklist

5/5 checks passed
Contract VerifiedPass
Ownership RenouncedPass
No Mint FunctionPass
Liquidity LockedPass
Not a ProxyPass
HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

78.8% in top 10
9.4% in wallets69.4% in contracts
Effective Concentration37.2%

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

$779.6K across 3 pairs
Uniswap v2WETHanalysed$752.3K96.5%Uniswap v2USDT$14.1K1.8%Uniswap v2USDC$13.2K1.7%

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

LP Locked78.3% · Null Address, TeamFinance
Top-1 Unlocked Holder21.6%
Top-3 Unlocked21.7%

Key Addresses

4 addresses
Deployer
0xbb9d…a86d
Unlocked LP Held By
0x51e6…aca40xf385…5f850x6ac4…6198

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

What Raised This Score

6 factors
  • Top-10 concentration > 30% (78.8% total → 37.2% effective; 9.4% in EOAs, 69.4% in contracts — moderate)
  • Token age < 24h (brand new — bot activity, unproven)
  • 2 Critical finding(s) from audit
  • 2 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
DAPPOS (DOS)Critical RiskICPCritical RiskPancakeSwap (CAKE)Critical RiskEveripedia IQ (IQ)Critical RiskThreshold Network Token (T)Critical RiskFARM Reward Token (FARM)Critical Risk

Would You Like a More Detailed Audit of Motoswap?

This token is brand new. Run a deeper AI-powered analysis of the contract code — free and instant.

Get Detailed Audit