Quantum Audit Logo

Is Metronome Synth ETH Safe?

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

Metronome Synth ETH MSETH
0x7ba6…8c98
Base Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

The SyntheticToken contract serves as an upgradeable ERC-20 token implementation, integrating with a broader DeFi ecosystem including a PoolRegistry, Pools, DebtTokens, ProxyOFT, and an AMO. The contract leverages OpenZeppelin's upgradeable patterns and Solidity 0.8.24's default overflow/underflow checks, enhancing its robustness. Key strengths include a well-defined access control system for core operations and the use of custom error messages. However, the audit identified a high reliance on the security and correct functioning of external contracts for critical token operations (minting, burning, seizing), which introduces significant external dependency risk. Additionally, the default unbounded `maxTotalSupply` could pose economic risks if not managed by other protocol layers.

1 High1 Medium2 Informational
Volume 24h
$224.7K
Liquidity
$1.47M
Price
$1170.4900
Token Age
1y
Top 10 Holders
92.7%

Security Findings

1 High1 Med2 Info
High

High Reliance on External Contracts for Core Logic and Access Control

H-01The `SyntheticToken` contract delegates critical minting, burning, and seizing capabilities to external contracts (ProxyOFT, AMO, Pool, DebtToken) via the `onlyIfCanBurn`, `onlyIfCanMint`, and `onlyIfCanSeize` modifiers. These modifiers involve multiple external calls to `_poolRegistry`, `IManageable`, `IPool`, and `IDebtToken` to verify the sender's role. This architecture introduces a high degree of trust in the security and correct functioning of these external contracts and the `PoolRegistry`. A vulnerability or misconfiguration in any of these dependent contracts could directly lead to unauthorized minting, burning, or seizing of the synthetic token, compromising its supply and value.
IssueThe `SyntheticToken` contract delegates critical minting, burning, and seizing capabilities to external contracts (ProxyOFT, AMO, Pool, DebtToken) via the `onlyIfCanBurn`, `onlyIfCanMint`, and `onlyIfCanSeize` modifiers. These modifiers involve multiple external calls to `_poolRegistry`, `IManageable`, `IPool`, and `IDebtToken` to verify the sender's role. This architecture introduces a high degree of trust in the security and correct functioning of these external contracts and the `PoolRegistry`. A vulnerability or misconfiguration in any of these dependent contracts could directly lead to unauthorized minting, burning, or seizing of the synthetic token, compromising its supply and value.
FixConduct comprehensive security audits of all external contracts that are granted privileged access to the `SyntheticToken`'s core functions. Implement robust monitoring and incident response plans for these interconnected components. Consider adding circuit breakers or emergency pause mechanisms that can be triggered by the `governor` in case of a compromise in a dependent external contract.
StatusUnresolved
Medium

Default Unbounded `maxTotalSupply`

M-01The `initialize` function sets `maxTotalSupply = type(uint256).max;`. This means, by default, there is no effective upper limit on the total supply of the synthetic token. While the contract includes `maxAmoSupply`, `maxBridgedInSupply`, and `maxBridgedOutSupply` limits, the overall `maxTotalSupply` being unbounded could lead to unexpected economic scenarios if not carefully managed by other protocol mechanisms or if the intention was to have a configurable global cap. If `maxTotalSupply` is intended to be a configurable limit, it should be set to a reasonable initial value rather than `type(uint256).max`.
IssueThe `initialize` function sets `maxTotalSupply = type(uint256).max;`. This means, by default, there is no effective upper limit on the total supply of the synthetic token. While the contract includes `maxAmoSupply`, `maxBridgedInSupply`, and `maxBridgedOutSupply` limits, the overall `maxTotalSupply` being unbounded could lead to unexpected economic scenarios if not carefully managed by other protocol mechanisms or if the intention was to have a configurable global cap. If `maxTotalSupply` is intended to be a configurable limit, it should be set to a reasonable initial value rather than `type(uint256).max`.
FixIf a global maximum total supply is desired, set `maxTotalSupply` to a specific, reasonable value during initialization or provide a dedicated `onlyGovernor` function to set it post-deployment. If the unbounded nature is intentional, ensure that the economic implications are fully understood and that other protocol layers adequately manage the overall supply without relying on this variable.
StatusUnresolved
Info

Lack of Specific Error for `amoSupply` Underflow

