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.
stS is distributed among 11.18K holders, with the largest holder, Soli Finance’s stS-S market, accounting for 36% of the total supply.
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.
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