[ARFC] Add stS to Aave v3 Sonic Instance

[ARFC] Add stS to Aave v3 Sonic Instance


title: [ARFC] Add stS to Aave v3 Sonic Instance
author: @ACI
created: 2025-03-15

ARFC updated with Risk Parameters 2025-03-25


Summary

The proposal aims to onboard Beets’s stS, to Aave v3 Sonic instance.

Motivation

Launched in December 2024, Beets Staked Sonic (stS) is an ERC-20 Liquid Staked Token offering seamless exposure to Sonic network staking rewards via validator delegation, while remaining fully liquid in users’ wallets.

Similar to wstETH, stS passively accrues value—each time delegation rewards are added to the staking pool, the stS-to-S exchange rate increases automatically, with no action needed from holders. The underlying S delegation enhances Sonic’s decentralization across a diverse set of validators and strengthens the network’s economic security.

Previously known as sFTMx, the leading LST on Fantom Opera, stS quickly established itself as the kingmaker LST in the Sonic ecosystem, capturing over 12% of all staked S liquidity and 76% of S LST liquidity. Demand for leverage looping strategies using stS has been steadily rising, with over $160 million already deployed across other lending markets. Despite this strong demand for leveraged positions, stS has maintained a solid peg, currently trading at 99.72%.

Users can easily convert their S into stS via the Beets minting UI and redeem their stS with a 14-day unbonding period. Alternatively, they can trade stS directly on any of the following DEXs:

Security Considerations

Security is at the forefront of stS operations. Beets Staked Sonic was launched in December 2024, with its contracts originally audited by Spearbit, and then further audited by Trail of Bits in January. Beets maintains an Immunefi bug bounty of up to $200,000.

Regarding Oracles stS currently integrates a Redstone, Pyth, and Stork stS/S price feed, with a Api3 and Chainlink Oracle integration currently being worked on. Aave will use a CAPO oracle leveraging chainlink’s infrastructure.

Beets in numbers

Beets Staked Sonic has seen continuous growth since launching on December 16th 2024, with 138.65m S and $86.20m currently staked within the protocol.

Beets Staked Sonic is growing at a steady rate and is currently the number one spot by TVL on Defillama for LST projects on Sonic, with over 3.4x as much TVL as the second largest protocol:

Beets also runs a DEX on Sonic, resulting in it being the 2nd largest source of TVL across all protocols on Sonic:

Points program

Due to both the underlying exposure to APR (currently ~5%), and the current Sonic points program which offers 4x passive points and 8x activity points on stS, S borrows vs stS have a seen continuous growth with users seeking efficient means to leverage capital.

Being the largest LST on the network, stS is integrated into a variety of protocol verticals, including DEXs, Vaults, Yield Tokenization, and Lending markets:

Benefits of listing Beets Staked Sonic

Adding lending and borrowing support for stS on Aave would allow users to supply, borrow, and leverage Sonic’s flagship LST.

A dedicated stS market on Aave’s Sonic deployment would drive meaningful TVL growth and generate additional revenue for the Aave DAO through active S loans and liquidations. This integration would also position Aave as the go-to venue for risk-adjusted capital efficiency, enabling advanced looping strategies while providing exposure to Sonic points.

It’s worth noting that Beets also operates a DEX on Sonic, powered by Balancer technology. Beets contributors operate as technical Service Providers to the Balancer DAO and have played a key role in the development and deployment of 100% Boosted Pools, which have successfully re-hypothicated over $50M in liquidity to Aave.

With the launch of Aave on Sonic, Beets will deploy Aave Boosted Pools, creating a highly efficient mechanism for simultaneously growing Aave’s supply-side liquidity and strengthening Sonic Swap markets.

Alongside stablecoin liquidity such as USDC.e, scUSD and GHO, an stS | S Boosted Pool would likely see strong adoption from Sonic users—helping bootstrap supply while keeping borrowing costs low in leverage markets.

