[ARFC] Add support for Wrapped Origin Sonic (wOS) to Aave v3

Governance New Asset
3

Summary

LlamaRisk supports onboarding Wrapped Origin Sonic (wOS) to Aave v3 and recommends configuring a dedicated wOS/S Emode to maximize capital efficiency. wOS is a Sonic liquid staking token designed to support leveraged staking strategies. Our analysis indicates that wOS is built on a strong foundation, reflecting the solid track record of the Origin team and oversight from their in-house security expert.

The Origin team has confirmed that fixes for their latest OpenZeppelin audit will be deployed imminently, alongside the inclusion of wOS in their bug bounty program. We consider these actions mandatory before onboarding. Furthermore, while the current yield is generated solely through staking, wOS’s risk profile may evolve significantly as additional DeFi strategies are adopted.

Collateral Risk Assessment (click to reveal)

1. Asset Fundamental Characteristics

1.1 Asset

Wrapped Origin Sonic (wOS) is an ERC-4626 tokenized vault that supports leveraged staking strategies. Unlike traditional tokens, whose supply increases with yield accumulation, wOS appreciates while its token count remains unchanged, reflecting the growing underlying asset. Its design aligns with previous Origin tokens such as OUSD, OETH, and SuperOETH, with approximately 5% of its code modified from the audited OUSD contract to implement its unique yield-generation mechanics.

1.2 Architecture

image
image1544×717 52.6 KB

Source: Origin Documentation via LlamaRisk on Aave Forum, October 3 2024

wOS is engineered to maximize yield by capturing network staking rewards and pool revenues. While its overall structure is analogous to wOETH, subtle implementation differences have been introduced to optimize performance and manage specific risk factors. The diagram above illustrates the protocol’s comprehensive architecture and yield capture mechanism, showcasing the OETH/superOETHb function (which is analogous to wOS).

image
image770×813 48.1 KB

Source: wOS dependencies, Origin documentation, February 24 2025

Specific wOS architecture is detailed above. It shares the same architectural design as wOETH and other Origin tokens with minor implementational differences.

Key wOS contracts include:

This architecture is relatively straightforward and introduces a few points of failure beyond yield strategy selection.

1.3 Tokenomics

The tokenomics structure for wOS is straightforward. Origin users stake S among diverse validators to receive network rewards passed to token holders. Users can choose to hold either OS—which increases in number over time as rewards are credited—or wOS, which represents a fixed share of an ever‑increasing pool of OS.

image
image1370×1092 47.3 KB

Source: Percentage of wrapped OS (wOS), Origin Analytics, February 24 2025

Currently, the proportion of wOS relative to unwrapped OS is 60%. Approximately 23,000,000 OS are staked, with network rewards at 10%—down from 15% two weeks ago.

The associated OGN token serves as the governance token for the Origin Protocol ecosystem. Holders can lock their OGN in exchange for xOGN, which grants economic rewards and governance rights. The multiplier increases with longer staking durations (up to one year), incentivizing long-term commitment. Stakers may delegate votes, participate in multiple staking periods, and collect rewards from protocol revenue, primarily through OETH and superOETHb performance fees. Importantly, while xOGN balances remain constant during the lock-up period, a staker’s share of the overall voting power decreases as additional stakes are introduced.

Although new to Aave, Origin’s tokenomics system has been thoroughly tested in design and implementation.

1.3.1 Token Holder Concentration

image
image2790×1452 343 KB

Source: wOS holder distribution, Etherscan,, February 24th 2025

wOS holders are relatively concentrated, with approximately 75% held by just two addresses. The first address is an Euler Finance wOS vault, and the second is a Silo Finance wOS vault. Within these vaults, the largest holder (an EOA) supplies about 20% of the vault’s assets. This distribution suggests a degree of ownership balance that may help limit Aave’s concentration risk.

2. Market Risk

2.1 Liquidity

image
image477×615 30.4 KB

Source: OpenOcean, March 4, 2025

Liquidity for wOS to S is reasonable (via OS), with the asset being able to handle ~$3.5m within 7.5% slippage. Given that wOS may be unstaked from Origin-selected validators on a 14-day cooldown, this liquidity constraint is not an all-encompassing concern.

