Is Origin Ether (OETH) Safe? Smart Contract Security Analysis

Security Findings

1 Crit1 High1 Med1 Low1 Info

Critical

Core Logic (`OUSD`) Source Code Not Provided for Audit

C-01The `OETH` contract inherits from `OUSD`, which is expected to contain the primary ERC-20 token logic (minting, burning, transfers) and potentially the complex vault and strategy interactions hinted at by the `IVault` interface. Without the source code for `OUSD`, a comprehensive security audit of the `OETH` token's core functionality and its interactions within the broader protocol is impossible. This leaves a significant portion of the system unaudited, posing an unknown but potentially critical risk. (7.1 Architecture, 7.2 Code Security, 7.4 Economic)

IssueThe `OETH` contract inherits from `OUSD`, which is expected to contain the primary ERC-20 token logic (minting, burning, transfers) and potentially the complex vault and strategy interactions hinted at by the `IVault` interface. Without the source code for `OUSD`, a comprehensive security audit of the `OETH` token's core functionality and its interactions within the broader protocol is impossible. This leaves a significant portion of the system unaudited, posing an unknown but potentially critical risk. (7.1 Architecture, 7.2 Code Security, 7.4 Economic)

FixProvide the complete source code for the `OUSD` contract and all its dependencies for a full security review. All inherited contracts and their logic are crucial for understanding the overall system's security posture.

StatusUnresolved

High

High Centralization of Power with Governor Role

H-01The `Governable` contract implements an `onlyGovernor` modifier, granting a single address extensive control over critical functions. While the specific functions controlled by the governor in `OUSD` are unknown, the `IVault` interface suggests the governor can manage strategies, set fees, pause/unpause capital and rebases, update price providers, and change various thresholds. A compromise of the governor's private key could lead to significant financial loss, manipulation of the protocol, or even a rug pull. (7.3 Access Control, 7.5 Governance, 7.8 Operations)

IssueThe `Governable` contract implements an `onlyGovernor` modifier, granting a single address extensive control over critical functions. While the specific functions controlled by the governor in `OUSD` are unknown, the `IVault` interface suggests the governor can manage strategies, set fees, pause/unpause capital and rebases, update price providers, and change various thresholds. A compromise of the governor's private key could lead to significant financial loss, manipulation of the protocol, or even a rug pull. (7.3 Access Control, 7.5 Governance, 7.8 Operations)

FixImplement a multi-signature wallet (e.g., Gnosis Safe) for the governor address to distribute control and reduce the single point of failure risk. Consider time-locks for critical operations to allow users to react to malicious actions.

StatusUnresolved

Medium

Potential Storage Collisions in UUPS Proxy Implementation

M-01The `Governable` contract uses fixed storage slots (`governorPosition`, `pendingGovernorPosition`, `reentryStatusPosition`) for its state variables, which is a standard practice for UUPS proxy implementations to prevent storage collisions with the proxy contract itself. However, without the `OUSD` source code, it's impossible to verify that `OUSD` (and any contracts it inherits from) also correctly manages its storage slots, especially if it introduces new state variables or uses `_initialize` functions. Incorrect storage slot management in `OUSD` could lead to critical state corruption upon upgrade. (7.1 Architecture, 7.7 Upgrades)

IssueThe `Governable` contract uses fixed storage slots (`governorPosition`, `pendingGovernorPosition`, `reentryStatusPosition`) for its state variables, which is a standard practice for UUPS proxy implementations to prevent storage collisions with the proxy contract itself. However, without the `OUSD` source code, it's impossible to verify that `OUSD` (and any contracts it inherits from) also correctly manages its storage slots, especially if it introduces new state variables or uses `_initialize` functions. Incorrect storage slot management in `OUSD` could lead to critical state corruption upon upgrade. (7.1 Architecture, 7.7 Upgrades)

FixEnsure that the `OUSD` contract and all its base contracts adhere to a strict storage layout, explicitly defining storage slots for all state variables using `bytes32` positions or ensuring no new state variables are introduced in the first storage slot of the implementation contract if using the standard UUPS layout. A thorough storage slot analysis of the entire inheritance hierarchy is required.

StatusUnresolved

Low

Extensive `IVault` Interface Implies High Complexity

L-01The `IVault` interface, which `OUSD` is likely to implement or interact with, exposes a large number of functions for managing assets, strategies, fees, and various protocol parameters. While interfaces themselves don't introduce vulnerabilities, the sheer volume and scope of configurable parameters and external interactions implied by this interface suggest a highly complex system. Increased complexity inherently leads to a larger attack surface and a higher potential for subtle bugs or misconfigurations, especially when interacting with multiple external strategies and price providers. (7.1 Architecture, 7.2 Code Security)

