Quantum Audit Logo

Is Syrup Token Safe?

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

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

Syrup Token SYRUP
0x643c…2d66
Ethereum Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Critical Risk
Executive SummaryAI Copilot

The MapleToken contract, serving as the implementation for a UUPS proxy, provides standard ERC-20 functionality with additional minting and burning capabilities controlled by designated modules and a governor. While access control for critical functions is robust, a critical upgradeability flaw exists due to incorrect handling of state variables in the inherited ERC20Proxied contract. Significant reliance on an external Globals contract introduces a high external dependency risk. Additionally, unchecked arithmetic for balance additions presents a theoretical overflow risk, and standard ERC-20 front-running concerns are present.

1 Critical1 High1 Medium1 Low
Volume 24h
$351.0K
Liquidity
$2.57M
Price
$0.21
Token Age
1y
Top 10 Holders
45.6%

Security Findings

1 Crit1 High1 Med1 Low
Critical

UUPS Implementation State Variable Mismanagement

C-01The `ERC20Proxied` abstract contract, inherited by `MapleToken`, declares storage variables such as `name`, `symbol`, `decimals`, `totalSupply`, `balanceOf`, `allowance`, and `nonces`. In a UUPS proxy architecture, these state variables must reside in the proxy's storage, not directly in the implementation contract. Declaring them in the implementation means their values are stored in the implementation's storage, which is not persistent across upgrades. An upgrade to a new implementation would result in the complete loss of all token state, including user balances and allowances.
IssueThe `ERC20Proxied` abstract contract, inherited by `MapleToken`, declares storage variables such as `name`, `symbol`, `decimals`, `totalSupply`, `balanceOf`, `allowance`, and `nonces`. In a UUPS proxy architecture, these state variables must reside in the proxy's storage, not directly in the implementation contract. Declaring them in the implementation means their values are stored in the implementation's storage, which is not persistent across upgrades. An upgrade to a new implementation would result in the complete loss of all token state, including user balances and allowances.
FixRefactor `ERC20Proxied` to manage all ERC-20 state variables using explicit storage slots, similar to how `GLOBALS_SLOT` and `IMPLEMENTATION_SLOT` are handled. This ensures that the state is stored in the proxy's persistent storage and remains intact across upgrades. Alternatively, consider using a well-established UUPS base contract that correctly handles ERC-20 state for proxy implementations.
StatusUnresolved
High

Centralized Control and High External Dependency on Globals Contract

H-01The `MapleToken` contract relies heavily on an external `Globals` contract for critical access control functions, specifically for determining the `governor()` and validating/unscheduling `onlyScheduled` calls. If the `Globals` contract is compromised, misconfigured, or contains vulnerabilities, it could directly impact the security and functionality of `MapleToken`, potentially allowing unauthorized `addModule`, `removeModule`, or other future governor-controlled actions.
IssueThe `MapleToken` contract relies heavily on an external `Globals` contract for critical access control functions, specifically for determining the `governor()` and validating/unscheduling `onlyScheduled` calls. If the `Globals` contract is compromised, misconfigured, or contains vulnerabilities, it could directly impact the security and functionality of `MapleToken`, potentially allowing unauthorized `addModule`, `removeModule`, or other future governor-controlled actions.
FixConduct a thorough security audit of the `Globals` contract to ensure its robustness, immutability (if intended), and proper access control mechanisms. Implement robust monitoring for the `Globals` contract's state and ownership. Consider implementing emergency pause mechanisms or circuit breakers within `MapleToken` that can be triggered independently of `Globals` in extreme situations to mitigate cascading risks.
StatusUnresolved
Medium

Unchecked Arithmetic for Balance Additions

M-01The `_mint` and `_transfer` internal functions utilize `unchecked` blocks for `balanceOf[recipient_] += amount_`. While Solidity 0.8.x generally provides checked arithmetic, `unchecked` blocks bypass these checks for gas optimization. In a highly improbable scenario where `balanceOf[recipient_]` is very close to `type(uint256).max` and `amount_` is non-zero, an overflow could occur, causing the recipient's balance to wrap around to a small number. This could lead to a loss of funds for the recipient or unexpected token economics.
IssueThe `_mint` and `_transfer` internal functions utilize `unchecked` blocks for `balanceOf[recipient_] += amount_`. While Solidity 0.8.x generally provides checked arithmetic, `unchecked` blocks bypass these checks for gas optimization. In a highly improbable scenario where `balanceOf[recipient_]` is very close to `type(uint256).max` and `amount_` is non-zero, an overflow could occur, causing the recipient's balance to wrap around to a small number. This could lead to a loss of funds for the recipient or unexpected token economics.
FixRe-evaluate the necessity of `unchecked` blocks for `balanceOf` additions. While gas savings are a consideration, the potential for an overflow, however rare, might outweigh the benefit. If `unchecked` is deemed essential, ensure that the system's design accounts for the theoretical possibility of balance overflows and that total supply and individual balances are monitored for anomalies.
StatusUnresolved
Low

