Quantum Audit Logo

Is Metronome Synth ETH Safe?

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

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

Metronome Synth ETH MSETH
0x6435…5160
Ethereum Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Critical Risk
Executive SummaryAI Copilot

The SyntheticToken contract serves as an ERC-20 compliant token implementation for a TransparentUpgradeableProxy, integrating with a broader DeFi ecosystem including PoolRegistry, Pools, DebtTokens, ProxyOFT, and AMO. The contract features robust access control mechanisms, extensive error handling, and adheres to OpenZeppelin's upgradeability patterns. However, significant reliance on external contracts for core access control decisions introduces a critical dependency risk. Additionally, the provided code snippet for the `_mint` function is incomplete, preventing a full security assessment of its supply management logic. The default initialization of `maxTotalSupply` to its maximum possible value also warrants attention.

1 Critical2 Medium2 Low1 Informational
Volume 24h
$649.5K
Liquidity
$7.61M
Price
$1165.5100
Token Age
3y
Top 10 Holders
97.6%

Security Findings

1 Crit2 Med2 Low1 Info
Critical

Critical External Dependency Risk in Access Control

C-01The `_isMsgSenderDebtToken` and `_isMsgSenderPool` functions, which are integral to the `onlyIfCanBurn`, `onlyIfCanMint`, and `onlyIfCanSeize` modifiers, rely on external calls to `IPoolRegistry`, `IPool`, and `IDebtToken` contracts. These external calls determine if a sender has permission to perform critical operations like minting, burning, or seizing tokens. If any of these external contracts are compromised, or if their logic can be manipulated (e.g., by registering a malicious pool/debt token or returning misleading information), the access control of the SyntheticToken could be bypassed, leading to unauthorized supply manipulation or asset seizure. This introduces a critical single p…
IssueThe `_isMsgSenderDebtToken` and `_isMsgSenderPool` functions, which are integral to the `onlyIfCanBurn`, `onlyIfCanMint`, and `onlyIfCanSeize` modifiers, rely on external calls to `IPoolRegistry`, `IPool`, and `IDebtToken` contracts. These external calls determine if a sender has permission to perform critical operations like minting, burning, or seizing tokens. If any of these external contracts are compromised, or if their logic can be manipulated (e.g., by registering a malicious pool/debt token or returning misleading information), the access control of the SyntheticToken could be bypassed, leading to unauthorized supply manipulation or asset seizure. This introduces a critical single p…
FixImplement robust validation and trust mechanisms for all external contract interactions. Consider adding a whitelist for trusted PoolRegistry, Pool, and DebtToken addresses, or implementing circuit breakers. Thoroughly audit all integrated external contracts to ensure their security and resistance to manipulation. Document the trust assumptions and potential attack vectors related to these external dependencies.
StatusUnresolved
Medium

Incomplete `_mint` Function Logic

M-01The provided source code for the `_mint` function is truncated. This prevents a complete security assessment of its implementation, particularly regarding how `totalSupply`, `balanceOf`, `totalBridgedIn`, `amoSupply`, and various `maxSupply` limits (`maxTotalSupply`, `maxAmoSupply`, `maxBridgedInSupply`) are managed. Without the full code, it's impossible to verify the correctness of its arithmetic, access control, and adherence to the protocol's economic rules (7.2 Code Security, 7.4 Economic).
IssueThe provided source code for the `_mint` function is truncated. This prevents a complete security assessment of its implementation, particularly regarding how `totalSupply`, `balanceOf`, `totalBridgedIn`, `amoSupply`, and various `maxSupply` limits (`maxTotalSupply`, `maxAmoSupply`, `maxBridgedInSupply`) are managed. Without the full code, it's impossible to verify the correctness of its arithmetic, access control, and adherence to the protocol's economic rules (7.2 Code Security, 7.4 Economic).
FixProvide the complete and untruncated source code for the `_mint` function for a thorough security review. Ensure that all relevant supply limits are checked before minting, and that `totalSupply`, `balanceOf`, and other related state variables are updated correctly and safely, preventing overflows and adhering to the intended economic model.
StatusUnresolved
Medium

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

