[ARFC] Add stS to Aave v3 Sonic Instance

Governance New Asset
4

Summary

LlamaRisk recommends onboarding stS to the Aave Sonic instance. stS is a liquid staking derivative for Sonic’s native token developed by Beets. Users deposit $S and receive a non-rebasing token that appreciates over time as staking rewards compound. Deposited $S is pooled and delegated to validators, with rewards—after deducting a protocol performance fee—being earned.

Liquidity is primarily provided on Beets, with a $16M swap incurring about a 7.5% price impact. Liquidity is diversified across leading venues such as SwapX and Shadow and market data indicate steady TVL growth, highlighted by an addition of roughly 50M $S over the past month. There is some inherent dependency risk due to limited third-party involvement and potential validator slashing, which can affect yield and asset value.

Risk management includes comprehensive smart contract audits performed by Trail of Bits and Spearbit and a $200k bug bounty program through ImmuneFi. Governance and access control measures are implemented through a multi-signature framework and layered timelock configurations, which oversee essential contract functions such as upgrades, fee adjustments, and emergency pauses. Our review uncovered that the Beets: Deployer EOA was mistakenly assigned the OPERATOR_ROLE, contrary to documented best practices. After notifying the team, access was revoked via this transaction, and at no point funds were at risk. The internal exchange rate oracle combined with CAPO parameters is recommended to mitigate short-term volatility and accurately reflect the asset’s underlying value.

Collateral Risk Assessment

1. Asset Fundamental Characteristics

stS, developed by Beets.fi, is a liquid staking derivative that represents staked S tokens, the native currency of the Sonic ecosystem. It has an onchain market cap of ±160M stS ($71M) as of 10th March 2025. It pays stakers 4.6% APY.

The asset generates yield from $S staked to validators. The value of stS naturally appreciates about $S thanks to native network staking rewards from validator delegation being automatically compounded within the token. It is a non-rebasing token, meaning it entitles holders to a fixed share of a vault with an increasing amount of $S.

Many liquid staking tokens have already been onboarded to Aave, making these fundamental asset characteristics of low incremental risk to the protocol. Indeed, wOS is another governance-approved liquid staking token on the protocol’s Sonic instance.

1.1 Asset

The asset is ERC-20 compliant. It is open-sourced and represents a share of the amount of Sonic being staked through Beethoven’s selected noncustodial validator system. Staking is instant, but unstaking takes 14 days. This asset has many DEX pools, and Beethoven (the issuer) has a long history of operating network-leading decentralized exchanges on Fantom (Sonic’s predecessor network). stS takes a 10% fee (after 15% validator fees) on all revenue generated by staking.

1.2 Architecture

Beethoven’s staked Sonic repository puts it best:

$stS earns yield from delegating underlying $S to validators. Delegated $S earns rewards and a portion of transaction fees (in $S) to secure the network. The rewards claimed increase the amount of $S in the system, which increases the price of $stS against $S. There is a protocol performance (not management) fee applied to rewards.

image
image2610×336 66.8 KB

Source: $stS staking / unstaking workflow, LlamaRisk

$stS works in the following way:

  • A user deposits $S into the contract and receives $stS for it, according to the rate (which may be viewed on SonicScan, under the "getRate "function), which is currently 1.016 $stS to $S.
  • Deposited $S will be accumulated in the “pool” contract first.
  • An operator delegates the deposited $S to a validator, where it will earn rewards.
  • A specific “claimor” will claim rewards from specific validators to increase the $stS to $S rate.
  • A protocol fee is deducted from the rewards, with the remainder being added to the pool where $S is initially sent to before being staked.
  • Our user undelegates their $stS and may withdraw the $S two weeks later.

This architecture is widely used and battle-tested. Slashing risks on S delegated to validators (which may decrease the value of $stS) remain, but this has yet to occur on the network.

1.3 Tokenomics

stS is contractually bound to an increasing ratio against the amount of S staked through the protocol. As an LST, this tokenomic structure is widely established and easily integrated into Aave.

1.3.1 Token Holder Concentration

