Beethoven x continues as Beets for swaps and liquid staking on Sonic

Sonic positions and older Fantom holdings

The Beets name accompanies the project’s expansion from its earlier Fantom operations into Sonic. Older holdings remain tied to their original network and contracts. In particular, sFTMx is a Fantom staking token, while stS represents Sonic staking exposure. A brand change does not convert one balance into the other. The migration design also treated liquidity positions separately from their underlying tokens, so an old pool receipt cannot simply function as a Sonic pool position.

Swaps use pool liquidity

The exchange uses automated market makers, which calculate trades against assets held in liquidity pools. Balancer technology separates routing, shared token accounting and each pool’s pricing rules. This architecture allows different pool designs to operate through the same exchange without giving every trade identical pricing behavior.

A swap quote reflects the selected assets, input amount, pool balances and applicable fees. Price impact measures the effect of the trade itself on execution. Slippage concerns changes between quoting and execution. The minimum output limits how little the transaction may deliver before reverting. Increasing slippage tolerance accepts worse execution; it does not replenish a thin pool. These distinctions matter when a route looks inexpensive at a small size but deteriorates at the intended amount.

Open full-size image

Pool design changes the exposure

Weighted pools support chosen asset proportions, while stable pools target assets with closely related values. The distinction concerns their pricing assumptions. A weighted pool can accommodate assets without a stable price relationship. Stable-pool mathematics concentrates trading efficiency around an expected relationship, which can break when an underlying asset loses its peg.

Rate providers let suitable pools account for changing conversion rates in tokens that earn yield. Elliptical concentrated liquidity pools use bounded price ranges and an uneven liquidity profile. Boosted pools add exposure to external yield mechanisms through their underlying assets. These designs affect both trading conditions and the risks that liquidity providers accept. A familiar token name does not establish which additional contracts or pricing assumptions a particular pool uses.

How does stS accumulate staking rewards?

stS gains staking value when net validator rewards increase the S backing its outstanding supply.

Deposits initially enter the staking contract’s pool of S. An operator delegates funds to validators, and reward collection adds net earnings back into the system. The protocol deducts its reward fee before adding the remainder. Collecting staking rewards increases the S backing stS without increasing the stS supply.

This accounting raises the staking conversion rate when rewards accrue. It does not promise a higher cash price. Changes in the market value of S can outweigh staking earnings, and a DEX quote can differ from the contract’s conversion rate.

Direct Sonic delegation leaves validator selection with the delegator. Holding stS delegates that operational work to the liquid staking system and adds its contract dependencies. The transferable token permits uses that an ordinary delegated balance cannot directly perform.

Providing liquidity adds a separate position

Liquidity provision creates a claim on a pool containing its underlying assets and accumulated fees. Pool tokens represent that claim. Their value follows the pool’s composition, trading activity and asset prices, so a deposit does not promise the same token quantities at withdrawal.

Trading can change the mix of assets that backs a position. Consequently, its value may lag behind simply holding the original assets outside the pool, even while it earns fees. This difference is commonly called impermanent loss. Fee income can offset it, but the relationship depends on actual trading revenue and price movements.

Some pools offer separate staking incentives that require depositing pool tokens into an incentive contract. Holding the pool token alone does not automatically satisfy that requirement. Similarly, placing stS inside another DeFi position adds that position’s withdrawal conditions and contract exposure. The original staking mechanism continues underneath, but access to the token now also depends on the surrounding position.

BEETS and maBEETS govern incentives

BEETS is the governance token within the Beets ecosystem, with a role distinct from S and stS. Governance influences protocol decisions and the distribution of incentives to liquidity pools. Reward budgets can change through governance, so an advertised incentive allocation should not become a permanent income assumption.

On Sonic, maBEETS uses a weighted liquidity position containing BEETS and stS. Its maturity mechanism adjusts voting power and rewards based on how long a position has been held. The design uses a financial NFT as the position receipt and requires a level-up action to activate higher maturity levels. Exiting forfeits accumulated maturity. This makes maBEETS a liquidity and governance position with its own conditions, rather than an ordinary stS balance.

Account for the costs of each operation

Swap fees, network gas and staking reward deductions apply to different parts of the transaction. Pool-specific swap fees affect exchange execution. The protocol’s share of collected swap fees describes how that fee revenue is divided, rather than another percentage charged against the entire trade amount.

Staking economics include validator compensation and the protocol’s deduction from rewards. The staking yield display accounts for these deductions; it remains an estimate of earnings rather than a fixed payout. Gas belongs to the wallet transaction and requires S on Sonic. Liquidity deposits or withdrawals that change asset proportions can also involve swap-like costs. Compare net amounts in the same asset where possible, and keep transaction costs separate from annualized yield estimates.

When can stS return to S?

stS can return to S through a market swap or a completed unstaking request.

The standard unstaking process separates the request from the later withdrawal. Its waiting period follows the applicable withdrawal configuration, and the withdrawal function must be available. Starting the request does not immediately produce spendable S. A market swap avoids waiting for that request to mature, provided a route has sufficient liquidity and acceptable execution. It can deliver less S than the staking conversion suggests. The distinction is therefore access through available market liquidity versus settlement through the staking contract.

Contract risk and the V2 exploit

Beets V2 liquidity pools suffered losses during the November 2025 Balancer V2 Composable Stable Pool exploit. That incident affected the DEX layer and disrupted liquidity routes involving stS. Sonic Labs subsequently returned recovered S to affected users. That recovery concerned the specific incident; it does not establish automatic compensation for future losses.

Staking has additional dependencies on validators and administrative controls. Validator slashing can reduce recoverable funds. The stS system includes permissions to change fees and withdrawal delays, pause operations and upgrade the contract through its access controls. An audit examines particular code and assumptions. It does not eliminate these permissions or extend automatically to every external contract that accepts stS. A position’s risk follows the contracts that actually hold or manage its assets.

Distinguish a failed transaction from missing data

A missing price or an unavailable portfolio display does not, by itself, establish a missing token balance. Beets interfaces depend on data services as well as contracts. A display failure can leave transaction records and balances intact, while a contract pause can prevent an operation even when the interface loads normally.

Use the transaction status and relevant token or position balance to identify which condition applies. A confirmed revert does not complete the intended swap or deposit, although execution can consume gas. Repeating an unavailable operation cannot bypass a contract pause or an unfinished withdrawal delay. Where a minimum-output condition caused a failure, a fresh quote may reveal changed execution terms. Another attempt makes sense only after the condition that blocked the original operation has changed.