M-02In the `initialize` function, the `maxTotalSupply` variable is set to `type(uint256).max`. This effectively means there is no upper limit on the total supply of the synthetic token by default. While other specific limits like `maxBridgedInSupply` and `maxAmoSupply` exist, the overall `totalSupply` is not capped. This design choice could lead to unexpected inflation or economic instability if the various minting mechanisms are not sufficiently constrained by other means, or if the intention was to have a more restrictive total supply limit (7.4 Economic).
IssueIn the `initialize` function, the `maxTotalSupply` variable is set to `type(uint256).max`. This effectively means there is no upper limit on the total supply of the synthetic token by default. While other specific limits like `maxBridgedInSupply` and `maxAmoSupply` exist, the overall `totalSupply` is not capped. This design choice could lead to unexpected inflation or economic instability if the various minting mechanisms are not sufficiently constrained by other means, or if the intention was to have a more restrictive total supply limit (7.4 Economic).
FixReview the economic model and confirm if an unbounded `maxTotalSupply` is the intended design. If a cap is desired, set a specific `maxTotalSupply` value during initialization or provide a clear governance mechanism for setting and updating this limit. If it is intentionally unbounded, ensure that all individual minting paths (e.g., via `ProxyOFT`, `Amo`, `Pool`, `DebtToken`) have sufficient and robust checks to prevent excessive supply creation.
StatusUnresolved
Low

Broad Access for Mint and Burn Operations

L-01The `onlyIfCanBurn` and `onlyIfCanMint` modifiers grant permission to `ProxyOFT`, `Amo`, `Pool`, and `DebtToken` contracts to perform mint and burn operations. While this is likely by design to facilitate the protocol's functionality, it means that a significant number of external entities have direct control over the synthetic token's supply. The security and integrity of these external contracts are paramount, as a compromise in any of them could lead to unauthorized token issuance or destruction (7.3 Access Control, 7.4 Economic).
IssueThe `onlyIfCanBurn` and `onlyIfCanMint` modifiers grant permission to `ProxyOFT`, `Amo`, `Pool`, and `DebtToken` contracts to perform mint and burn operations. While this is likely by design to facilitate the protocol's functionality, it means that a significant number of external entities have direct control over the synthetic token's supply. The security and integrity of these external contracts are paramount, as a compromise in any of them could lead to unauthorized token issuance or destruction (7.3 Access Control, 7.4 Economic).
FixEnsure that all external contracts authorized to mint or burn tokens are subject to the highest security standards, including regular audits and robust operational security. Implement monitoring for unusual minting/burning activity from these addresses. Clearly document the roles and responsibilities of each authorized entity and the potential impact of their compromise.
StatusUnresolved
Low

`seize` Function Grants Powerful Transfer Capability

L-02The `seize` function allows entities identified by `onlyIfCanSeize` (i.e., `Pool` and `DebtToken` contracts) to transfer tokens from any `from_` address to any `to_` address without requiring prior approval from the `from_` address. This is a powerful capability that, if misused or compromised, could lead to arbitrary token transfers. While restricted by the `onlyIfCanSeize` modifier, the implications of this power should be fully understood and documented (7.3 Access Control).
IssueThe `seize` function allows entities identified by `onlyIfCanSeize` (i.e., `Pool` and `DebtToken` contracts) to transfer tokens from any `from_` address to any `to_` address without requiring prior approval from the `from_` address. This is a powerful capability that, if misused or compromised, could lead to arbitrary token transfers. While restricted by the `onlyIfCanSeize` modifier, the implications of this power should be fully understood and documented (7.3 Access Control).
FixThoroughly review the design rationale and necessity of the `seize` function. Ensure that the `Pool` and `DebtToken` contracts, which are authorized to call `seize`, have robust internal controls and are highly secure. Document the specific scenarios and conditions under which `seize` is intended to be used, and consider implementing additional safeguards or multi-signature approvals for such sensitive operations if feasible.
StatusUnresolved
Info

Implicit Return of Zero in `bridgedInSupply` and `bridgedOutSupply`

