Quantum Audit Logo
Launch App

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

Is Metronome Synth ETH Safe?

MSETHEthereum
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
Technical5/10Governance1/10Upgrades1/10Checks passed3 of 7Findings1 Critical · 2 Medium · 2 Low · 1 Info6
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.

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 = 100.0%
  • LP top3 unlocked holders = 100.0%
  • 1 Critical finding(s) from audit
  • 2 Medium finding(s) from audit
  • 2 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% (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

Security Checklist

as of audit · Sep 43 of 7 checks passed
Contract verifiedVerified
OwnershipUnknown
MintMintable
Liquidity lockNot locked
UpgradeabilityUpgradeable
HoneypotNone found
Buy / sell tax0% / 0%

Holders

as of audit · Sep 4, 2026
95.1%Contracts2.5%2.4%
95.1%Contracts
ContractsWalletsEveryone elseBubble area = share of supply
97.6%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking95.1%
  • Walletsanonymous holders, free to sell2.5%
  • Everyone elsethe rest of the supply2.4%
Effective concentrationwhat the score reads40.5%
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$7.76M across 2 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$7.61MShare of depth98.0%
Top-1 Unlocked Holder100.0%
Top-3 Unlocked100.0%
Unlocked LP held by
0xd9b0…236f

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

Security Findings

1 Critical2 Medium2 Low1 Info
Critical

Critical External Dependency Risk in Access Control

The _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…C-01

Issue

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

Fix

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

Status

Unresolved

Medium

Incomplete _mint Function Logic

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

Issue

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

Fix

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

Status

Unresolved

Medium

maxTotalSupply Initialized to type(uint256).max

In 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).M-02

Issue

In 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).

Fix

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

Status

Unresolved

Low

Broad Access for Mint and Burn Operations

The 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).L-01

Issue

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

Fix

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

Status

Unresolved

Low

seize Function Grants Powerful Transfer Capability

The 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).L-02

Issue

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

Fix

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

Status

Unresolved

Info

Implicit Return of Zero in bridgedInSupply and bridgedOutSupply

The 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).I-01

Issue

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

Fix

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

Status

Unresolved

Analysis

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

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.

Technical5/10Medium risk

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

Governance1/10High risk

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.

Upgrades1/10High risk

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.

Final RecommendationWhat to do about this score

Prioritize a comprehensive review of the external contracts (IPoolRegistry, IPool, IDebtToken, IProxyOFT, Amo) that directly influence the access control and economic integrity of the SyntheticToken.

Ensure their security and trustworthiness are thoroughly established. Complete the audit of the full _mint function implementation to verify all supply management logic and limits. Consider implementing a more restrictive default maxTotalSupply or clearly documenting the rationale for its current unbounded state, alongside a robust governance process for its adjustment.

Contract & Record

1 audit on record
TypeTransparentUpgradeableProxy
NetworkEthereum
Token age3y
Contract0x6435…5160
Deployer0x421a…7dbe
Proxy Upgrade Controls
Proxy TypeEip1967 Transparent
AdminOZ ProxyAdmin → Multisig 3-of-5
ImplementationVerified source
Upgrades (30d)0 · stable
Badge for your website
Metronome Synth ETH 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 1, 202673High

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 Ethereum is 0x64351fc9810adad17a690e4e1717df5e7e085160. 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 73/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; Honeypot: None found; Buy / sell tax: 0% / 0%. 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: $7.76M.

Who holds MSETH?

As of Sep 4, 2026, the 10 largest holders own 97.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
NEXOEthereum73HighCronosCRO · Ethereum73HighEpic ChainEPIC · Ethereum73HighAZTECEthereum73HighCoW Protocol TokenCOW · Ethereum73HighMetronome Synth USDMSUSD · Ethereum73High

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