Quantum Audit Logo
Launch App

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

Is Syrup Token Safe?

SYRUPEthereum
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
High RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical4/10Governance1/10Upgrades1/10Checks passed1 of 5Findings1 Critical · 1 High · 1 Medium · 1 Low4
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.

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 = 75.2%
  • LP top3 unlocked holders = 89.0%
  • 1 Critical finding(s) from audit
  • 1 High finding(s) from audit
  • 1 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% (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

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
18.9%Contracts26.7%Wallets54.4%Everyone else
18.9%Contracts26.7%Wallets54.4%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
45.6%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking18.9%
  • Walletsanonymous holders, free to sell26.7%
  • Everyone elsethe rest of the supply54.4%
Effective concentrationwhat the score reads34.2%
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$3.53M across 4 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$2.57MShare of depth72.9%
Top-1 Unlocked Holder75.2%
Top-3 Unlocked89.0%
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.

Security Findings

1 Critical1 High1 Medium1 Low
Critical

UUPS Implementation State Variable Mismanagement

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

Issue

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

Fix

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

Status

Unresolved

High

Centralized Control and High External Dependency on Globals Contract

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

Issue

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

Fix

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

Status

Unresolved

Medium

Unchecked Arithmetic for Balance Additions

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

Issue

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

Fix

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

Status

Unresolved

Low

Standard ERC-20 Front-Running Risks

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

Issue

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

Fix

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

Status

Unresolved

Analysis

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

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.

Technical4/10Medium risk

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.

Governance1/10High risk

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.

Upgrades1/10High risk

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.

Final RecommendationWhat to do about this score

Address the critical upgradeability flaw by refactoring the ERC20Proxied contract to manage ERC-20 state variables via explicit storage slots, ensuring persistence across upgrades.

Conduct a comprehensive security audit of the Globals contract to mitigate the high external dependency risk. Re-evaluate the use of unchecked blocks for balance additions in _mint and _transfer to prevent theoretical overflow scenarios. Educate users on standard ERC-20 front-running risks, particularly concerning approve and permit functions.

Contract & Record

1 audit on record
TypeMapleTokenProxy
NetworkEthereum
Token age1y
Contract0x643c…2d66
Deployer0x763a…7882
Proxy Upgrade Controls
Proxy TypeEip1967 Uups
ImplementationVerified source
Upgrades (30d)0 · stable
Badge for your website
Syrup Token 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, 202678High
  2. Aug 16, 202670High

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

Frequently Asked Questions

What is the SYRUP contract address?

The Syrup Token (SYRUP) contract on Ethereum is 0x643c4e15d7d62ad0abec4a9bd4b001aa3ef52d66. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.

Is Syrup Token a scam?

Quantum Audit's risk score for Syrup Token is 78/100 (High risk) as of Sep 4, 2026, computed by a deterministic function from on-chain facts — Contract verified: Verified; Mint: Mintable; Liquidity lock: Not locked; Upgradeability: Upgradeable. A score is a dated snapshot of those facts, not a guarantee; each one is listed on this page.

Is SYRUP liquidity locked?

Liquidity lock: Not locked (as of Sep 4, 2026). Total DEX liquidity: $3.53M.

Who holds SYRUP?

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

Related Audits

6 more on the recordAll audits
TurtleEthereum78HighMinpentaiPENTA · Ethereum78HighClausEthereum78HighPortalEthereum77HighNillionNIL · Ethereum77HighSynapseSYN · Ethereum76High

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