This audit covers the OETH token contract, which inherits from OUSD, and the Governable contract, which provides access control and reentrancy protection. The system operates behind an EIP-1967 UUPS proxy. A critical limitation of this audit is the absence of the OUSD contract's source code, which is expected to contain the core token logic and potentially complex vault interactions. This prevents a full assessment of the protocol's primary functionality and introduces significant unknown risks. The provided Governable contract implements a robust two-step governance transfer and a secure reentrancy guard. However, the high centralization of power with the governor role and potential storage collision risks due to the missing OUSD source are notable concerns.
On-chain security analysis — is it a scam or legit?
Is Origin Ether Safe?
EthereumNot 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 →This audit covers the OETH token contract, which inherits from OUSD, and the Governable contract, which provides access control and reentrancy protection.
- Ownership not renounced
- 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
- 1 High finding(s) from audit
- 1 Medium finding(s) from audit
- 1 Low finding(s) from audit
Exact 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
Security Checklist
as of audit · Sep 4Holders
as of audit · Sep 4, 2026- Contractstreasury, vesting, bridge, staking93.6%
- Walletsanonymous holders, free to sell3.6%
- Everyone elsethe rest of the supply2.8%
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 4The 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.
0xeb0a…c8e3No privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.
Security Findings
CriticalCore Logic (OUSD) Source Code Not Provided for Audit
The 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)C-01
OUSD) Source Code Not Provided for AuditIssue
The 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)
Fix
Provide 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.
Status
Unresolved
HighHigh Centralization of Power with Governor Role
The 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)H-01
Issue
The 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)
Fix
Implement 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.
Status
Unresolved
MediumPotential Storage Collisions in UUPS Proxy Implementation
The 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)M-01
Issue
The 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)
Fix
Ensure 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.
Status
Unresolved
LowExtensive IVault Interface Implies High Complexity
The 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)L-01
IVault Interface Implies High ComplexityIssue
The 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)
Fix
Implement 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.
Status
Unresolved
InfoMissing _initialize Function in Provided Scope
For 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)I-01
_initialize Function in Provided ScopeIssue
For 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)
Fix
Ensure 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.
Status
Unresolved
Analysis
AI Copilotas of audit · Sep 4The 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).
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).
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).
A comprehensive security audit of the OUSD contract and all its dependencies is paramount to ensure the overall integrity and security of the Origin Ether protocol.
Implement a multi-signature wallet for the governor address to mitigate centralization risks and consider time-locks for sensitive administrative actions. Thoroughly review and test the storage layout of all contracts in the inheritance chain to prevent potential storage collisions during future upgrades.
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 3, 202670High
Score changes are recorded as dated snapshots — history is append-only and cannot be edited.
Would You Like a More Detailed Audit of Origin Ether?
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