Standard ERC-20 Front-Running Risks

L-01Standard ERC-20 functions such as `approve`, `increaseAllowance`, `decreaseAllowance`, and `permit` are susceptible to front-running attacks. For instance, a user calling `approve(spender, newAmount)` could be front-run by a malicious `spender` who quickly spends the `oldAmount` before the `newAmount` is set, effectively allowing the `spender` to spend `oldAmount + newAmount`. Similarly, `permit` can be front-run on the `deadline` or `nonces` to invalidate a signature or execute it prematurely.
IssueStandard ERC-20 functions such as `approve`, `increaseAllowance`, `decreaseAllowance`, and `permit` are susceptible to front-running attacks. For instance, a user calling `approve(spender, newAmount)` could be front-run by a malicious `spender` who quickly spends the `oldAmount` before the `newAmount` is set, effectively allowing the `spender` to spend `oldAmount + newAmount`. Similarly, `permit` can be front-run on the `deadline` or `nonces` to invalidate a signature or execute it prematurely.
FixEducate users about the inherent risks associated with front-running on ERC-20 approvals and `permit` functions. Advise users to exercise caution with approvals, especially for large amounts, and to use `increaseAllowance`/`decreaseAllowance` carefully. For `permit`, users should be aware of the implications of `deadline` and `nonces`. While these are inherent to the ERC-20 standard, clear communication can help mitigate user-level risks.
StatusUnresolved

Category Ratings

TechnicalMedium4/10

The contract implements standard ERC-20 functionality (7.2 Code Security) with robust access control (7.3 Access Control) for minting, burning, and module management, leveraging a governor and scheduled calls. However, a medium-severity issue was identified with unchecked arithmetic in `_mint` and `_transfer` for balance additions, which could theoretically lead to overflows (7.2 Code Security). The contract's heavy reliance on an external `Globals` contract for governance and scheduling introduces a high external dependency risk (7.6 External), as its security directly impacts MapleToken's integrity.

GovernanceHigh1/10

The governance model (7.5 Governance) is centralized through a `governor` address, which controls critical functions like `addModule` and `removeModule`. These actions are further protected by a `onlyScheduled` modifier, requiring validation and unscheduling via an external `Globals` contract. This design centralizes significant control and introduces a high economic risk (7.4 Economic) if the `Globals` contract or the governor's key is compromised (7.6 External). While scheduled calls add a layer of security, the overall system's resilience depends heavily on the security of this external dependency.

UpgradesHigh1/10

The contract is designed as a UUPS proxy implementation, correctly using storage slots for `GLOBALS_SLOT` and `IMPLEMENTATION_SLOT` (7.7 Upgrades). However, a critical upgradeability flaw exists: the `ERC20Proxied` base contract declares ERC-20 state variables (e.g., `totalSupply`, `balanceOf`) directly. In a UUPS pattern, these variables must be managed via storage slots in the proxy, not declared in the implementation. This design error means that upon an upgrade to a new implementation, all token state would be lost, rendering the token unusable.

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

45.6% in top 10
26.7% in wallets18.9% in contracts
Effective Concentration34.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

$3.53M across 4 pairs
Uniswap v4ETHanalysed$2.57M72.9%Uniswap v3WETH$937.5K26.6%Uniswap v4USDT$18.0K0.5%Uniswap v4USDC$1040.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 Holder75.2%
Top-3 Unlocked89.0%

Key Addresses

11 addresses
Deployer
0x763a…7882
Unlocked LP Held By
0x00bd…c55c0x96c1…07fb0xd622…41ab0x7c53…6c320x5a74…280e0x8ca9…e2b20xf85c…0ee10xb583…952c0x2515…cd6b0xd162…eb66

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

What Raised This Score

11 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% (45.6% total → 34.2% effective; 26.7% in EOAs, 18.9% in contracts — moderate)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 75.2% (independent LP — depth risk, pool = 73% of DEX liquidity)
  • LP top3 unlocked holders = 89.0% (independent LP — depth risk, pool = 73% of DEX liquidity)
  • 1 Critical finding(s) from audit
  • 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
TurtleCritical RiskPortalCritical RiskNillion (NIL)Critical RiskSynapse (SYN)Critical RiskRallyCritical RiskAutonolas (OLAS)Critical Risk

Would You Like a More Detailed Audit of Syrup Token?

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

Get Detailed Audit