Proof of Liquidity (POL) and Deposit Commitments

As mentioned, Beets can deploy Aave Boosted Pools to help seed Aave’s capital markets on Sonic. While Beets would not directly supply stS or S POL to Aave, it would deposit POL from the DAO treasury into these pools, effectively routing 100% of capital straight to Aave.

Additionally, Beets is in discussions with Sonic Money Managers regarding the bootstrapping of the stS market through stS <> S looping strategies, as well as Boosted Pool POL deposits. Specific amounts will be determined in collaboration with the Aave team and the ACI, with further details to be shared during the ARFC stage of the proposal process.

Specification

Risk Parameters have been provided by Risk Services Providers and ARFC has been updated accordingly. 2025-03-25

Parameter Value
Asset stS
Isolation Mode No
Borrowable No
Collateral Enabled Yes
Supply Cap 30,000,000
Borrow Cap -
Debt Ceiling -
LTV 66%
LT 68%
Liquidation Penalty 10%
Liquidation Protocol Fee 10.00%
Variable Base -
Variable Slope1 -
Variable Slope2 -
Uoptimal -
Reserve Factor -
Stable Borrowing Disabled
Flashloanable Yes
Siloed Borrowing No
Borrowable in Isolation No
E-Mode Category stS/wS

stS/wS Liquid E-mode Configuration

Parameter Value Value
Asset stS wS
Collateral Yes No
Borrowable No Yes
Max LTV 87% -
Liquidation Threshold 90% -
Liquidation Bonus 1% -

CAPO

maxYearlyRatioGrowthPercent ratioReferenceTime MINIMUM_SNAPSHOT_DELAY
11.04% monthly 7

Useful links

Disclosure

The ACI is not directly affiliated with Beets and did not receive compensation for creation this proposal.

Next Steps

  1. Publish a standard ARFC, collect community & service providers feedback before escalating proposal to ARFC snapshot stage.
  2. If the ARFC snapshot outcome is YAE, publish an AIP vote for final confirmation and enforcement of the proposal

Copyright

Copyright and related rights waived via CC0.

4 Likes

Was there a temp check for this proposal?

1 Like

Hello,
Yes there was with YAE vote:
https://snapshot.box/#/s:aave.eth/proposal/0x9de39ac8c12d86853779584dbfdbd9c8ef679d6f530a7c0d5c66c358b6ec772c

2 Likes

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.

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

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

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

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

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.

4 Likes

Overview

Chaos Labs supports listing stS on Aave V3’s Sonic instance. Below is our analysis and initial risk parameter recommendations.

Beets

Beets is a DeFi protocol evolving from Beethoven X as Fantom transitions to Sonic, focusing on liquidity provisioning, yield optimization, and LSTs. Its core offerings include stS, Sonic’s LST managed by Beets; BEETS, the governance and utility token; and maBEETS, a maturity-adjusted governance token derived from an 80/20 BEETS-stS LP.

stS

stS is a reward-accruing LST that represents staked $S on the Sonic network. Unlike rebasing tokens, stS utilizes an exchange rate model, where its value increases relative to $S as staking rewards are automatically compounded. The current exchange rate stands at 1 stS = 1.0136 S.


stS Smart Contract

To track which validator receives the staked $S from stS, we analyzed the SFC address noted in the stS contract. By querying the SFC contract using the function getStake(address delegator, uint256 validatorID) with the stS address as the delegator and iterating through validator IDs, we identified the validators currently holding the staked assets from stS. Below, we present all of stS’s validators and their staked amounts, which collectively equal the totalDelegated.

Currently, the largest validators for stS are Validator IDs 18, 17, 16, and 15. Notably, these four validators also rank as the largest validators on Sonic by total staked amount. Unlike wOS, which delegates all staked assets to a single validator (validatorID 18), stS diversifies its stake across 10 validators. The top four validators each receive approximately 30M to 32M $S, collectively accounting for 80% of the total distribution, while the remaining 20% is distributed among the other validators. This distribution strategy reduces validator concentration compared to wOS, significantly lowering the risk of a single point of failure.

