Overview
Chaos Labs supports the listing of openUSDT, tBTC, WBTC, and LBTC on Aave’s BOB deployment based on their risk profiles. Our parameter recommendations for these assets can be found in the sections below.
For solvBTC and xSolvBTC, Chaos Labs collaborated closely with the Solv team to improve the internal oracle mechanism and enhance the safety of these assets for listing on Aave. The Solv team was highly responsive and collaborative throughout the process, implementing the necessary changes we recommended. As a result, we also support the listing of solvBTC and xSolvBTC, and our parameter recommendations for these assets are included in this analysis.
Solv Protocol
Solv Protocol serves as both a tokenization and LST provider for the Bitcoin ecosystem, enabling Bitcoin to be utilized across EVM-compatible chains. Users can deposit either native BTC or supported wrapped BTC tokens (such as WBTC, BTCB, BTC.b, and others). Based on user preference, Solv protocol issues either solvBTC or BTC backed liquid staking tokens, such as xSolvBTC (formerly solvBTC.BBN), solvBTC.BERA, and solvBTC.JUP.
xSolvBTC is a Bitcoin LST backed by BTC staked to the Babylon network, inheriting Babylon’s associated slashing risk — a topic we explored in our Staking Penalties on Babylon’s Bitcoin Staking Protocol post. It is exclusively minted and redeemed 1:1 using solvBTC.
solvBTC is a non-yield-bearing token backed by native BTC and supported Bitcoin derivatives. It is not staked in any DeFi protocol, making it free from smart contract risks and slashing exposure. Users can mint solvBTC using native BTC or wrapped variants. However, redemptions are limited to Bitcoin derivatives, redeeming solvBTC for native BTC is not currently supported.
Issuing BTC-based wrappers (solvBTC) and BTC LSTs (xSolvBTC) is inherently complex due to the lack of a native smart contract layer on the Bitcoin network. While these tokenized versions of BTC are deployed on EVM chains, the underlying transactions and value typically reside on the Bitcoin network. To streamline this process, Solv Protocol has introduced the Staking Abstraction Layer (SAL), a core infrastructure component that abstracts away these complexities and simplifies integration across chains.
SolvBTC
solvBTC is a non yield bearing token issued by Solv Protocol, designed to represent BTC on EVM-compatible chains. It is backed by native BTC and a set of supported wrapped BTC assets. Unlike liquid staking tokens, solvBTC is not staked in any protocol and therefore avoids exposure to smart contract risk, slashing penalties, or protocol-level failures. Its primary role is to serve as a foundational BTC wrapper within Solv Protocol’s infrastructure, including its use as the base asset for minting xSolvBTC.
Mint
When users want to mint solvBTC, they can do so using native BTC and a range of wrapped BTC assets, including WBTC, cbBTC, FBTC, tBTC, BTCB, BTC.b, M-BTC, and RBTC, across 14 different networks. Minting solvBTC with native BTC is only supported on BNB Chain, meaning the minted solvBTC will initially be received on BNB Chain. However, it can be bridged to other chains via Chainlink’s CCIP.
To mint solvBTC on EVM based chains, the user calls the createSubscription() function in the SolvBTCRouter contract. Within this function, the OpenFundMarket.subscribe() function is invoked, which calculates how much value the user will receive based on the deposited currencyAmount.
In the implementation of OpenFundMarket.subscribe(), we see that:
However, the Net Asset Value (NAV) used in the calculation is determined based on the poolInfo.valueDate, which is specific to each poolID, in relation to the current block.timestamp.
-
If block.timestamp < poolInfo.valueDate, the NAV is hardcoded to 1.
-
If block.timestamp > poolInfo.valueDate, the NAV is dynamically pulled from a price oracle via the NavOracle contract using the getSubscribeNav() function.
Based on the NAV, the amount of solvBTC tokens minted is determined accordingly.
NavOracle.setSubscribeNavOnlyMarket() function is used to update the onchain NAV value, and the SetSubscribeNav event is emitted once the NAV is set. Looking at the NAV values for the top BTC wrappers backing solvBTC it appears that the NAV is updated a few times per week for each asset on average, but it is consistently set to 1.
To mint SolvBTC via a native BTC deposit on Bitcoin network, users send BTC to designated addresses managed by a trusted custodian.
An oracle system continuously monitors the Bitcoin network to ensure transaction finality. It verifies critical details such as output scripts, block confirmations, and transaction integrity, ensuring each deposit meets stringent security standards.
Once a deposit is confirmed, the Staking Abstraction Layer (SAL) generates a deposit proof, a data package containing the depositor’s transaction details, the amount of Bitcoin deposited, and the intended recipient’s address on the destination chain.
This deposit proof is then relayed to the destination chain, currently supported only on BNB Chain, where a minting smart contract validates the proof against internal records and reserve balances. Upon successful verification, the contract mints an equivalent amount of SolvBTC and transfers it to the user’s wallet.
Redemption
Redemptions work in reverse compared to minting, with a few additional nuances. To initiate a redemption, the user calls the createRedemption() function on the SolvBTCRouter contract. The user must send their solvBTC tokens back to the contract, which burns them and mints an ERC-721 redemption token. This token represents the user’s claim on a future redemption payout and is sent to the user’s address. ERC-721s are non-fungible tokens and can be transferred or sold on secondary markets. This allows users to sell their future redemption payout rights in advance at a discount to access immediate liquidity, similar to how factoring works in traditional finance. However, while this is technically possible, active and liquid secondary markets for such discounted future claims have not yet materialized onchain.
Once the redemption request is created, it is processed off-chain by the Solv Protocol.
According to Solv Protocol, user redemption requests are expected to be processed within 7 days. Requests submitted on weekends or public holidays are processed collectively on the following business day.
Redeeming native BTC on the Bitcoin network is not currently supported — minting with native BTC into solvBTC is a one-way process for now. As a result, you can only redeem wrapped BTC assets such as WBTC, cbBTC, tBTC, FBTC, and others.
After the redemption is settled off-chain, the user can claim their underlying collateral by calling the claimTo() function on the MultiRepayableDelegate contract. This triggers MultiRepayableConcrete.claimableValue() for the specific redemption ID. The claimableValue() function calculates the claimable amount based on the redemption NAV, which is updated via an oracle. However, similar to how the mint NAV is handled, it is updated infrequently and is often set to 1, effectively setting the exchange rate between solvBTC and other wrapped BTCs to 1:1.
Once the claimable value is determined, the corresponding ERC-3525 tokens (acting as receipts) are burned, and the underlying assets are unlocked and made available to the user.
In addition, Solv Protocol also allows redemptions to be canceled before being claimed and enables matured redemptions to be claimed in multiple parts if needed.
Redemption Processing Times on BOB
According to Solv Protocol, most solvBTC redemptions are expected to be completed within 7 days. In practice, actual redemption times vary based on the size of the request, with larger redemptions often prioritized.
On the BOB Chain, high-value redemptions—particularly those exceeding 40 BTC—are frequently processed within a single day, reflecting the protocol’s operational preference to expedite larger withdrawals.
As illustrated in the chart below, over 65% of all redemption request have been processed and claimed in under 7 days, while nearly 90% have been completed within 8 days.
When analyzing redemptions by total value, the trend becomes even more pronounced: approximately 70% of solvBTC redeemed by volume has been claimed within 1 day. This indicates a clear prioritization of high value redemptions.
Market Capitalization
As of now, solvBTC has a total supply of approximately 9,700 tokens distributed across 13 EVM-compatible chains.
On the BOB network, solvBTC was deployed approximately 11 months ago. Following its initial launch, solvBTC supply on BOB surged to around 2,500 tokens. However, circulating supply on BOB has since stabilized around 665 solvBTC.
Notably, over 35% of the solvBTC supply on BOB is currently deposited into Pell Network, the leading BTC restaking protocol on the network. These deposits are mostly underutilized and passively earning Solv and BOB points.
Liquidity
The aggregated liquidity for solvBTC currently stands at approximately $26.7 million, distributed across three primary pools. However, the composition of this liquidity is important for evaluating actual onchain depth.
Two of these pools are paired with xSolvBTC, accounting for $16 million in total. While these pools are relevant for internal conversions within the Solv ecosystem, they do not materially contribute to solvBTC’s standalone liquidity, as both assets are tightly coupled and rely on solvBTC as collateral.
The most relevant source of external liquidity is the solvBTC/WBTC pool, which holds approximately $15.4 million in total value. Within this pool, $5.48 million is held in WBTC (equivalent to 50.38 WBTC), providing meaningful exit liquidity for solvBTC holders.
This pool currently allows the sale of up to 50 solvBTC (≈ $5.42 million) into WBTC with less than 2.5% price impact.
However, WBTC itself is highly illiquid on the BOB network. Most of its liquidity is concentrated in pairs against other Bitcoin derivatives such as tBTC and fBTC, rather than against stablecoins. The primary WBTC/USDT pool holds only around $200,000 in total liquidity, with $135,000 in USDT available. As a result, users can only trade approximately 0.5 solvBTC (~$58,405) into USDT incurring more than 8% price impact.
This introduces a second order liquidity constraint: while solvBTC may appear liquid via its WBTC pair, converting WBTC to stablecoins on BOB is highly constrained, limiting solvBTC’s practical liquidity for users seeking stablecoin exit routes. This has direct implications for onchain liquidations, liquidators attempting to repay debt positions collateralized by solvBTC may face slippage or capital inefficiencies when trying to off-ramp to stable assets, especially under volatile conditions or cascading liquidation events.
Backing
Historically, solvBTC has been backed by a combination of native BTC held on the Bitcoin network and a variety of BTC derivatives (such as M-BTC, WBTC, BTC.b, BTCB, and others) sourced from multiple chains. At times, the share of solvBTC backed by BTC derivatives exceeded that of native BTC, introducing depeg risk tied to the underlying wrappers. This was particularly relevant given the varying custody models, liquidity profiles, and risk characteristics across these derivative tokens.
This composition exposed the protocol to potential backing integrity issues in the event of a deviation between the market value of the BTC derivatives and native BTC, particularly during stress scenarios or wrapper specific incidents.
However, since June 2025, the backing composition has significantly improved. More than 99% of solvBTC supply is now backed by native BTC held in custody directly on the Bitcoin network, with verifiable custody infrastructure. This shift effectively eliminates the risk of collateral depegging, as solvBTC is now overwhelmingly collateralized by Bitcoin in its canonical, base-layer form rather than synthetic or wrapped representations.
This strengthening of solvBTC’s collateral base as a BTC wrapper, improves its suitability for use as collateral in DeFi protocols, and reduces systemic risk associated with derivative based reserves.
Bridging
SolvBTC leverages integrations with Chainlink’s Cross-Chain Interoperability Protocol (CCIP) to enable cross-chain transactions. This makes solvBTC available across a wide range of networks, including Ethereum, BNB Chain, Arbitrum, Merlin, Avalanche, Mantle, Bob, Base, Linea, Mode, Taiko, Bera, Corn, Rootstock, Sei, Soneium, Sonic, zkSync Era, AILayer, Core, and Bitlayer.
Risks
1. Collateral Risk
Historically, solvBTC carried indirect exposure to the risks associated with derivative Bitcoin wrappers (such as WBTC, BTCB, BTC.b, and others), since these assets were used to collateralize a portion of the solvBTC supply. This introduced depeg risk in cases where the market value or solvency of the derivative deviated from native BTC.
As covered in the Backing section, this risk has been fully mitigated as of June 2025. Currently, over 99.5% of solvBTC is backed by native BTC held in verified custodial infrastructure on the Bitcoin network. This significantly strengthens solvBTC’s risk profile and removes dependency on third-party wrapper integrity. However, it remains important to monitor the collateral composition going forward to ensure continued collateral quality.
2. Custodian Risk
solvBTC depends on custodians to securely hold native BTC and process associated transactions. This creates exposure to operational and counterparty risks inherent in any custodial setup.
In the event of custodian downtime or service disruption, solvBTC redemptions may be temporarily paused. In more extreme scenarios, such as a loss of custody keys, user funds could be at risk. While this type of risk is challenging to quantify and may vary across custody providers, it should be acknowledged as a critical component of solvBTC’s trust model.
3. Slashing Risk via xSolvBTC
While solvBTC itself is not staked and is free from slashing exposure, it may inherit slashing risk indirectly through its relationship with xSolvBTC.
xSolvBTC is backed by BTC staked to the Babylon network and carries slashing risk under Babylon’s validator slashing conditions. Because xSolvBTC can be redeemed for solvBTC at a 1:1 rate, solvBTC becomes vulnerable in edge cases where mass redemptions are triggered immediately following a slashing event, before the solvBTC:xSolvBTC exchange rate is updated to reflect the loss.
This creates a scenario where slashing losses could be socialized across solvBTC holders, should all xSolvBTC holders redeem for solvBTC at par before pricing adjustments occur. Although the current Babylon slashing penalty is limited to just 0.1%, capping the immediate risk impact, this parameter may increase over time, warranting close monitoring.
Mitigation Strategy:
To address this potential arbitrage vector and protect solvBTC holders, we recommend that Solv Protocol implement an off-chain Risk Oracle that monitors slashing transactions on the Bitcoin network. Upon detecting a slashing transaction, the oracle should automatically freeze xSolvBTC minting and redemption contracts across all supported chains. This mechanism would prevent exploitative behavior and provide time for protocol maintainers to update pricing or take corrective action.
LTV, Liquidation Threshold, and Liquidation Bonus
Based on the BOB team’s expected incentives to deepen onchain markets, we recommend adjusting solvBTC’s risk parameters to reflect a cautiously optimistic outlook. Specifically, we propose setting the LTV ratio at 75%, the LT at 70%, and the LB at 10%.
These parameters remain conservative relative to other networks, aiming to limit systemic risk while enabling basic capital efficiency.
Supply & Borrow Caps
Given solvBTC’s current circulating supply of approximately 665 tokens on the BOB network and the relatively limited depth of onchain stablecoin liquidity for BTC pairs, we recommend a supply cap of 100 solvBTC and a borrow cap of 80 solvBTC.
These conservative initial limits are intended to contain systemic exposure and allow for controlled onboarding of solvBTC into the lending markets. As market liquidity these caps can be revisited and adjusted accordingly.
E-Mode
We propose an E-Mode configuration where solvBTC is used exclusively as collateral and WBTC is borrowable. We recommend setting the LTV at 80%, the LT at 82%, and the LB at 4% to support efficient BTC-correlated borrowing while containing risk within a high correlation asset pair.
Oracle Configuration/Pricing
For solvBTC, given that it is fully backed by native BTC held on the Bitcoin network, we propose using the BTC/USD Chainlink price feed as the sole pricing source.
xSolvBTC
xSolvBTC is a yield bearing LST issued by Solv Protocol, backed by BTC staked to the Babylon network. xSolvBTC is exclusively minted and redeemed 1:1 against solvBTC, meaning solvBTC functions as the gateway asset for entering and exiting xSolvBTC positions.
With the latest contract upgrade, minting and redemption of xSolvBTC are facilitated through the XSolvBTCPool contract and are based on the current Net Asset Value (NAV) of xSolvBTC, which is set by an admin via the XSolvBTCOracle contract. This upgrade enables atomic redemptions, allowing users to convert xSolvBTC to solvBTC in a single transaction without delay.
Mint
To mint xSolvBTC, users call the deposit() function on the XSolvBTCPool contract and supply an amount of solvBTC. The process is as follows:
- NAV is fetched from the
XSolvBTCOracle contract, which is a internal oracle that reflects the latest price of xSolvBTC in solvBTC.
- The calculated number of xSolvBTC shares is minted and transferred to the user.
This process is atomic, finalized within a single transaction, and relies directly on the most recent NAV published to the onchain oracle. Minting is only permitted if the depositAllowed flag is enabled by the admin.
Redemption
To redeem solvBTC, users call the withdraw() function function on the XSolvBTCPool contract and specify the number of xSolvBTC shares to redeem. The following steps are executed:
-
The xSolvBTC shares are burned from the user’s balance.
-
The contract calls getValueByShares() to determine the solvBTC amount owed:
-
A withdrawal fee is applied to the calculated amount. The contract allows the fee to be configured and it is currently set at 0.05% onchain, following a recent reduction from the previous rate of 0.2%
-
The fee portion is sent to a designated fee recipient.
-
The remaining solvBTC is minted and transferred to the user.
To prevent abuse or manipulation, the contract enforces an upper bound via the maxMultiplier parameter, which is currently set to 1.5. This means that the solvBTC redemption amount cannot exceed 1.5 times the implied solvBTC value of the user’s xSolvBTC shares based on the most recently published NAV.
NAV Updates
The NAV is not calculated dynamically, but rather manually set by an admin via the XSolvBTCOracle. Updates must adhere to the following constraints:
-
NAV cannot be updated more than once in any 24-hour period.
-
NAV growth is capped by the withdrawFeeRate parameter (e.g., 0.05%), ensuring it cannot increase beyond acceptable bounds in a single update.
-
NAV growth per update is capped at 1%, even if the withdrawFeeRate parameter is set higher than 1%, ensuring price adjustments remain within safe bounds.
The NAV was set to 1 during the initial deployment of the XSolvBTCOracle and has not been updated since. This static initialization occurred when the XSolvBTCPool was first configured, and no further NAV changes have been made to date.
Reward Distribution
Solv Protocol currently supports two types of LSTs. The first category consists of NAV increasing LSTs, where the NAV is periodically updated to reflect generated rewards. In such cases, holders receive more of the base asset upon redemption as the NAV accrues over time.
By contrast, xSolvBTC is not a NAV increasing LST. Its NAV remains fixed at 1, and rewards are not embedded into the NAV. Instead, xSolvBTC holders receive rewards through direct airdrops, distributed separately from the redemption mechanism.
Market Capitalization
xSolvBTC was launched approximately 10 months ago (in August 2024) on the BOB network. xSolvBTC has been deployed across multiple EVM compatible chains and currently maintains a circulating supply of approximately 5,340 tokens.
On the BOB network specifically, xSolvBTC supply peaked in late 2024 at around 1,750 tokens, driven by early adoption and staking demand. However, supply has since declined and stabilized around 370.
Approximately 80% of the xSolvBTC supply on BOB is currently deposited in a Uniswap pool, where it is paired with solvBTC.
Liquidity
There are three primary liquidity pools for xSolvBTC on the BOB network. Two of these are paired with solvBTC, comprising approximately $16 million in total liquidity. However, these pools have recently become redundant, as xSolvBTC and solvBTC can already be converted atomically via the protocol. As a result, they no longer provide a meaningful enhancement to xSolvBTC’s standalone liquidity.
The third pool is against WBTC; however, the depth on the WBTC side is currently negligible, with only 0.37 WBTC (~$41,000) available. As a result, external liquidity for xSolvBTC is extremely limited.
For example, swapping just 0.5 xSolvBTC (~$55,265) into USDT would incur approximately 9% price impact. This lack of stablecoin liquidity severely limits the ability to efficiently liquidate xSolvBTC positions that underwrite stablecoin debt.
It is important to note that, xSolvBTC benefits from its ability to be atomically converted to and from solvBTC. This atomic convertibility ensures that xSolvBTC can directly inherit solvBTC’s onchain liquidity without the need for separate deep liquidity pools. However, as previously discussed, solvBTC’s onchain liquidity on BOB is also highly limited.
Bridging
xSolvBTC supports cross-chain transfers via Chainlink’s CCIP, the same mechanism used by solvBTC.
This bridging infrastructure allows xSolvBTC to be moved between chains, facilitating cross-chain utility without the need for external custodians.
Risks
xSolvBTC inherits the base risks associated with solvBTC, including custodial risk and operational security of solvBTC’s underlying system. However, it also introduces additional risks due to its integration with the Babylon network, which introduces slashing risk and smart contract risk on top of solvBTC’s existing risk profile.
As detailed in our Staking Penalties on Babylon’s Bitcoin Staking Protocol analysis, the Babylon protocol enforces a slashing mechanism that penalizes misbehavior. Currently, the maximum theoretical slashing penalty for BTC staked via Babylon is set at 0.1%. However, this penalty is subject to change and may increase in the future as more Babylon Supercharged Networks (BSNs) are launched and Babylon’s economic security model evolves.
This creates a potential mismatch with the redemption fee structure in the xSolvBTC system. The current redemption fee for converting xSolvBTC back to solvBTC is 0.05%, which is lower than the maximum possible slashing penalty. In the event of a slashing incident on Babylon, sophisticated users could quickly redeem their xSolvBTC for solvBTC before the NAV is updated manually to reflect the reduced backing. This behavior can cause the backing loss to be socialized across all solvBTC holders, depending on the size of the slashing and the number of xSolvBTC holders redeeming before the exchange rate is updated. As a result, solvBTC holders with no exposure to xSolvBTC may be penalized, or the remaining xSolvBTC holders after the exchange rate adjustment may be disproportionately impacted.
Even though the slashing penalty is currently set at a relatively low 0.1%, the redemption fee discrepancy creates a structural risk that can impact solvBTC holders under certain conditions.
To mitigate this risk while preserving the atomic convertibility between solvBTC and xSolvBTC, we recommend that the Solv protocol integrate a slashing aware risk oracle. Such an oracle would allow the protocol to automatically pause redemptions from xSolvBTC to solvBTC upon detection of a slashing event on Babylon. This would prevent the propagation of slashing losses to solvBTC holders and help ensure fair treatment across both token holders.
We also recommend that Aave integrate with the same slashing aware oracle to automatically freeze solvBTC and xSolvBTC markets in the event of a Babylon slashing incident. This coordination between protocol and lending markets is essential to avoid value extraction, maintain fair pricing, and limit arbitrage opportunities during slashing-related volatility.
LTV, Liquidation Threshold, and Liquidation Bonus
Given the structural similarity and atomic convertibility between xSolvBTC and solvBTC, we propose applying the similar conservative parameters to xSolvBTC initially.
These restrictive parameters are intended to discourage general usage of xSolvBTC as collateral outside of designated E-Mode categories, such as the xSolvBTC_solvBTC and xSolvBTC_WBTC e-modes.
Supply & Borrow Caps
We propose a supply cap of 50 xSolvBTC and a borrow cap of zero. These limits are intended to minimize lending market exposure to an asset that carries slashing risk and has the ability to claim BABY rewards. Given the lack of a clear use case for borrowing xSolvBTC, borrowing is not enabled.
E-mode
To support capital efficient usage of xSolvBTC, we propose two E-Mode configurations.
The first is a dedicated E-Mode pairing xSolvBTC with solvBTC. In this setup, xSolvBTC would be enabled exclusively as collateral, while solvBTC would be borrowable only. We recommend setting the LTV at 83%, the LT at 85%, and the LB at 3%. This configuration facilitates efficient intra-protocol leverage while preserving risk containment, particularly given the current liquidity constraints on the BOB network.
The second proposed E-Mode category groups xSolvBTC with solvBTC and WBTC to enable broader BTC-correlated collateral usage. In this configuration, xSolvBTC remains the sole collateral asset, while both solvBTC and WBTC are borrowable. Given the additional liquidity and price volatility considerations associated with WBTC, we recommend a slightly more conservative risk posture: an LTV of 80%, LT of 82%, and a 4% Liquidation Bonus. This E-Mode category expands borrowing flexibility while preserving appropriate liquidation margins.
Oracle Configuration/Pricing
We recommend pricing xSolvBTC using a composite mechanism that accounts for both its underlying asset exposure and potential internal oracle risk. Specifically, we suggest using Chainlink’s BTC/USD price feed as the primary feed, combined with the onchain xSolvBTC/solvBTC exchange rate published via Solv’s internal oracle.
Although xSolvBTC is a yield bearing token, it does not currently accrue value directly into the token. Instead, staking rewards are distributed separately to users. As a result, the exchange rate between xSolvBTC and solvBTC does not increase monotonically, and is currently fixed at 1. Furthermore, slashing events on Babylon can reduce the value of staked BTC, necessitating a pricing model that can account for such negative events.
To protect the protocol in the event that Solv’s internal oracle is compromised, we propose introducing a cap adapter, similar to the approach used for stablecoins. This adapter would enforce an upper bound on the xSolvBTC/solvBTC exchange rate used in pricing calculations. We recommend setting the price cap at 1.04, meaning the protocol would never treat xSolvBTC as being worth more than 1.04 times the value of solvBTC, regardless of the internal NAV. This provides a buffer against manipulation while preserving upside flexibility for future yield accrual mechanisms.
In the future, if Solv Protocol chooses to internalize xSolvBTC’s value accrual, such that the token automatically accrues yield and trades at a structural premium to BTC and solvBTC, similar to the expected transition of LBTC, the cap adapter can be upgraded to a CAPO adapter.
This composite approach, anchoring to BTC/USD, incorporating the solvBTC reference price, and enforcing a cap on internal conversion rates, offers a robust and conservative pricing configuration for xSolvBTC in its current form.
Collaboration with Solv Protocol on xSolvBTC Safety Improvements
Chaos Labs has worked closely with the Solv team to enhance the safety of xSolvBTC for listing on Aave. This collaboration has focused on two main areas:
1. Internal Oracle Mechanism for Minting and Redemption Pricing
Negative Rebase Support – In the original implementation, the xSolvBTC internal exchange rate oracle only allowed monotonically increasing values, meaning it could not reflect a drop in value after a slashing event. We recommended enabling negative rebases to allow the oracle to adjust downward if necessary. The Solv team has implemented this functionality.
Update Frequency Safeguard – To reduce manipulation risk, we suggested introducing a minimum time interval between consecutive oracle updates. The Solv team implemented a safeguard that limits oracle updates (up or down) to once per day.
Update Magnitude Cap – The Solv team has also capped per-update changes at the withdrawFeeRate (currently 5 basis points). To further protect against manipulation of the withdrawFeeRate itself, an additional safeguard was added: updates cannot exceed 100 basis points in either direction per function call, even if the withdrawFeeRate is increased. For example, if the withdrawFeeRate is set to 50%, the oracle update would still be capped at 1%.
2. Atomic Redemption Risk Management
xSolvBTC can be redeemed atomically for solvBTC. In a slashing event, the penalty could exceed the withdrawFeeRate, creating a risk where sophisticated holders frontrun the negative rebase by redeeming before the adjustment is applied.
We recommended adding a freeze function to temporarily halt redemptions in such scenarios. This would allow Solv Protocol to prevent redemptions until the slashing penalty is reflected in the exchange rate. The Solv team has not yet implemented this functionality but is actively considering it. The long term plan should be to integrate such a freeze mechanism with a slashing-aware Risk Oracle that can trigger freezes automatically without human intervention.
While the absence of this feature leaves a potential risk, the existing oracle safeguards reduce the likelihood of significant exploitation. We therefore do not consider its current absence a blocker for listing xSolvBTC on Aave.
OpenUSDT
OpenUSDT (oUSDT) is an interoperable stablecoin issued to unify fragmented USDT liquidity across multiple blockchain networks within the OP Superchain ecosystem. Built through a collaboration among Chainlink, Hyperlane, Celo and Velodrome, OpenUSDT utilizes a burn and mint architecture underpinned by Chainlink’s CCIP and Hyperlane’s messaging infrastructure. This approach ensures that each unit of oUSDT is always backed 1:1 by native USDT.
It supports both the XERC20 and SuperchainERC20 token standards, enabling oUSDT to operate seamlessly across EVM chains. This structure allows for native asset delivery across multiple chains without requiring bespoke token deployments or vendor specific bridge solutions.
Superswap
Superswap is Velodrome’s onchain cross-chain swap infrastructure, built as a public good for the Superchain. Its goal is to make interchain swaps feel as seamless as local swaps.
Superswaps allow users to swap tokens across different chains in a single transaction flow. Rather than requiring manual bridging followed by a swap on the destination chain, Superswaps combine the two steps. This experience is enabled by Hyperlane’s Interchain Accounts (ICAs), which let contracts on the origin chain remotely execute swaps on the destination chain on behalf of the user.
The Superswap process works as follows:
-
The user initiates a token swap on Chain A.
-
Velodrome converts the token into oUSDT on Chain A.
-
oUSDT is bridged to Chain B using Hyperlane’s Warp Routes.
-
Velodrome swaps oUSDT into the desired token on Chain B.
-
The user receives the final token on Chain B in one seamless transaction flow.
OpenUSDT as an Intermediary Stablecoin
A central design element of Superswaps is the use of a stable, fungible intermediary asset to transfer value across chains. OpenUSDT fulfills this role by serving as the intermediary stablecoin.
This design offers several advantages. First, it ensures stable value transfer, as oUSDT is backed 1:1 by native USDT, providing a medium of exchange. Second, it enables unified liquidity routing by using oUSDT as the common asset for all cross-chain swaps. Finally, oUSDT’s compatibility with both XERC20 and SuperchainERC20 token standards ensures broad interoperability, allowing Superswaps to initiate transactions seamlessly across both EVM and non-EVM environments.
Mint
The minting of oUSDT is enabled through a lock and mint mechanism centered around designated hub chains, currently Ethereum and Celo. On each hub chain, a contract called the XERC20Lockbox is deployed. Users initiate the minting process by depositing native USDT into the XERC20Lockbox on either Ethereum or Celo. Upon receiving the deposit, the protocol mints an equivalent amount of oUSDT on the user’s specified destination chain, maintaining a 1:1 backing ratio. This architecture ensures that every oUSDT token in circulation is fully collateralized by USDT locked on a canonical hub chain, enabling secure and verifiable cross-chain issuance without requiring users to interact with multiple bridge interfaces.
As of now, the majority of oUSDT’s collateral resides on Ethereum, with approximately 4.38 million USDT deposited into the Ethereum XERC20Lockbox. In contrast, the Celo hub currently holds around 565,000 USDT. This distribution reflects the dominant role of Ethereum as the primary source of backing for oUSDT across the ecosystem.
Redemption
Redemptions of oUSDT can be initiated from any supported chain, the corresponding amount of oUSDT is burned on the origin chain, and an equivalent amount of USDT is released to the user on one of the designated hub chains, either Ethereum or Celo.
The redeemed USDT is drawn directly from the XERC20Lockbox contract on the selected hub chain. Redemptions typically settle within a few minutes, enabling fast and reliable access to native USDT.
Market Capitalization & Liquidity
Since its introduction in March 2025, OpenUSDT has seen moderate adoption, reaching a circulating supply of approximately 4.8 million tokens across all Optimism chains. The majority of this supply, around 4.3 million, is on the Base chain. In contrast, the BOB chain has seen minimal adoption, with only 32 oUSDT in circulation. Due to its limited supply on the BOB chain, OpenUSDT effectively has no DEX liquidity on BOB.
There is an expectation that the existing USDT supply on BOB will eventually migrate to oUSDT, aligning with the broader goal of liquidity unification across the Superchain. The BOB team has indicated that there are upcoming LP commitments to support onchain oUSDT markets. However, these commitments have not yet materialized onchain, and without publicly verifiable data, it is not currently possible to assess the sufficiency or reliability of future oUSDT liquidity on the BOB network.
Bridging
OpenUSDT relies on Chainlink’s CCIP and Hyperlane’s secure cross-chain messaging solutions to enable bridging and interoperability across supported blockchain networks. This bridging infrastructure allows users to transfer oUSDT across chains within the OP Superchain ecosystem.
Risks
Hub Chain Dependency
Redemptions of oUSDT rely on the availability of Ethereum and Celo, where the backing USDT is held in XERC20Lockbox contracts. If either hub chain experiences downtime, users may be temporarily unable to redeem oUSDT. This risk is more acute for Celo, which, as a newer chain, may face higher chances of instability. Extended outages could delay redemptions and limit access to underlying USDT until the affected chain resumes normal operations.
Bridge and Messaging Layer Risk
The security of oUSDT’s cross-chain functionality depends on the integrity of Chainlink’s CCIP and Hyperlane’s messaging infrastructure. Any vulnerabilities, misconfigurations, or consensus failures in these layers could disrupt minting, redemptions, or interchain routing. While both systems are designed with robust security assumptions, the multi-layered architecture increases the surface area for potential failures or attacks.
Liquidity Risk
Although future liquidity commitments have been suggested, the absence of concrete and verifiable liquidity provisioning raises concerns about usability, slippage, and price execution on BOB network.
LTV, Liquidation Threshold, and Liquidation Bonus
We recommend that oUSDT not be enabled as collateral at this stage. While the asset is fully backed, it currently lacks sufficient onchain liquidity on the BOB network to support safe liquidation in the event of defaults. Until deeper and verifiable liquidity is established, the LTV, LT, and liquidation bonus should all be set to zero.
Supply & Borrow Caps
To account for the possibility of near term migration of native USDT to oUSDT and anticipated LP commitments, we propose an initial supply cap of 300,000 oUSDT and a borrow cap of 250,000 oUSDT. These limits can be revised upward in response to verified improvements in BOB side liquidity and usage. This conservative approach ensures protocol safety while allowing for gradual adoption and organic growth of oUSDT utility on BOB.
Oracle Configuration/Pricing
Given that each oUSDT token is fully backed 1:1 by native USDT, it is recommended to use the existing Chainlink USDT/USD price feed for oracle configuration. Since oUSDT does not introduce any independent market dynamics or deviation from USDT’s value, a separate oracle is not required.
Additional Asset Listings: tBTC, WBTC, LBTC
In our January 2025 Bob deployment post, we proposed the inclusion of tBTC, WBTC, and LBTC as initial listing candidates but deferred the risk parameterization. We now revisit these assets with updated supply and liquidity metrics, and propose conservative listing parameters reflecting current conditions on Bob.
Asset Overview
While tBTC and WBTC have moderate liquidity, they lack meaningful stablecoin pairs and do not accrue yield or points. LBTC, on the other hand, accrues BABY yield and incentive points, but its liquidity is highly constrained, selling just 1.45 LBTC ($159,231.99) to WBTC or tBTC incurs 10% slippage.
Risk Configuration
Due to the current lack of stablecoin liquidity on the Bob network, these assets should have limited collateral use. tBTC and WBTC should be configured as borrow-only assets that can be utilized within E-Modes but not as collateral. LBTC, which accrues yield and Babylon points, should be the sole collateral asset within a BTC-correlated E-Mode that includes tBTC and WBTC as borrowable assets.
Although the LBTC to WBTC and LBTC to tBTC trading pairs are currently illiquid, where even relatively small trades incur significant price impact, the Bob team has outlined upcoming liquidity incentives and received LP commitments aimed at improving market depth. Based on this expectation, we have adjusted the risk parameters to be slightly less conservative than they would otherwise be, while still accounting for the current state of liquidity.
Specification
Following the above analysis, we recommend the following parameter settings:
E-mode (xSolvBTC_SolvBTC)
E-mode (xSolvBTC_WBTC)
E-mode (solvBTC_WBTC)
E-mode (LBTC_BTC Correlated)
Disclaimer
Chaos Labs has not been compensated by any third party for publishing this recommendation.
Copyright
Copyright and related rights waived via CC0
