Quantum Audit Logo
Launch App

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

Is Metronome Synth USD Safe?

MSUSDBase
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
Technical6/10Governance1/10Upgrades1/10Checks passed1 of 5Findings1 High · 2 Medium · 1 Low · 1 Info5
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.

Read the full analysis
What raised the score
  • Ownership status UNKNOWN
  • Mintable supply — no cap found, dilution unbounded
  • Proxy contract
  • Top-10 concentration > 50%
  • 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
  • 2 Medium finding(s) from audit
  • 1 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 > 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

Security Checklist

as of audit · Sep 41 of 5 checks passed
Contract verifiedVerified
OwnershipUnknown
MintMintable
Liquidity lockNot locked
UpgradeabilityUpgradeable

Holders

as of audit · Sep 4, 2026
61.8%Contracts32.4%Wallets5.8%
61.8%Contracts32.4%Wallets5.8%
ContractsWalletsEveryone elseBubble area = share of supply
94.2%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking61.8%
  • Walletsanonymous holders, free to sell32.4%
  • Everyone elsethe rest of the supply5.8%
Effective concentrationwhat the score reads57.2%
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$4.01M across 8 pairs
Show 2 more 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$2.60MShare of depth64.8%
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 High2 Medium1 Low1 Info
High

Centralized Control Over Token Supply and Operations

The 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)H-01

Issue

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

Fix

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

Status

Unresolved

Medium

Immutability of _poolRegistry after Initialization

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

Issue

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

Fix

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

Status

Unresolved

Medium

Reliance on External Contract Security and Liveness

The 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)M-02

Issue

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

Fix

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

Status

Unresolved

Low

Default maxTotalSupply to type(uint256).max

During 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)L-01

Issue

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

Fix

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

Status

Unresolved

Info

Incomplete Code for Core ERC-20 Logic

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

Issue

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

Fix

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

Status

Unresolved

Analysis

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

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.

Technical6/10Medium risk

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

Governance1/10High risk

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

Upgrades1/10High risk

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.

Final RecommendationWhat to do about this score

To enhance the security posture of the SyntheticToken contract, it is highly recommended to decentralize critical administrative powers currently held by the single governor role.

Implementing a multi-signature wallet with a sufficient threshold or a time-locked governance mechanism for sensitive operations like setting supply caps or updating privileged addresses would significantly mitigate the risk of a single point of failure. Additionally, consider adding a governor-controlled setter for the _poolRegistry address to allow for more flexible management of this critical dependency without requiring a full contract upgrade.

Contract & Record

1 audit on record
TypeTransparentUpgradeableProxy
NetworkBase
Token age1y
Contract0x5267…ae9d
Deployer0xdf82…99d5
Proxy Upgrade Controls
Proxy TypeEip1967 Transparent
AdminOZ ProxyAdmin → Multisig 3-of-5
ImplementationVerified source
Upgrades (30d)0 · stable
Badge for your website
Metronome Synth USD 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 4, 202668High
  2. Jul 28, 202659Medium
  3. Jul 24, 202667High

Score changes are recorded as dated snapshots — history is append-only and cannot be edited.

Frequently Asked Questions

What is the MSUSD contract address?

The Metronome Synth USD (MSUSD) contract on Base is 0x526728dbc96689597f85ae4cd716d4f7fccbae9d. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.

Is Metronome Synth USD a scam?

Quantum Audit's risk score for Metronome Synth USD is 68/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. A score is a dated snapshot of those facts, not a guarantee; each one is listed on this page.

Is MSUSD liquidity locked?

Liquidity lock: Not locked (as of Sep 4, 2026). Total DEX liquidity: $4.01M.

Who holds MSUSD?

As of Sep 4, 2026, the 10 largest holders own 94.2% of the supply. The Holders section on this page shows who they are by holder type.

Related Audits

6 more on the recordAll audits
CoW Protocol TokenCOW · Base68HighSETZBase68HighBaseBase68HighPaperBase68HighEthy AI by VirtualsETHY · Base69HighLingoBase69High

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 Is this your token? Publish your own audit on this page