The stS operator can undelegate assets from a validator through the clawback mechanism using the operatorInitiateClawBack() function. This is achieved through fetching the stake amount via SFC.getStake() and then calling SFC.undelegate() to initiate the undelegation request. Once the withdraw delay has passed, the operator can finalize the process by calling operatorExecuteClawBack(), which withdraws the assets using SFC.withdraw() and restores them to the staking pool.

To stake $S and receive stS, users deposit $S on the Beets UI. This process mints stS immediately, representing the staked position while continuously accruing rewards. Unstaking requires a 14-day unbonding period, after which users can claim $S. Below, we present the distribution of stS withdrawals, showing that most occur right after the 14-day period, reflecting the required wait time before users can access their staked assets.

This differs from our previous analysis of wOS, where the withdrawal process depends on whether its vault holds enough wS to fulfill user withdrawal requests. If the vault has sufficient underlying assets, users only need to wait one day to withdraw. Otherwise, the wait time can extend up to 14 days. In contrast, stS enforces a fixed minimum withdrawal period of 14 days.

Market Cap & Liquidity

Since its inception, stS has exhibited a steady upward trend. Below, we present the amount of $S staked into the protocol over time. Currently, stS has a total supply of 166.15M, translating to a TVL of 82.23M USD.

Beets Dune Dashboard

stS is distributed among 11.18K holders, with the largest holder, Soli Finance’s stS-S market, accounting for 36% of the total supply.

stS Holder Distribution

The majority of stS liquidity is concentrated on Shadow Exchange and SwapX. Notable pairs include the S/stS pair on Shadow Exchange, currently holding a $4.2M TVL, the wS/stS pair on SwapX with a $7.97M TVL, and the USDC.e/stS pair on SwapX with a $1.08M TVL. Below, we present the aggregated stS DEX liquidity on Sonic over time.

Volatility

Below, we present the peg stability of stS, calculated as the market exchange rate relative to the internal exchange rate. The observed peg stability aligns with the volatility patterns seen in the Shadow S/stS pair and the SwapX wS/stS pair. While some fluctuations have occurred, the maximum depeg has remained within 100bps, demonstrating relatively strong peg stability.

stS Peg Stability

LTV, Liquidation Threshold, and Liquidation Bonus

Given stS’s technical architecture, liquidity, and volatility, we recommend applying slightly more conservative initial parameters compared to wS for the following reasons. First, the unstaking process for stS is not an atomic redemption—users must wait 14 days before they can withdraw. In the event of extreme market volatility, the liquidity pool becomes the only available exit for users looking to redeem stS immediately. Second, while the overall on-chain liquidity for stS is sufficient relative to its total supply, its liquidity has shown fluctuations over the past three months. Third, as discussed in this post, stS carries the same underlying asset risk as wOS, as wS serves as its backing asset and exhibits significant volatility, introducing duration risk.

Given these considerations, we recommend setting stS’s initial LTV at 66% and LT at 68%, with a liquidation bonus of 10%.

E-Mode

We recommend establishing an isolated liquid E-Mode for stS and wS to support the anticipated leverage looping use case of stS, enhancing users’ capital efficiency and potentially driving Sonic instance’s growth.

wS Parameters

Given the expectation of wOS/wS looping with the creation of a specific E-Mode, Chaos Labs recommends adjusting the UOptimal of wS to 80%
This will enable a highly efficient looping market and additional yield to be driven to wS suppliers.
In order to better parameterize wS for this use case, we also recommend decreasing Slope 1 of wS to 3.5%, or 70 bps below the current wOS staking rate.
This change, coupled with a maximum possible leverage of 10x determined by the 90% LT, will allow users to perform profitable looping strategies on the wOS/wS pair.

Supply Cap and Borrow Cap