image
image1654×1026 208 KB

Source: stS Beets dashboard, Dune via BeetsFi, March 14, 2025

On the surface, stS is relatively concentrated, with 3 addresses containing more than 50% of the supply. The largest holder is a Silo vault, likely being used to power leveraged staking strategies—the second largest is an EOA. The third largest holder is a Balancer pool. This makes concentration risk less than it may seem, but it ultimately remains.

2. Market Risk

2.1 Liquidity

image
image2936×1212 239 KB

Source: $stS to $S via Odos Router, March 11th, 2025

Liquidity for this asset is excellent, with a $16M swap incurring ±7.5% price impact. This mitigates risk for the Aave protocol as liquidators can reliably liquidate in profit.

2.1.1 Liquidity Venue Concentration

Most liquidity is hosted on Beets, which is appropriate given they developed this LST. This presents some risk as in the unlikely event Beets suffers an unintended event, the majority of the onchain liquidity for this asset may not be usable. Beets’ liquidity strategy builds on this with two CL pools on Shadow (4M TVL) and SwapX (8M TVL) which adds to onchain stS liquidity. Diversified liquidity venues decrease risk to Aave as they increase the likelihood of profitable liquidations being successfully operated. Venue concentration risk is low.

2.2 Volatility

image
image2402×1222 165 KB

Source: $stS / $S, Shadow Exchange via GeckoTerminal, March 19th, 2025

stS has not maintained a continuously increasing peg in the market, exhibiting moderate volatility. This behavior is significant for an LST used in high-leverage looped positions, particularly when considering eMode. The asset’s inability to consistently hold its peg increases its risk profile. Although an ever-increasing internal rate may be implemented with a 14-day delay (pending continued slashing-free performance), the market price still reflects a degree of risk.

2.3 Exchanges

$stS is not yet listed on centralized exchanges.

2.4 Growth

image
image1640×818 41 KB

Source: stS Dashboard, Beets via Dune, March 11th 2025

The asset is growing in $S terms. Roughly 50M $S have been added in the last month, demonstrating sustained market satisfaction with the asset at this early stage.

3. Technological Risk

3.1 Smart Contract Risk

stS has been audited by Trail of Bits and Spearbit, both first-class security firms.

This is evidence of smart contract risk best practices, reducing risk.

3.2 Bug Bounty Program

Beets uses ImmuneFi and offers a $200K max bug bounty for their $stS product.

3.3 Price Feed Risk

As with other liquid staking tokens, this asset can be valued using either a market feed or its fundamental internal exchange rate oracle. Implementing the internal exchange rate with a CAPO adapter protects against inflation risk, accurately reflects slashing in case of penalties, and shields against short-term volatility that could arise from withdrawal demands.

3.4 Dependency Risk

Given how few third parties are involved in the continued operation of this asset, few dependencies are introduced. Those introduced include:

  • Validators that Beets select may get slashed for malicious activity. This reduces the yield generated and potentially results in lost S principal for the protocol. This risk is mitigated by carefully selecting separate validators to minimize the impact if one gets slashed.
  • Block rewards from the network may fluctuate, resulting in lowered APYs for $stS holders. This is especially relevant to Sonic, who uses a novel fee system. This dependency is harder to mitigate, but its threat is limited (it should only reduce leveraged staking profitability, which is not mission-critical to the function of this asset on Aave).

Dependency risk is low.

4. Counterparty Risk

4.1 Governance and Regulatory Risk

Beets uses a DAO, but core contributors maintain many functions of this protocol. Discussions occur on Discord, and votes are decided by two or three major voters (with strong turnouts nonetheless). Limited visibility on these processes result in some degree of risk. Fortunately, these processes have been clarified and updated recently, and governance cycles/roles are documented. This process will increase procedure and transparency, which reduces risk.

Beets DAO LLC is established as a non-profit limited liability company under the Republic of the Marshall Islands laws. The Company is organized exclusively for charitable, educational, and social purposes, specifically to promote and provide access to the Beets technology and protocol.