IssueThe `IVault` interface, which `OUSD` is likely to implement or interact with, exposes a large number of functions for managing assets, strategies, fees, and various protocol parameters. While interfaces themselves don't introduce vulnerabilities, the sheer volume and scope of configurable parameters and external interactions implied by this interface suggest a highly complex system. Increased complexity inherently leads to a larger attack surface and a higher potential for subtle bugs or misconfigurations, especially when interacting with multiple external strategies and price providers. (7.1 Architecture, 7.2 Code Security)

FixImplement robust testing, including unit, integration, and fuzz testing, for all functions related to the `IVault` interface. Ensure comprehensive documentation of all configurable parameters and their impact. Consider modularizing complex logic where possible to reduce cognitive load and potential for errors.

StatusUnresolved

Info

Missing `_initialize` Function in Provided Scope

I-01For UUPS proxy contracts, an `_initialize` function is crucial for setting initial state variables (like the governor) upon deployment of the implementation contract through the proxy. While `Governable` provides `_setGovernor`, the actual `_initialize` function is not present in the provided `OETH` or `Governable` code. It is presumed to exist in the `OUSD` contract. Without it, the contract would not be properly initialized, leading to an unowned or unconfigured state. (7.1 Architecture, 7.8 Operations)

IssueFor UUPS proxy contracts, an `_initialize` function is crucial for setting initial state variables (like the governor) upon deployment of the implementation contract through the proxy. While `Governable` provides `_setGovernor`, the actual `_initialize` function is not present in the provided `OETH` or `Governable` code. It is presumed to exist in the `OUSD` contract. Without it, the contract would not be properly initialized, leading to an unowned or unconfigured state. (7.1 Architecture, 7.8 Operations)

FixEnsure that the `OUSD` contract or one of its base contracts correctly implements an `_initialize` function that is called exactly once upon proxy deployment to set up the initial state, including the governor. This function should include an `initializer` modifier to prevent re-initialization attacks.

StatusUnresolved

Category Ratings

TechnicalMedium4/10

The technical architecture includes a UUPS proxy and a `Governable` contract providing robust access control and a reentrancy guard. The `nonReentrant` modifier is correctly implemented using assembly for storage slot access. However, the core logic residing in the `OUSD` parent contract was not provided, preventing a full technical assessment of the token's functionality, including minting, burning, and interactions with external systems. This significantly limits the ability to identify potential vulnerabilities in the primary business logic (7.1 Architecture, 7.2 Code Security).

GovernanceHigh1/10

The governance model features a secure two-step transfer process for the governor role, enhancing operational safety. The governor holds significant power, as is typical for such protocols, with the ability to manage critical parameters like strategies, fees, and pausing mechanisms, as indicated by the `IVault` interface. This centralization, while efficient, introduces a single point of failure if the governor's key is compromised, posing a high economic risk (7.3 Access Control, 7.5 Governance, 7.4 Economic).

UpgradesHigh1/10

The system utilizes an EIP-1967 UUPS proxy pattern, with the `Governable` contract correctly employing fixed storage slots for its state variables to prevent collisions during upgrades. This design allows for future enhancements and bug fixes. However, the absence of the `OUSD` contract's source code means its storage layout and initialization logic could not be verified, which is critical for ensuring safe and collision-free upgrades (7.7 Upgrades).

Security Checklist

1/5 checks passed

Contract VerifiedPass

Ownership RenouncedFail

No Mint FunctionFail

Liquidity LockedFail

Not a ProxyFail

HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Proxy Upgrade Controls

Proxy TypeEip1967 Uups

ImplementationVerified source

Upgrades (30d)0 · stable

Holder Composition

97.2% in top 10

3.6% in wallets93.6% in contracts

Effective Concentration41.0%

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

$59.76M across 4 pairs

Curve stblWETHanalysed$59.70M CurveETH$58.0K Uniswap v3WETH$190 SushiswapWETH$2

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

0xfd9e…1236

Unlocked LP Held By

0xeb0a…c8e3

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

What Raised This Score

11 factors

Ownership NOT renounced (admin/mint authority retained)
Mintable supply — no cap found, dilution unbounded
Proxy contract (upgradeable — admin can replace logic)
Top-10 concentration > 30% (97.2% total → 41.0% effective; 3.6% in EOAs, 93.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)
LP top3 unlocked holders = 100.0% (independent LP — depth risk)
1 Critical finding(s) from audit
1 High finding(s) from audit
1 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

Is Origin Ether Safe?

Security Findings

Core Logic (`OUSD`) Source Code Not Provided for Audit

High Centralization of Power with Governor Role

Potential Storage Collisions in UUPS Proxy Implementation

Extensive `IVault` Interface Implies High Complexity

Missing `_initialize` Function in Provided Scope

Category Ratings

Security Checklist

Proxy Upgrade Controls

Holder Composition

Liquidity Depth

LP Distribution

Key Addresses

What Raised This Score

Related Audits

Would You Like a More Detailed Audit of Origin Ether?