Is Metronome Synth USD (MSUSD) Safe? Smart Contract Security Analysis

Security Checklist

1/5 checks passed

Contract VerifiedFail

Ownership RenouncedUnknown

No Mint FunctionFail

Liquidity LockedFail

Not a ProxyPass

Audit History

1 audit on record

Jul 2467

Every audit run adds a dated snapshot — history is append-only and cannot be edited.

Audit Summary

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.

Final Recommendation: 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.

Category Ratings

TechnicalHigh

3/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(uint

GovernanceHigh

2/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` h

UpgradesHigh

2/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 stor

What Raised This Score

7 factors

Ownership status UNKNOWN (owner could not be resolved)
Mintable supply — no cap found, dilution unbounded
Contract source NOT verified
Liquidity NOT locked (owner can withdraw — rug-pull risk)
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 Findings

5 total

1 High 2 Medium 1 Low 1 Info

H-01HighUnresolved

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)

Recommendation: 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.

M-01MediumUnresolved

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)

Recommendation: 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.

M-02MediumUnresolved

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)

Recommendation: 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.

L-01LowUnresolved

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)

Recommendation: 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.

I-01InformationalUnresolved

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)

Recommendation: 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.

Is Metronome Synth USD Safe? MSUSD