2.1.1 Liquidity Venue Concentration

Most of the liquidity is held on SwapX and Metropolis, with smaller pools on Shadow and Beethoven.

2.1.2 DEX LP Concentration

It is important to note that OpenOcean routes unwrapping as a potential route, deepening liquidity.

2.2 Volatility

The OS/S has remained strong, showing very little volatility.

2.3 Exchanges

The market presence of wOS is currently limited, with trading activity confined to just a few DEXs. The asset has no CEX support.

2.4 Growth

From early February, TVL started at a relatively low base and exhibited gradual accumulation, reaching 37.5M S as of today. This upward trend reflects growing confidence and usage within the Sonic ecosystem, likely driven by the attractive yield opportunities currently available on the network. Among these opportunities, OS and wOS tokens stand out as they are whitelisted for 4x Sonic points, offering enhanced rewards.

image
image1732×962 46.5 KB

Source: Origin Sonic TVL, DefiLlama, February 26th, 2025

3. Technological Risk

3.1 Smart Contract Risk

The Origin Sonic contract is a nuanced adaptation of the OUSD contract, which has undergone multiple comprehensive security audits. A dedicated Origin Sonic Staking Audit performed by OpenZeppelin in February 2025 identified one medium severity, three low severity, and four informational issues. The issues have been acknowledged, and the team confirmed fixes will be deployed shortly. Additional Sonic network adaptations are undergoing further audits, with results expected in the first week of March.

3.2 Bug Bounty Program

Origin maintains a bug bounty program offering rewards of up to $1,000,000 OUSD for identifying major critical vulnerabilities. At present, the program covers only OUSD and OETH. The Origin team has indicated that the scope will be expanded to include wOS shortly.

3.3 Price Feed Risk

As an ERC-4626 compliant contract, wOS has a built-in internal exchange rate oracle available via the convertToAssets function. There is currently no wOS/S market price feed.

3.4 Dependency Risk

Dependencies are depicted in the architecture diagram provided earlier. In addition to relying on ERC-20 and ERC-4626 standards, wOS introduces timelock dependencies:

  • The contract inherits from OpenZeppelin’s TimelockController.
  • It implements ERC-165 for role‑based access control.

All main protocol components use the same proxy pattern by inheriting from InitializeGovernedUpgradeabilityProxy—a custom proxy implementation rather than the standard OpenZeppelin patterns.

4. Counterparty Risk

4.1 Governance and Regulatory Risk

Origin’s core protocol operations—yield generation, fee collection, and distribution—are executed through upgradeable smart contracts governed by token holders. Governance decisions require a quorum of at least 20% of the total xOGN supply (staked Origin Token). All approved proposals are subject to a mandatory timelock before execution, allowing users to exit their positions if they disagree with forthcoming changes.

Most governance activities begin off-chain on the Origin Governance Forum and Discord server, then progress to a Snapshot vote before culminating in formal implementation.

Governance participation is tiered according to token holdings:

  • Voting on existing proposals has no minimum requirement.
  • Creating a Snapshot proposal requires 5,000 xOGN.
  • Submitting an on-chain proposal requires 100,000 xOGN.

The governance contract includes additional parameters, such as a 24-hour voting delay, a 48-hour voting period, and a two-day timelock delay before proposal implementation.

The website (www.originprotocol.com) and the decentralized application are accessible via IPFS at originprotocol.eth.limo (the Interface) are provided by Origin Protocol Labs, a Cayman Islands entity. While the Cayman Islands offer a recognized yet adaptable legal environment for digital assets and related services, they have not formally addressed liquid staking within their regulatory framework.

Hosted on IPFS, the Interface enables users to interact with decentralized protocols deployed on public blockchains. Under the Terms of Service, users always maintain full control over their crypto assets. Origin neither holds nor manages these assets nor assumes any role in transactions conducted via the Interface or protocol. All interactions occur directly between a user’s self-custodial wallet and the underlying protocol.

Due to the decentralized nature of the Interface—where files and content reside on multiple IPFS nodes rather than a central server—Origin cannot modify, supervise, or guarantee its availability at any given time.

This decentralized approach limits the risk to Aave stemming from counterparty exposure, though some residual risk remains.

4.2 Access Control Risk