I-01When `_isMsgSenderAmo(_msgSender)` is true in the `_burn` function, `amoSupply -= amount_` is executed. In Solidity 0.8.24, this operation will revert if `amoSupply < amount_` due to default overflow/underflow checks. However, unlike `BurnAmountExceedsBalance()` which is explicitly checked for `balanceOf[account_]`, there is no specific custom error for `amoSupply` underflow. This could lead to a less clear error message for users or integrators if an AMO attempts to burn more than its allocated supply.
IssueWhen `_isMsgSenderAmo(_msgSender)` is true in the `_burn` function, `amoSupply -= amount_` is executed. In Solidity 0.8.24, this operation will revert if `amoSupply < amount_` due to default overflow/underflow checks. However, unlike `BurnAmountExceedsBalance()` which is explicitly checked for `balanceOf[account_]`, there is no specific custom error for `amoSupply` underflow. This could lead to a less clear error message for users or integrators if an AMO attempts to burn more than its allocated supply.
FixConsider adding an explicit `require(amoSupply >= amount_, 'AmoSupplyExceedsBalance')` or a custom error check before the `amoSupply -= amount_` operation to provide a more specific and user-friendly error message in case of an underflow.
StatusUnresolved
Info

Unused `VERSION` Constant

I-02The `VERSION` constant is declared but not referenced anywhere within the provided contract code. While not a security vulnerability, it represents dead code and could be removed to slightly reduce contract size and improve clarity, or utilized for on-chain version tracking.
IssueThe `VERSION` constant is declared but not referenced anywhere within the provided contract code. While not a security vulnerability, it represents dead code and could be removed to slightly reduce contract size and improve clarity, or utilized for on-chain version tracking.
FixEither remove the `VERSION` constant if it serves no functional purpose, or integrate it into a function (e.g., a `version()` public view function) to provide on-chain version information for external tools or users.
StatusUnresolved

Category Ratings

TechnicalMedium6/10

The SyntheticToken contract demonstrates good technical practices, utilizing OpenZeppelin's `Initializable` for upgradeability and custom error types for efficient error handling. Solidity 0.8.24's default overflow/underflow checks enhance arithmetic safety. However, the contract's access control for minting, burning, and seizing relies heavily on multiple external contract calls (e.g., `_isMsgSenderDebtToken`, `_isMsgSenderPool`), increasing the attack surface and complexity (7.2 Code Security, 7.3 Access Control). This dependency on external contract behavior introduces a significant technical risk.

GovernanceHigh1/10

The economic model incorporates various supply limits (`maxAmoSupply`, `maxBridgedInSupply`, `maxBridgedOutSupply`) and a governor-controlled `PoolRegistry` for managing critical parameters (7.4 Economic, 7.5 Governance). However, the `maxTotalSupply` is initialized to `type(uint256).max`, effectively making the total supply unbounded by default, which could have economic implications if not intended or managed by other protocol layers (7.4 Economic). The high reliance on external contracts for core token operations also introduces governance and economic risks, as a compromise in a dependent contract could impact the synthetic token's integrity (7.6 External).

UpgradesHigh1/10

The contract is deployed behind a `TransparentUpgradeableProxy` and correctly uses OpenZeppelin's `Initializable` pattern, including `_disableInitializers()` in the constructor and the `initializer` modifier for `initialize` (7.7 Upgrades). The use of `SyntheticTokenStorageV2` indicates a structured approach to storage management, which is crucial for safe upgrades. The proxy is administered by a multisig, providing a robust and secure mechanism for future upgrades (7.8 Operations).

Security Checklist

1/5 checks passed
Contract VerifiedPass
Ownership Renounced?
No Mint FunctionFail
Liquidity LockedFail
Not a ProxyFail

Proxy Upgrade Controls

Proxy TypeEip1967 Transparent
AdminOZ ProxyAdmin → Multisig 3-of-5
ImplementationVerified source
Upgrades (30d)0 · stable

Holder Composition

92.7% in top 10
20.1% in wallets72.6% in contracts
Effective Concentration49.1%

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

$2.27M across 4 pairs
AerodromeWETHanalysed$1.47M64.8%AerodromeWETH$799.9K35.2%AerodromemsUSD$5510.0%0xB0C2…9C88WETH$90.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 Holder100.0%
Top-3 Unlocked100.0%

Key Addresses

2 addresses
Deployer
0xdf82…99d5
Unlocked LP Held By
0x5ec2…daa7

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

What Raised This Score

9 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% (92.7% total → 49.1% effective; 20.1% in EOAs, 72.6% in contracts — moderate)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 100.0% (independent LP — depth risk, pool = 65% of DEX liquidity)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 65% of DEX liquidity)
  • 1 High finding(s) from audit
  • 1 Medium 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
OpenUSDT (OUSDT)High RiskPingHigh RiskVenice Token (VVV)High RiskAvantis (AVNT)High RiskSupergemma4-26b-multimodal (SUPERGEMMA)High RiskACUHigh Risk

Would You Like a More Detailed Audit of Metronome Synth ETH?

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

Get Detailed Audit