We recommend setting the stS supply cap based on Chaos Labs’ standard methodology, which defines the cap as twice the liquidity available under the liquidation bonus. Based on this approach, we propose an initial supply cap of 30M.

Given stS’s yield-bearing nature and the historically limited use cases for borrowing yield-bearing assets, we recommend setting stS as non-borrowable at this time.

Oracle/Pricing

We recommend pricing stS based on its internal exchange rate with S using the convertToAsset function in the stS contract, combined with the Chainlink S/USD price feed.

CAPO

The smooth APY trend observed indicates that stS’s reward distribution is consistent without drastic fluctuations. Given this, we recommend setting a 7-day MINIMUM_SNAPSHOT_DELAY, which is sufficient to obtain a stable rolling APY. Following this, we propose a maxYearlyRatioGrowthPercent of 11.04%.

Specification

We have aligned with @LlamaRisk on the following parameter specification:

Parameter Value
Asset stS
Isolation Mode No
Borrowable No
Collateral Enabled Yes
Supply Cap 30,000,000
Borrow Cap -
Debt Ceiling -
LTV 66%
LT 68%
Liquidation Penalty 10%
Liquidation Protocol Fee 10.00%
Variable Base -
Variable Slope1 -
Variable Slope2 -
Uoptimal -
Reserve Factor -
Stable Borrowing Disabled
Flashloanable Yes
Siloed Borrowing No
Borrowable in Isolation No
E-Mode Category stS/wS

stS/wS Liquid E-mode Configuration

Parameter Value Value
Asset stS wS
Collateral Yes No
Borrowable No Yes
Max LTV 87% -
Liquidation Threshold 90% -
Liquidation Bonus 1% -

CAPO

maxYearlyRatioGrowthPercent ratioReferenceTime MINIMUM_SNAPSHOT_DELAY
11.04% monthly 7

wS

Parameter Current Value Recommended Value
UOptimal 45% 80%
Slope 1 7.0% 3.5%

Disclaimer

Chaos Labs has not been compensated by any third party for publishing this recommendation.

Copyright

Copyright and related rights waived via CC0

4 Likes

Hi @LlamaRisk @ChaosLabs,

We are excited to see stS listed on Aave and expect it to drive significant AUM upside on the Sonic instance of Aave v3.

May we suggest increasing the Uoptimal on wS Reserve to 90% in support of enhancing the appeal of the stS collateral and wS debt eMode.

3 Likes

stS technical analysis


Summary

This is a technical analysis of all the smart contracts of the asset and its main dependencies.

Disclosure: This is not an exhaustive security review of the asset like the ones done by the Beets Team, but an analysis from an Aave technical service provider on different aspects we consider critical to review before a new type of listing. Consequently, like with any security review, this is not an absolute statement that the asset is flawless, only that, in our opinion, we don’t see significant problems with its integration with Aave, apart from different trust points.



Analysis


stS is an LST representing $S staked via the Beets platform on the Sonic blockchain, accruing staking rewards from the $S delegated to Sonic’s PoS validators. Users can mint stS at its current exchange rate by depositing S, and redeem S later on, after a 14-day unstaking period.


For the context of this analysis, our focus has been on the following aspects, critical for the correct and secure integration with Aave:

  • Mechanism to update the exchange rate of the asset for the underlying ETH, in this case, S.
  • A recommendation of pricing strategy to be used in the integration asset <> Aave.
  • Any miscellaneous aspect of the code we can consider important.
  • Analysis of the access control (ownerships, admin roles) and the nature of the entities involved in the system. Regarding the table permissions’ holders and their criticality/risk, it is done following these guidelines:
