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.
On-chain security analysis — is it a scam or legit?
Is Metronome Synth ETH Safe?
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 →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.
Read the full analysis- 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 = 100.0%
- LP top3 unlocked holders = 100.0%
- 1 High finding(s) from audit
- 1 Medium 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% (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
Security Checklist
as of audit · Sep 4Holders
as of audit · Sep 4, 2026- Contractstreasury, vesting, bridge, staking72.6%
- Walletsanonymous holders, free to sell20.1%
- Everyone elsethe rest of the supply7.3%
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- AerodromeWETHAnalysed$1.47M64.8%
- AerodromeWETH$799.9K35.2%
- AerodromemsUSD$5510.0%
- 0xB0C2…9C88WETH$90.0%
The risk score reads depth across every pair.
The LP tokens of the analysed pool are not locked or burned, so whoever holds them can withdraw that liquidity.
0x5ec2…daa7No privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.
Security Findings
HighHigh Reliance on External Contracts for Core Logic and Access Control
The 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.H-01
Issue
The 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.
Fix
Conduct 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.
Status
Unresolved
MediumDefault Unbounded maxTotalSupply
The 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.M-01
maxTotalSupplyIssue
The 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.
Fix
If 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.
Status
Unresolved
InfoLack of Specific Error for amoSupply Underflow
When _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.I-01
amoSupply UnderflowIssue
When _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.
Fix
Consider 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.
Status
Unresolved
InfoUnused VERSION Constant
The 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.I-02
VERSION ConstantIssue
The 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.
Fix
Either 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.
Status
Unresolved
Analysis
AI Copilotas of audit · Sep 4The 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.
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).
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).
It is recommended to thoroughly audit all external contracts that interact with the SyntheticToken, especially those granted minting, burning, or seizing permissions (ProxyOFT, AMO, Pool, DebtToken, PoolRegistry), to ensure their security and correct behavior.
Consider implementing a more restrictive default maxTotalSupply or clearly documenting the intended management of this parameter if it is designed to be unbounded. For improved user experience and debugging, consider adding specific custom error messages for all critical revert conditions, such as amoSupply underflow.
Contract & Record
Free for any token on the record. It links to this page and always shows the current score and the date it was checked.
- Sep 4, 202650Medium
- Aug 13, 202655Medium
Score changes are recorded as dated snapshots — history is append-only and cannot be edited.
Frequently Asked Questions
What is the MSETH contract address?
The Metronome Synth ETH (MSETH) contract on Base is 0x7ba6f01772924a82d9626c126347a28299e98c98. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.
Is Metronome Synth ETH a scam?
Quantum Audit's risk score for Metronome Synth ETH is 50/100 (Medium 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 MSETH liquidity locked?
Liquidity lock: Not locked (as of Sep 4, 2026). Total DEX liquidity: $2.27M.
Who holds MSETH?
As of Sep 4, 2026, the 10 largest holders own 92.7% of the supply. The Holders section on this page shows who they are by holder type.
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 Is this your token? Publish your own audit on this page