Quantum Audit Logo

Is Metronome Synth USD Safe?

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

Metronome Synth USD MSUSD
0x5267…ae9d
Base Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

The audit of the SyntheticToken contract (implementation for a TransparentUpgradeableProxy) on the Base network identified several areas of concern, primarily related to centralized control and reliance on external dependencies. While the contract demonstrates good coding practices and adheres to upgradeability standards, the extensive powers granted to the governor role and the immutability of a critical dependency introduce notable risks. The core ERC-20 logic was partially truncated, limiting a full assessment of internal functions.

1 High2 Medium1 Low1 Informational
Volume 24h
$1.03M
Liquidity
$2.60M
Price
$0.4678
Token Age
1y
Top 10 Holders
94.2%

Security Findings

1 High2 Med1 Low1 Info
High

Centralized Control Over Token Supply and Operations

H-01The `SyntheticToken` contract grants significant control to the `governor` role (obtained from `_poolRegistry`). The governor can update `maxTotalSupply`, `maxAmoSupply`, `maxBridgedInSupply`, `maxBridgedOutSupply`, `proxyOFT`, and `amo` addresses. These addresses are then used in `onlyIfCanBurn` and `onlyIfCanMint` modifiers, effectively allowing the governor to dictate which external entities can mint or burn tokens. This centralization introduces a single point of failure; compromise of the governor's private key could lead to arbitrary minting/burning or manipulation of supply caps. (Coverage: 7.3 Access Control, 7.4 Economic, 7.5 Governance)
IssueThe `SyntheticToken` contract grants significant control to the `governor` role (obtained from `_poolRegistry`). The governor can update `maxTotalSupply`, `maxAmoSupply`, `maxBridgedInSupply`, `maxBridgedOutSupply`, `proxyOFT`, and `amo` addresses. These addresses are then used in `onlyIfCanBurn` and `onlyIfCanMint` modifiers, effectively allowing the governor to dictate which external entities can mint or burn tokens. This centralization introduces a single point of failure; compromise of the governor's private key could lead to arbitrary minting/burning or manipulation of supply caps. (Coverage: 7.3 Access Control, 7.4 Economic, 7.5 Governance)
FixImplement a multi-signature wallet or a time-locked governance mechanism for critical administrative functions to reduce the risk associated with a single point of control. Clearly document the powers of the governor and the associated risks.
StatusUnresolved
Medium

Immutability of `_poolRegistry` after Initialization

M-01The `_poolRegistry` address, which is crucial for determining the `governor` and potentially other core functionalities, is set only once during the `initialize` function. There is no setter function to update this address. If `_poolRegistry` is initialized incorrectly or if the referenced `IPoolRegistry` contract needs to be upgraded or replaced in the future, it would require a full contract upgrade of `SyntheticToken` itself, which is a more complex and risky operation than a simple address update. (Coverage: 7.1 Architecture, 7.3 Access Control, 7.8 Operations)
IssueThe `_poolRegistry` address, which is crucial for determining the `governor` and potentially other core functionalities, is set only once during the `initialize` function. There is no setter function to update this address. If `_poolRegistry` is initialized incorrectly or if the referenced `IPoolRegistry` contract needs to be upgraded or replaced in the future, it would require a full contract upgrade of `SyntheticToken` itself, which is a more complex and risky operation than a simple address update. (Coverage: 7.1 Architecture, 7.3 Access Control, 7.8 Operations)
FixConsider adding a `setPoolRegistry` function, protected by `onlyGovernor`, to allow for updates to this critical dependency. This would provide more flexibility for future protocol evolution and error correction, while still maintaining appropriate access control.
StatusUnresolved
Medium

Reliance on External Contract Security and Liveness

M-02The `SyntheticToken` contract heavily relies on external contracts such as `IPoolRegistry`, `IProxyOFT`, `IPool`, and `IDebtToken` for its core access control logic (`onlyIfCanBurn`, `onlyIfCanMint`, `onlyIfCanSeize`) and to determine the `governor`. The security, liveness, and correct functioning of these external contracts are paramount. A vulnerability, compromise, or unexpected behavior in any of these dependencies could directly impact the `SyntheticToken`'s integrity, potentially leading to unauthorized minting/burning or frozen operations. (Coverage: 7.6 External, 7.1 Architecture)
IssueThe `SyntheticToken` contract heavily relies on external contracts such as `IPoolRegistry`, `IProxyOFT`, `IPool`, and `IDebtToken` for its core access control logic (`onlyIfCanBurn`, `onlyIfCanMint`, `onlyIfCanSeize`) and to determine the `governor`. The security, liveness, and correct functioning of these external contracts are paramount. A vulnerability, compromise, or unexpected behavior in any of these dependencies could directly impact the `SyntheticToken`'s integrity, potentially leading to unauthorized minting/burning or frozen operations. (Coverage: 7.6 External, 7.1 Architecture)
FixConduct thorough security audits of all integrated external contracts. Implement robust monitoring for the health and activity of these dependencies. Consider circuit breakers or emergency pause mechanisms in `SyntheticToken` that can be triggered if a critical external dependency is compromised or malfunctions.
StatusUnresolved
Low

Default `maxTotalSupply` to `type(uint256).max`