Criticality Description
CRITICAL Usually super-admin functionality: it can compromise the system by completely changing its fundamentals, leading to loss of funds if misused or exploited. E.g. proxy admin, default admin
HIGH It can control several parts of the system with some risk of losing funds. E.g., general owners or admin roles involved in the flow of funds
MEDIUM It can cause malfunction and/or minor financial losses if misused or exploited. E.g., fee setter, fee recipient addresses
LOW It can cause system malfunctions but on non-critical parts without meaningful/direct financial losses. E.g., updating descriptions or certain non-critical parameters.
Risk Description
:green_circle: The role is controlled via a mechanism we consider safe, such as on-chain governance, a timelock contract, or setups involving multi-sigs under certain circumstances.
:yellow_circle: The role is controlled in a way that could expose the system and users to some risk depending on the actions it can control.
:red_circle: The role is controlled via a clearly non-secure method, representing risks for the system and users.

General points

  • It relies on a single contract with most dependencies from OZ for access control, tokenization, upgradability, and security. The proxy contract uses the OZ UUPS upgradable pattern.
  • The upgradeability admin of the system is an OZ Timelock with a 3-week delay.
  • The system uses a role-based access control split across Timelocks, Safe wallets, and one EOA (for automation purposes).

Contracts

The following is a non-exhaustive overview of the main smart contracts involved with stS.


stS

The main contract of the system and entry point for minting stS. Users can deposit S for stS at its current exchange rate. Later, users can request redemption and wait 14 days to withdraw S. It uses a role-based access control, where operators can delegate S to validators via the Special Fee Contract (SFC) to start accruing rewards, a claimer to claim staking rewards, and a default admin in charge of more sensitive permissions. It is an upgradable contract using the OZ UUPS pattern.