I-01The `bridgedInSupply()` and `bridgedOutSupply()` functions implicitly return 0 if their respective `if` conditions are not met (i.e., `_totalBridgedIn <= _totalBridgedOut` for `bridgedInSupply()` or `_totalBridgedOut <= _totalBridgedIn` for `bridgedOutSupply()`). While this is the default behavior for Solidity functions returning a value type when no explicit `return` statement is executed, explicitly returning `0` in these cases would enhance code clarity and readability for future developers and auditors (7.2 Code Security).
IssueThe `bridgedInSupply()` and `bridgedOutSupply()` functions implicitly return 0 if their respective `if` conditions are not met (i.e., `_totalBridgedIn <= _totalBridgedOut` for `bridgedInSupply()` or `_totalBridgedOut <= _totalBridgedIn` for `bridgedOutSupply()`). While this is the default behavior for Solidity functions returning a value type when no explicit `return` statement is executed, explicitly returning `0` in these cases would enhance code clarity and readability for future developers and auditors (7.2 Code Security).
FixFor improved clarity, consider adding an explicit `return 0;` statement at the end of `bridgedInSupply()` and `bridgedOutSupply()` functions, after the conditional logic, to clearly indicate the intended return value when the conditions for subtraction are not met.
StatusUnresolved

Category Ratings

TechnicalMedium5/10

The contract demonstrates good technical practices, including comprehensive custom error handling and safe arithmetic operations using `unchecked` blocks after validation checks (7.2 Code Security). The `decreaseAllowance` and `transferFrom` functions correctly prevent underflows. However, a critical technical risk arises from the heavy reliance on external contracts (`IPoolRegistry`, `IPool`, `IDebtToken`) for determining access control permissions in `_isMsgSenderDebtToken` and `_isMsgSenderPool` (7.6 External, 7.3 Access Control). Furthermore, the provided `_mint` function is truncated, making a complete assessment of its security and economic logic impossible (7.2 Code Security).

GovernanceHigh1/10

The contract implements granular access control through modifiers like `onlyGovernor`, `onlyIfCanBurn`, `onlyIfCanMint`, and `onlyIfCanSeize`, restricting sensitive operations to specific roles or integrated protocol components (7.3 Access Control). Supply limits such as `maxBridgedOutSupply` are enforced during burning. However, the `maxTotalSupply` is initialized to `type(uint256).max` in the `initialize` function, effectively setting no default upper bound on the total token supply (7.4 Economic). The broad permissions granted to `ProxyOFT`, `Amo`, `Pool`, and `DebtToken` for minting and burning operations (7.4 Economic) mean that the economic stability of the synthetic token is highly dependent on the security and integrity of these external entities.

UpgradesHigh1/10

The contract correctly utilizes OpenZeppelin's `Initializable` pattern, including `_disableInitializers()` in the constructor and an `initializer` modifier for the `initialize` function (7.7 Upgrades). This standard approach mitigates common upgradeability risks such as re-initialization. The use of `SyntheticTokenStorageV2` suggests a well-considered storage layout for future upgrades, though the full storage definition was not provided for review.

Security Checklist

1/5 checks passed
Contract VerifiedPass
Ownership Renounced?
No Mint FunctionFail
Liquidity LockedFail
Not a ProxyFail
HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Proxy Upgrade Controls

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

Holder Composition

97.6% in top 10
2.5% in wallets95.1% in contracts
Effective Concentration40.5%

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

$7.76M across 2 pairs
CurveWETHanalysed$7.61M98.0%Curve stblOETH$153.5K2.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
0x421a…7dbe
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 > 30% (97.6% total → 40.5% effective; 2.5% in EOAs, 95.1% 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 = 98% of DEX liquidity)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 98% of DEX liquidity)
  • 1 Critical finding(s) from audit
  • 2 Medium finding(s) from audit
  • 2 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
NEXOCritical RiskCronos (CRO)Critical RiskEpic Chain (EPIC)Critical RiskAZTECCritical RiskCoW Protocol Token (COW)Critical RiskMetronome Synth USD (MSUSD)Critical 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