L-01During initialization, `maxTotalSupply` is set to `type(uint256).max`, effectively imposing no initial cap on the total supply of the synthetic token. While the `governor` can later set a specific `maxTotalSupply` via `setMaxTotalSupply`, this initial state means that until a specific cap is set, the token's supply is theoretically unbounded, subject only to the `onlyIfCanMint` restrictions. This might not align with the intended economic model if a hard cap is desired from the outset. (Coverage: 7.4 Economic, 7.5 Governance)
IssueDuring initialization, `maxTotalSupply` is set to `type(uint256).max`, effectively imposing no initial cap on the total supply of the synthetic token. While the `governor` can later set a specific `maxTotalSupply` via `setMaxTotalSupply`, this initial state means that until a specific cap is set, the token's supply is theoretically unbounded, subject only to the `onlyIfCanMint` restrictions. This might not align with the intended economic model if a hard cap is desired from the outset. (Coverage: 7.4 Economic, 7.5 Governance)
FixIf a specific total supply cap is intended from deployment, it should be set during the `initialize` function or immediately after deployment by the governor. Otherwise, ensure clear documentation that the initial supply is uncapped and relies on the governor to set a limit.
StatusUnresolved
Info

Incomplete Code for Core ERC-20 Logic

I-01The provided contract snippet for `SyntheticToken` truncates the implementations of critical internal functions such as `_approve`, `_burn`, `_mint`, and `_transfer`. These functions are fundamental to the token's ERC-20 behavior and supply management, including the enforcement of supply caps (`SurpassMaxBridgingSupply`, `SurpassMaxSynthSupply`) and balance updates. Without the full code, a comprehensive audit of these core mechanics, including potential reentrancy vectors or subtle arithmetic errors, cannot be fully performed. (Coverage: 7.2 Code Security)
IssueThe provided contract snippet for `SyntheticToken` truncates the implementations of critical internal functions such as `_approve`, `_burn`, `_mint`, and `_transfer`. These functions are fundamental to the token's ERC-20 behavior and supply management, including the enforcement of supply caps (`SurpassMaxBridgingSupply`, `SurpassMaxSynthSupply`) and balance updates. Without the full code, a comprehensive audit of these core mechanics, including potential reentrancy vectors or subtle arithmetic errors, cannot be fully performed. (Coverage: 7.2 Code Security)
FixAlways provide the complete and final source code for all contracts and their dependencies for a thorough security audit. Assume standard and safe OpenZeppelin-like implementations for these internal functions, but verify this assumption with the full code.
StatusUnresolved

Category Ratings

TechnicalMedium6/10

The contract demonstrates good adherence to secure coding practices, including comprehensive input validation with custom error messages (e.g., `NameIsNull`, `AmountExceedsAllowance`). It correctly implements ERC-20 standard functions like `transferFrom` with allowance handling, including `type(uint256).max` for infinite allowances. The use of `unchecked` blocks for `decreaseAllowance` is safely guarded, preventing underflow. A significant portion of the core ERC-20 logic (`_mint`, `_burn`, `_transfer`) was not provided, limiting a full assessment of potential reentrancy or subtle arithmetic issues within these critical functions (I-01). The contract's reliance on external contracts for access control also introduces a dependency risk (M-02).

GovernanceHigh1/10

The contract clearly defines a `governor` role and uses specific modifiers (`onlyGovernor`, `onlyIfCanBurn`, `onlyIfCanMint`, `onlyIfCanSeize`) to enforce access control for sensitive operations. This structured approach to permissions is beneficial for operational clarity. However, the `governor` holds highly centralized control over critical parameters, including the ability to set supply caps (`maxTotalSupply`, `maxAmoSupply`) and define which external entities can mint or burn tokens (H-01). This level of centralization presents a significant single point of failure and economic risk if the governor's key is compromised. Additionally, the `_poolRegistry` address, which determines the governor, is immutable after initialization (M-01).

UpgradesHigh1/10

The contract correctly utilizes the OpenZeppelin `Initializable` pattern, including `_disableInitializers()` in the constructor and the `initializer` modifier, which is standard practice for secure upgradeable contracts. The use of `SyntheticTokenStorageV2` suggests a conscious effort to manage storage layout for future upgrades, mitigating common storage collision risks. While the standard upgrade pattern is followed, the immutability of the `_poolRegistry` address (M-01) means that if this core dependency needs to be changed, it would necessitate a full contract upgrade, rather than a simpler administrative update.

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

94.2% in top 10
32.4% in wallets61.8% in contracts
Effective Concentration57.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

$4.01M across 8 pairs
AerodromemsETHanalysed$2.60M64.8%AerodromeUSDC$1.05M26.2%AerodromeUSDC$351.2K8.8%AerodromeUSDC$5.1K0.1%AerodromeAERO$3.4K0.1%AerodromeUSDC$80.0%
Show 2 more pairsShow less
SushiswapAERO$10.0%AerodromeUSDT$00.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
0xd9b0…236f

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

What Raised This Score

10 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 > 50% (94.2% total → 57.2% effective; 32.4% in EOAs, 61.8% in contracts — heavy)
  • 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
  • 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

Related Audits

6 more on the record
CoW Protocol Token (COW)High RiskSETZHigh RiskEthy AI by Virtuals (ETHY)High RiskResearchCoin (RSC)High RiskFren PetHigh RiskRIZEHigh Risk

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

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

Get Detailed Audit