Permission Owner functions Criticality Risk
owner: 3-week Timelock upgradeAndCall CRITICAL :green_circle:
DEFAULT_ADMIN_ROLE: 1-day Timelock setWithdrawDelay, setTreasury, setProtocolFeeBIPS, setUndelegatePaused, setUndelegateFromPoolPaused, setWithdrawPaused, setDepositPaused HIGH :green_circle:
OPERATOR_ROLE: 3-of-6 Safe delegate, operatorInitiateClawBack, operatorExecuteClawBack, donate, pause HIGH :green_circle:
CLAIM_ROLE: EOA (0xFaC3…1718) claimRewards HIGH :green_circle:
  • Access Control
    • The DEFAULT_ADMIN_ROLE controls the general configuration of the stS system and pauses isolated parts of the system.
    • The Default admin can update the withdrawal delay period, the protocol fee, and the treasury address that receives the fees via the setWithdrawDelay(delay), setProtocolFeeBIPS(fee), setTreasury(address) functions, respectively.
    • The default admin can pause deposits, withdrawals, and delegations via the setDepositPaused(bool), setWithdrawPaused(bool), setUndelegatePaused(bool), setUndelegateFromPoolPaused(bool) functions, respectively.
    • The operator can delegate S to validators via the delegate(validatorId, amount) function. It delegates by calling the SFC.delegate(validatorId, amount) contract, which transfers the amount of S to the corresponding validatorId.
    • The operator can request a withdrawal of the delegated assets from a validator by calling the operatorInitiateClawBack(validatorId, amount) function. After the 14-day unstaking period, the operator can finish it by calling the operatorExecuteClawBack(withdrawId, bool emergency) function.
    • The operator can pause the entire system (deposits, withdrawals, delegations) via the pause() function.
    • The operator can increase the exchange rate via the donate(msg.value) function.
    • The claimer can claim staking rewards from multiple validators via the claimRewards(validatorsIds[]) function.
  • Deposit and Withdrawals
    • Users can deposit S via the deposit(amount) function. Internally, the function verifies that at least 0.01 S was deposited, calculates the actual exchange rate via the convertToShares(amount) function, increases the totalPool for internal accounting, and then mints stS shares to the user.
    • Users can request a withdrawal via the undelegate(validatorId, amount) and undelegateFromPool(amount) functions. The main difference between them is that the first method will undelegate the amountAssets from the validatorId via the SFC.undelegate(validatorId, withdrawId, amountAssets) function decreases the amount from the totalDelegated, while the second uses the assets within the stS contract, reducing the amount from the totalPool storage variable.
    • The minimum amount that users can request is 0.000001 S.
    • Both functions will burn the stS shares from the user and create a withdrawId for the user, with the kind of withdrawal (POOL, VALIDATOR) and the amount.
    • After the 14-day withdrawDelay period, users can claim their S via the withdraw(withdrawId, bool emergency). The emergency flag is marked as true when the user is concerned that his assets have been slashed, and the amount withdrawn will be less than the actual request.
  • Exchange Rate
    • The stS exchange rate can be obtained by the general ERC4626 function convertToAssets(shares), which internally uses the totalAssets() and totalSupply(). There is also a getRate() function that calls convertToAssets(1 ether).
    • The system relies on a proper internal accounting, where the totalAssets() is composed of the sum of totalPool (S in the stS contract), totalDelegated (S delegated to validators), and the pendingClawBackAmount (amount requested to be unstaking from validators).
  • Delegation, staking, and rewards
    • The delegation of S to Sonic validators starts via the delegate(validatorId, amount) function, which will call the SFC (Special Fee Contract), which tracks validators and delegators distributing rewards to them. Internally, the stS contract will decrease the amount from totalPool and add to the totalDelegated storage variable. There is no minimum S that can be delegated.
    • The undelegation/withdrawal from the SFC contract happens in a two-step process, where first operators request it via the operatorInitiateClawBack(validatorId, amountAssets), which will create a withdrawId with the kind CLAW_BACK and call SFC.undelegate(validatorId, withdrawId, amountAssets). It also internally accounts for decreasing the amountAssets from totalDelegated to adding it to the pendingClawBackAmount storage variable.
    • After the 14-day withdrawal waiting period, the operator will call operatorExecuteClawBack(uint256 withdrawId, bool emergency), which internally calls SFC.withdraw(validatorId, withdrawId). Internally, it is accounted for by decreasing the amountAssets from the pendingClawBackAmount and adding it to the totalPool storage variable.
    • The emergency parameter flags the acknowledgment of the operator that the validatorId might have been slashed, which affects the number of assets withdrawn, and it is very important to mention that this will decrease the stS <> S exchange rate.
    • The claimer (automated EOA) claims staked rewards via the claimRewards(validatorIds[]) function, claiming the rewards in the SFC contract of each validatorId and verifying that the total claimed is at least 0.000001 S. Internally, a protocolFeeBIPS of 10% is applied to the rewards claimed and sends the fee to the treasury address. It finishes by adding the remaining to the totalPool storage variable, increasing the stS <> S exchange rate.


Pricing strategy

We suggest pricing stS by using a CAPO adapter with the exchange rate provided by the stS contract and price component using the S Chainlink Feed.
We can confirm that the stS is safeguarded against any kind of donation attack due to its internal accounting for S across the system.

However, it is important to mention that the system contains a donate(msg.value) function, only callable by the operator, that allows S to be sent to the contract, increasing the exchange rate.

Additionally, even if not in our technical scope, the asset is slashable both high-level and on the smart contract, so risk contributors should take that into account for parameter suggestions.



Miscellaneous

  • The system has 2 security reviews from Trail of Bits and Spearbit with no High or Critical findings. The reports can be found here.
  • The system has an Immunefi bug bounty of 200k. More details can be found here.

Conclusion

We think stS doesn’t have any problem in terms of integration with Aave, and there is no major technical blocker for listing.

5 Likes

Thank you @bgdlabs , @LlamaRisk and @ChaosLabs .

The current proposal has been escalated to ARFC Snapshot.

Vote will start tomorrow, we encourage everyone to participate.

1 Like

After Snapshot monitoring, the current ARFC Snapshot ended recently, reaching out both Quorum and YAE as winning option with 576.9K votes.

Therefore [ARFC] Add stS to Aave v3 Sonic Instance has PASSED.

Next step will be the publication of an AIP for final enforcement and confirmation of the proposal.