Here are the main controlling wallets:

Here are the main contracts of the protocol:

  • Origin Sonic (ERC-20) : The ERC20 implementation. Deployed behind an older version of a BaseUpgradeabilityProxy contract from OpenZeppelin and is owned by the Timelock.
  • Wrapped OS (ERC-4626): An ERC4626 wrapper for the token. Deployed behind an older version of a BaseUpgradeabilityProxy contract from OpenZeppelin and is owned by the Timelock.
  • Vault Admin: Manages the supported assets for minting OS, deposits/withdraws from strategies, and allocates funds to the withdrawal buffer.
  • Vault Core: Manages strategy configuration. It is deployed behind an older version of a BaseUpgradeabilityProxy contract from OpenZeppelin and is owned by the Timelock.
  • Oracle Router: Oracle that returns the 1e18 constant (fixed price oracle). The contract is immutable.
  • Dripper: Passes rewards to OS holders at a fixed rate to avoid drastic changes in the internal exchange rate. Deployed behind an older version of a BaseUpgradeabilityProxy contract from OpenZeppelin and is owned by the Timelock.
  • Zapper: Allows to mint and redeem wOS for S and conversely. The contract is immutable, and only the Vault Core contract can use its minting and redeeming functions.
  • Sonic Staking Strategy: Manages staking into the consensus layer of Sonic. Deposits and withdrawals are available to the Vault Core contract only. Deployed behind an older version of a BaseUpgradeabilityProxy contract from OpenZeppelin and is owned by the Timelock.
  • VaultValueChecker: Ensures that changes in the vault’s backing evolve within expected boundaries. It is an immutable contract.

4.2.1 Contract Modification Options

In most cases, all contract upgrades and state modifying functions are restricted to the governor, which is the Timelock. This Timelock is itself controlled by the Admin Multisig and the Guardian Multisig.

The vault code is split between the Vault Core and Vault Admin contracts for contract size reasons. When functions are called on the proxy, it first checks the Vault Core implementation and delegates to the Vault Admin implementation if the function is not found there. In both cases, privileged functions can only be executed by the Timelock. Below is a non-exhaustive list of important tasks that the Timelock can execute:

  • setPriceProvider(): Updates the contract address that provides asset price data.
  • setRedeemFeeBps(): Sets the fee percentage charged for redeeming tokens, limited to a maximum of 10%.
  • setStrategistAddr(): Updates the address of the Strategist who has partial administrative capabilities (no strategist is set for now).
  • setWithdrawalClaimDelay(): Changes the waiting period for async withdrawals, with constraints between 10 minutes and 15 days.
  • supportAsset(): Adds a new asset to the list of supported assets that can be used for minting OS.
  • removeAsset(): Removes an asset from the list of supported assets only if the vault holds minimal amounts.
  • setSwapper(): Sets the contract that performs swaps of collateral assets.
  • approveStrategy(): Adds a new strategy to the vault’s approved strategies list.
  • removeStrategy(): Removes a strategy from the vault, ensuring it’s not a default strategy for any asset.
  • setVaultBuffer(): Sets assets buffer to keep in the vault to handle redemptions without unwinding from strategies.
  • pauseCapital(): Pauses capital movement to prevent deposits and withdrawals.
  • unpauseCapital(): Resumes capital movement to allow deposits and withdrawals.

4.2.2 Timelock Duration and Function

The Timelock is controlled by the following roles:

4.2.3 Multisig Threshold / Signer identity

Two multisig wallets control the protocol:

The identity of the signers is not disclosed.

Note: This assessment follows the LLR-Aave Framework, a comprehensive methodology for asset onboarding and parameterization in Aave V3. This framework is continuously updated and available here.

Aave V3 Specific Parameters

Will be presented jointly with @chaoslabs

Price feed Recommendation

We recommend using the wOS internal exchange rate with the CAPO adapter.

Disclaimer

This review was independently prepared by LlamaRisk, a community-led non-profit decentralized organization funded in part by the Aave DAO. LlamaRisk is not directly affiliated with the protocol(s) reviewed in this assessment and did not receive any compensation from the protocol(s) or their affiliated entities for this work.

The information provided should not be construed as legal, financial, tax, or professional advice.