Discover How Oracles Will Be Incorporated Into Skybridge
Swingby’s Skybridge network consists of clusters of nodes that use threshold signature cryptography (“TSS”) to form gas-optimized multi-signature wallets that offer token swaps across blockchains.
As announced 2 weeks ago, Swingby Labs partnered with Band Protocol, one of the most competent teams in the oracle space, to provide oracle services on Skybridge.
Curious about how it will work? We’ve got you covered. This article discusses the current development of SWIP-019 and how price oracles will be incorporated into Skybridge to improve its risk management system.
The current iteration of Skybridge offers bilateral direct swaps between BTC on the Bitcoin blockchain and BTC-pegged assets on Ethereum like WBTC. While these prices are meant to be exchanged at a 1:1 rate (vs. BTC), there might be either temporary or long-lasting deviations due to various factors like markets’ environment (e.g., liquidity shocks) and protocol-specific matters (e.g., incidents).
In addition, funds held in TSS addresses are solely controlled by node validators, which are required to bond SWINGBY tokens as collateral. If the bond’s total value were lower than the sum of the value held in the float, it could result in potential incentives for funds to be stolen from the protocol.
While this would require some coordination from node operators (requiring the threshold majority), along with advanced game theory elements, this aspect remains often overlooked by projects. Solutions have been implemented for assets like tBTC (where signers are required to be overcollateralized) but neglected by others.
These two risk scenarios are addressed with SWIP-019. Using one or multiple data oracle providers, Swingby’s Skybridge protocol is ought to add a stand-alone risk layer to control various external factors that may affect the well functioning of the protocol.
This integration makes it possible to monitor whether two assets become unpegged and assess the protocol’s current collateralization. By incorporating market prices into the Skybridge protocol, risk checks can be implemented, along with a dedicated logic that applies to the protocol in these adverse events.
These logics are built to act in the best interest of (1) users and (2) liquidity providers while ensuring that (3) node operators are also not penalized by bearing the entire cost of monitoring & reporting the asset market prices.
The implementation can be broken down into three components: the oracle integration, the underlying responses for (1) two bridged assets becoming unpegged & (2) the protocol being over-staked, and the required procedure to exit these alert states and consequently return to the normal state.
The high-level steps for integrating an oracle are the following:
- At a fixed frequency or upon a user’s request, the Skybridge protocol sends a request to get the oracle provider’s prices.
- The request (or set of requests) asks for the latest prices of (1) SWINGBY and (2) all bridged assets on Skybridge (e.g., BTC, WBTC, tBTC, renBTC), (3) oracle tokens (e.g., LINK, BAND).
- Swingby protocol must also retrieve the quantities of each asset staked in the pools, the quantities of SWINGBY tokens bound by validators, and the quantities held in the TSS for paying oracle services.
Once the quantities staked (in the float), the amount of SWINGBY bonded, the token quantities held by the TSS address used for paying oracle services, and the set of associated prices for all these assets are retrieved, these are used to calculate risk control metrics (described in the two subsections below).
While the price oracle is designed to be called at a periodic frequency by network validators, it is not sufficient to prevent the system from responding at a pace necessary for Skybridge to be constantly safe. This explains why third parties can call the oracle directly only if they bear the associated cost to retrieve the set of price elements. If any of the two risk controls described below are triggered, this third party will be rewarded SWINGBY tokens for an amount larger than the data request’s associated cost.
- The system calculates a set of relative ratios for each asset pegged in a two-way fashion and select its maximum, such as:
If abs(1 — r) is greater than f (i.e., the threshold to accept the price imbalance), a peg alert is triggered. The proposed value f should be equal to the minimum fee to conduct a cross-chain swap between two bridged assets on Skybridge (e.g., WBTC → BTC or BTC → WBTC).
Once the system receives a peg alert, the following actions are taken:
- liquidity provision is suspended (i.e., minting of LP token is suspended);
- redemptions for liquidity providers can continue based on the new price logic to adjust for the deviation in the peg between the two assets being bridged;
- user swaps are suspended.
To learn more about these responses, don’t forget to read the full draft of SWIP-019.
- The system calculates a parameter k to determine the protocol’s current staking status.
Note that n is the number of assets included in the float (e.g., BTC, WBTC) AND the number of different oracle tokens held in the smart contract address.
- The l parameter is defined to determine limits on quantities that can be deposited in the protocol, such as:
m is the lower boundary risk ratio required for new assets to be added on both legs of Skybridge.
k represents the protocol’s current staking status, while l is used to determine the maximum liquidity provision for the protocol.
The exit of risk checks
To exit these risk status, the protocol needs to receive a set of prices that allow it to calculate new risk metrics that fit within their respective normal limits.
- For the peg alert, the system requires the price difference between the two bridged assets to be lower than the specified f threshold.
- For the over-staking protection, the protocol requires the system’s k parameter to return within appropriate limits (a multiplier of m).
Like the oracle logic discussed before, either validators or a third-party actor can retrieve (from the oracle provider) the set of prices necessary to assess the current risk status of the protocol. If the new risk status of the protocol properly changes, the network rewards the third party for a price higher than the cost of retrieving and posting the set of relevant prices from the oracle provider.
Skybridge is the first protocol offering non-custodial swaps to move assets between the Bitcoin blockchain and Ethereum building on new TSS technology. This innovation makes it possible to swap bitcoins directly onto Ethereum (and other EVM-compatible networks in the future).
Yet, as illustrated in this deep dive on SWIP-019, bi-lateral cross-chain swaps and liquidity provision activities are not immune to some potential attack vectors such as over-staking and the unpegging of two assets.
By integrating price oracles into a dedicated risk layer into Skybridge, SWIP-019 will solve these problems and continue to pave the way for future integration of TSS technology for cross-chain swaps with a wide variety of assets and networks.
Since one of our core goals is to bridge the gap between blockchains by offering non-custodial cross-chain swaps, the team will continue to explore ways of improving the risk management aspects of Skybridge.