In 2022, the Republic of the Marshall Islands amended its Non-Profit Entities Act to allow DAOs to register as legal entities. This framework was further strengthened in 2023, streamlining the registration process and providing legal protections for DAOs operating within the country. Regarding staking activities, in particular, no specific legislation directly addresses the regulation of cryptocurrency staking.

While the Operating Agreement does not explicitly list all products launched by Beets DAO LLC, it provides a broad mandate to cover all activities and initiatives aligned with its purpose. Membership is exclusive to token holders. By holding a designated NFT (ERC-721 token), one automatically acknowledges and consents to the terms of the Operating Agreement. Members have voting power proportional to their token holdings. They are not obligated to make any capital contributions to the Company, nor are they personally liable for the Company’s debts or obligations.

Beets Reliquary NFT Terms outline that participation includes activities such as voting on proposals, attending events, communicating with the Beets community, and interacting with the Beets protocol. A token holder’s membership interest is freely transferable through the conveyance of the NFT. While these Terms establish a connection between NFT ownership and membership in the DAO, they do not represent a standard website or protocol terms of use. In particular, the terms under which users can access staking features or products offered by Beets are not addressed. Several key elements typically found in comprehensive terms of use are missing: there are no provisions detailing what constitutes acceptable or prohibited use of the Beets platform or protocol; the Terms do not specify who is eligible to participate, such as jurisdictional limitations or legal compliance requirements; the Terms do not disclaim any warranties regarding the performance, availability, or reliability of the Beets protocol or associated services; there is no limitation on the DAO’s liability for damages or losses users might incur while using the platform.

4.2 Access Control Risk

4.2.1 Contract Modification Options

The $stS contract has a variety of functions that may be modified. The most significant are:

  • Changing contract ownership
  • Upgrade the contract
  • Change S withdraw delays
  • Reclaim S from validators to the pool
  • Change stS fees
  • Modify treasury addresses
  • Pause deposits/withdrawals
  • Donate from the pool

These are very significant permissions that may modify all parts of $stS. This presents an access control risk that may be realized should contract ownership be compromised.

4.2.2 Timelock Duration and Function

The timelock, which functions as the owner of the $stS contract, is authorized to execute these functions. Its duration is 21 days, which, while relatively long and potentially introducing certain risks, allows for pausing critical contract functions during emergencies. The Beets team has indicated that this extended timelock is necessary to support the efficient withdrawal of S from the pool. While this approach carries some inherent risks, it is evident that the Beets team has carefully designed it to balance security and functionality.

4.2.3 Multisig Threshold / Signer identity

stS token:

1.OPERATOR_ROLE: which may manage staking/delegation, handle clawbacks, donate to the pool, and commence emergency protocol pauses.

2.CLAIM_ROLE: This function claims rewards from all contracts and adds them to the pool, increasing the vault’s value. While an EOA is potentially easy to compromise, having limited permissions to call functions helps reduce this risk.

3.ADMIN_ROLE handles protocol parameters, treasury/fees, and role assignments. It is critical for operational governance but does not handle contract upgrades.

4.OWNER: may upgrade any part of the contract, hence the long timelock.

Upon reviewing stS’s access controls, we discovered that the Beets: Deployer (0xb5e6b895734409Df411a052195eb4EE7e40d8696 - an EOA) was still holding the OPERATOR_ROLE. This is contrary to best practices and the documentation. The Beets team was promptly notified and revoked access within minutes. At no point were funds at risk; however, this could have resulted in protocol disruptions had that EOA deployer been compromised. Although not explicitly within the bug bounty scope, the Beets team has decided to award a small bug bounty for this finding.

Separating these roles and having a timelock owner indicates a responsible access control management process. Careful segmentation of these roles with long/short timelocks as appropriate reduces access control risk to Aave when onboarding the asset.

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 jointly presented with @ChaosLabs

Price feed Recommendation

We recommend employing the internal exchange rate oracle in combination with CAPO.

Disclaimer

This review was independently prepared by LlamaRisk, a community-led 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.

2 Likes