# Getting Started with Symbiosis Welcome to the Symbiosis Documentation Center! Dive into comprehensive explanations of the principles that drive the Symbiosis protocol. Access user guides, developer tools, and much more. ## Introducing Symbiosis Symbiosis is a decentralized exchange that pools together liquidity from different blockchains, whether they use EVM technology or not. With Symbiosis, users can effortlessly trade any token and transfer their assets across blockchains. No need to worry about which network a token is on or how to move funds between different blockchains. All cross-chain operations are done in a single click (one transaction) at competitive exchange rates and transaction costs. The Symbiosis protocol is designed to provide a seamless cross-chain trading experience for users, while adhering to the following key principles:

Complete Decentralization

The Symbiosis protocol operates without a central authority, ensuring that no single party can halt its functionality or censor user access.

Interoperability

Symbiosis aims to connect every blockchain that attracts sufficient market interest, ultimately striving to create a unified bridge between all blockchains.

Non-Custodial

User funds remain secure, as no one – not even the Symbiosis team – has access to them.

Boundless Cross-Chain Liquidity

The Symbiosis protocol targets the full range of token pairs across supported blockchain networks, providing the best prices to exchange any arbitrary token pair.

## What is under the Hood Let's have a look at the parts of the Symbiosis protocol (Scheme 1).

Scheme 1. Main components of the Symbiosis protocol.

The Symbiosis protocol consists of two main parts:
On-Chain Part: Core ContractsSymbiosis Core Contracts implement the on-chain logic of cross-chain operations (cross-chain swaps, cross-chain zaps, interchain communication, bridging). The smart contracts are deployed and tuned by Symbiosis administrators while adding a blockchain to the Symbiosis protocol.Details →/pages/-MbqnJZPZg1c6rCKzu58
Off-Chain Part: Relayers NetworkThe Symbiosis Relayers Network is a peer-to-peer (P2P) network designed to enable fast, accurate, and secure transmission of information for cross-chain operations. As the off-chain component of the Symbiosis protocol, the network plays a crucial role in ensuring smooth and secure communication across blockchains.Details →/pages/-MbqnR8ol3fmRhDBEAIN
## Services Provided The Symbiosis protocol provides the following services:
Cross-chain SwapsThe Symbiosis protocol was born to enable cross-chain exchange. Any token to any token cross-chain exchange is possible across supported blockchain networks.Details →/pages/wPyxDg35Kg9JObjEMcn9
Interchain Communicating MessengerWith Symbiosis, users can supply liquidity to other DeFi protocols. Yes, it's cross-chain and done in one transaction.Details →/pages/zDw6lFBm31y6NZz5oOf4
Cross-chain ZapsCross-chain zapping facilitates liquidity supplying to Symbiosis Octopools. Liquidity providers can supply assets via cross-chain zapping in one transaction.Details →/pages/ok6mEMXhjxwsQXe3eLjW
FarmingSymbiosis offers several reward programs for users who provide liquidity to the Symbiosis protocol.Details →/pages/py6fYgMG0m8pjHMKu8Dc
Symbiosis ExplorerSymbiosis Explorer collects and stores data related to cross-chain operations performed via the Symbiosis protocol.Details →https://explorer.symbiosis.finance/transactions
veSISBy staking SIS tokens, users can receive rewards, reduce cross-chain fees, increase APR for providing liquidity, and most importantly, gain voting power to shape the Symbiosis DAO.Details →/pages/U0xqYEml0jNsiyp69MZB
## More Information
Why not give it a try?Take a tour around with Symbiosis WebApp.https://app.symbiosis.finance/
Questions?Check our Frequently Asked Questions or contact our support on Discord.https://discord.com/invite/ymbRx6ADvR
Looking for SDK or API?Refer to the documentation section dedicated to software engineers./pages/JNNWK3RXikL7rfRUd1ZA
# Symbiosis: Frequently Asked Questions Find answers to the most frequently asked questions about the Symbiosis protocol. ## Vision and Product ### Q: **Why should I care about Symbiosis?** **A:** Our vision is that users need a simple solution to move their liquidity across multiple chains; current solutions like bridges create liquidity fragmentation and are not trivial for end users. ### Q: **So then what is Symbiosis?** **A:** Our idea was that a multi-chain world needs an easy-to-use solution like Uniswap. So we created Symbiosis: it acts as a cross-chain AMM DEX and interchain communication protocol allowing users to swap their assets and move liquidity between chains with one click (in one transaction). ### Q: **Interesting, but how does it work?** **A:** Here is a simple explanation of how the Symbiosis protocol handles cross-chain swaps [Symbiosis: Cross-Chain Swaps](/main-concepts/symbiosis-cross-chain-swaps). ### Q: **What's new in Symbiosis protocol V2?** **A:** In a nutshell, * Symbiosis protocol V2 inherits the main concepts and the logic of cross-chain operations from V1. * The difference lies in the liquidity pools used to perform cross-chain operations via the Symbiosis protocol. Please refer to [Symbiosis v1 vs. v2](/miscellaneous/symbiosis-v1-vs.-v2) for more information. ## Relayers and Staking ### Q: **What is the Symbiosis Relayers Network?** **A:** The Symbiosis Relayers Network is a P2P network with built-in crypto-economic incentive mechanisms. The relayers network is an off-chain part of the Symbiosis protocol. The main purpose of the network is to provide fast, accurate, and secure transfer of information about cross-chain operations conducted via the Symbiosis protocol. Please refer to [Relayers network](/relayers-network/symbiosis-relayers-network) for more information. ### Q: **Do bridge operators (relayers) receive rewards for bridging blockchains?** **A:** Relayers receive rewards as a part of the relayers consensus distribution. For more information on the rewards, please refer to [Symbiosis Relayer Node](/relayers-network/symbiosis-relayer-node). If you ask who is paying gas fees for bridging, the answer is relayers pay for the gas, which is deducted from users swaps. For more information on how it works, please refer to [Symbiosis & Fees](/main-concepts/symbiosis-and-fees) ### Q: **What blockchains are supported?** **A:** Technically, the Symbiosis protocol can support the chains listed below: * L1/L2 EVM compatible blockchain (with the correct Solidity version). * WASM blockchain (Near). In practice, we will support blockchains that gain market traction and are appreciated by the users. Since there are legal risks in integrating new blockchains, we consult legal advisors before integrating any. For the up-to-date list of supported blockchains by the Symbiosis protocol, please refer to [Symbiosis sTokens and Supported Chains](/main-concepts/wrapped-tokens#supported-blockchains) ## Symbiosis DAO Govern the Symbiosis DAO and DAO Treasury. See [Governing Symbiosis](/sis-token/governing-symbiosis) for more information. ### Q: **Who can submit governance proposals on the DAO?** **A:** Users with a voting power of 2,000 veSIS or more can submit proposals. ### Q: **Does a SIS token holder have to stake SIS tokens to be able to vote on proposals?** **A:** Yes. In order to vote on the Symbiosis DAO, users should stake SIS tokens. By doing so, users get veSIS tokens that give voting power, rewards for participating in the Symbiosis DAO, and boost APRs for providing liquidity. ### Q: **Are there rewards in the form of additional SIS tokens provided for participation in governance functions?** **A:** Yes. Users who lock SIS tokens are rewarded for participating in the governance process. For more information, please refer to [veSIS](/reward-programs/vesis) ## Problem Solving ### Q: How do we solve the problem of uneven exchange direction between networks, resulting in a balance increase of an asset on one network and a decrease on the other? **A:** The simple solution to this problem is AMM pools**,** which are perfectly designed to handle this problem. At Symbiosis, we rely on proven solutions for Uniswap-like and Curve-like models that have been confirmed to be efficient over time. A liquidity pool between two networks is always deployed on one of these networks (usually, on the one with fewer transaction fees). The ratio of the number of assets in the pool to each other determines their prices. With an increase in one of the directions of exchange, the ratio of assets changes, and the price of each of them comes to a "non-market" state. At this point, arbitrageurs come into play. Arbitrageurs are an important element of the AMM protocols. They compete for the right to buy an asset from the pool at a discount price. 💡 There is an excellent description of this process in the documentation provided by [Paradigm](https://research.paradigm.xyz/amm-price-impact). There is one difference in the implementation of Symbiosis pools: one of the assets in a pool is [a wrapped representation of the source token](/main-concepts/wrapped-tokens). Thus, arbitrageurs should execute the bridging scenario (Token A <> sToken A) in addition to the usual scenario of buying an asset on the open market. It’s done to transfer source tokens from (or into) the Symbiosis protocol and manage them in the pools. The stablecoin pools have their peculiarities and can potentially work between multiple networks at the same time. ### Q: **How do you incentivize TVL for the stablecoin pools?** **A:** The main directions are: * Fees collected from all swaps going through that pool, * Farming incentivization. Please refer [Symbiosis Reward Programs](/reward-programs/symbiosis-reward-programs) for more information. ### Q: **The non-EVM chain swapping, how does it work?** **A:** There are two cases: * EVM-incompatible blockchains with smart contracts (e.g. Solana, Near): We will support them as long as they allow the EdDSA/ECDSA key generation. Integration complexity depends on the virtual machines and the smart contract languages they use. * Blockchains without smart contracts (e.g. Bitcoin): We definitely cannot run the AMM logic directly on them. However, if they support ECDSA and HTLC (hash time lock) contracts, we can bridge the native assets since the Symbiosis relayer network supports that. So as for UX, it will be similar to swapping ETH -> BTC, and slightly different for BTC -> ETH. # Symbiosis Roadmap The hero's journey ## Year 2024 See [Symbiosis 2024 Recap](https://symbiosis.finance/blog/symbiosis-2024-annual-recap-a-year-of-growth-and-breakthroughs) ## Year 2023 See [Symbiosis 2023 Recap](https://medium.com/@symbiosis_fi/symbiosis-2023-recap-94da3a1562d7) ## Year 2022 See [Symbiosis 2022 Recap](https://medium.com/symbiosis-fi/symbiosis-2022-recap-879d7676f8eb) The major achievements of 2022: * Q1: Launch of Symbiosis protocol V1 on Mainnet * Q4: Launch of Symbiosis protocol V2 on Mainnet See the differences between Symbiosis protocols V1 and V2: [Symbiosis V1 vs. V2](/miscellaneous/symbiosis-v1-vs.-v2) ## Year 2021 ### Q1 2021 * Cross-chain DEX MVP is complete * Testnet launch: ETH <-> BTC cross-chain swap * Symbiosis relayers network on top of ChainLink * Finalizing the Symbiosis protocol vision and strategy ### Q2 2021 * Cross-chain MVP: [Polygon, BSC, Ethereum](/main-concepts/wrapped-tokens#symbiosis-protocol-v1) * Smart-routing ([the concepts are used in Symbiosis protocols V1 and V2](/crosschain-liquidity-engine/symbiosis-routing-contracts)) * [SIS tokenomics ](/sis-token/symbiosis-sis-token#sis-tokenomics) ### Q3 2021 * Cross-chain DEX Testnet: [+ Avalanche, Heco, Okex](/main-concepts/wrapped-tokens#symbiosis-protocol-v1) * [Security audits](/main-concepts/security-audits) of core smart contracts * [Farming contracts](/reward-programs/symbiosis-reward-programs) * Mobile App SDK V1 (deprecated in Symbiosis protocol V2) ### Q4 2021 * Staking for Symbiosis relayers network * Mobile App SDK V2 (deprecated in Symbiosis protocol V2) * Last preparations before going to Mainnet ## Year 2020 ### Q3 2020 * Start of RnD ### Q4 2020 * RnD: Concepts of bridges, relayers, burn-mint process * Start of development of core smart-contracts # Symbiosis sTokens and Supported Chains The Symbiosis protocol leverages sTokens, a form of wrapped tokens, to enable cross-chain operations. Discover more about sUSDC, sUSDT, sWETH, and sWBTC in this comprehensive document. ## sToken Introduction The Symbiosis protocol employs sTokens, which stand for synthetic or synthesized tokens. These tokens facilitate cross-chain operations. Despite their resemblance to wrapped tokens, we purposefully refrain from labeling them as such. This distinction ensures they are set apart from the myriad of wrapped tokens prevalent in the DeFi sector.
What is wrapped token? If you would like to refresh your knowledge about wrapped tokens, here is some basic information. Wrapped tokens play several crucial roles in the DeFi ecosystem. Since different blockchains have different technical specifications, not all tokens can interact with all platforms. Wrapping tokens allows them to be used on platforms where they couldn't be used otherwise. A wrapped token in decentralized finance (DeFi) is a type of token that represents an asset hosted on the same or different blockchain. It's called "wrapped" because the original asset is put into a wrapper, or a different blockchain layer. The process of wrapping and unwrapping tokens is typically done through certain organizations or smart contracts, depending on the specific wrapped token. For example, one of the most popular wrapped tokens is Wrapped Bitcoin (WBTC). WBTC is a token on the Ethereum blockchain that represents Bitcoin. Each WBTC is backed 1:1 with a real Bitcoin. This allows Bitcoin to be used directly in Ethereum's ecosystem, enabling it to be utilized in Ethereum's DeFi applications, smart contracts, and DApps. In order to assure the token's credibility, the equivalent amount of the underlying asset is usually locked in a smart contract or held by a custodian, which can be audited to confirm that each wrapped token is fully backed.
## **Transit Tokens: Choice of Tokens for Synthesis** While Symbiosis has the capability to take any token from one blockchain and mint a synthetic counterpart on another, the protocol primarily engages with a select group: namely stablecoins, WETH (Wrapped ETH), and WBTC (Wrapped BTC). {% hint style="info" %} **Transit tokens:** WBTC, WETH and specific stablecoins can be seen as transit tokens in the Symbiosis protocol, since they are used to enable cross-chain operations within the protocol. {% endhint %} But why the focus on just stablecoins, WETH and WBTC? The core objective of Symbiosis is to enable token exchanges across various blockchains. To fulfill this, the protocol prioritizes tokens that maintain consistent value and enjoy wide usage across all supported blockchains. The tokens that meet these criteria are stablecoins, WETH, and WBTC. In cases where multiple stablecoins are present on a blockchain, the Symbiosis protocol typically leans towards one, often opting for USDC, or USDT, based on the specific blockchain. ## **sTokens Usage** ### Stablecoins Let's consider an example: we want to exchange USDC from Ethereum for BUSD on the BNB chain via the Symbiosis protocol. The simplified algorithm of the bridging stablecoins is shown in Scheme 1 below.

Scheme 1. Mint-burn routing during a cross-chain operation performed via the Symbiosis protocol.

Thus, when sending 1 USDC on Ethereum, we would expect to receive 1 BUSD on the BNB chain in an ideal world without transaction fees or varying exchange rates. However, in reality, the amount received will likely be slightly less than the amount sent. ### WETH If we exchange WETH from Ethereum for WETH on Arbitrum, the bridging procedure will be the same with one exception: Octopool with sWETH will be used (Scheme 2).

Scheme 2. Mint-burn routing during a cross-chain operation performed via the Symbiosis protocol.

Thus, when sending 1 WETH on Ethereum, we would expect to receive 1 WETH on Arbitrum in an ideal world without transaction fees or varying exchange rates. However, in reality, the amount received will likely be slightly less than the amount sent. ### WBTC If we exchange WBTC from Ethereum for syBTC on zkSync Era, the bridging procedure will be the same with one exception: Octopool with sBTC will be used (Scheme 3).

Scheme 2. Mint-burn routing during a cross-chain operation performed via the Symbiosis protocol.

Thus, when sending 1 WBTC on Ethereum, we would expect to receive 1 syBTC on zkSync Era in an ideal world without transaction fees or varying exchange rates. However, in reality, the amount received will likely be slightly less than the amount sent. **NB on Symbiosis Host Chain** The Symbiosis contracts with mint-burn logic and Symbiosis Octopools are located on the Symbiosis host chain. {% hint style="info" %} sTokens are used for technical purposes only, and end-users cannot trade sTokens, although they can receive sTokens when adding/removing liquidity to/from Symbiosis Octopool. Comprehensive information on Octopools can be found here: [Symbiosis Octopools](/crosschain-liquidity-engine/symbiosis-octopools). {% endhint %} ## Supported Blockchains The Symbiosis protocol supports the following blockchains: 1. Abstract 2. ApeChain 3. Arbitrum Nova 4. Arbitrum One 5. Avalanche 6. B² Network 7. Bahamut 8. Base 9. Berachain 10. Bitcoin 11. Blast 12. BNB 13. Boba Ethereum 14. CORE 15. Cronos 16. Cronos zkEVM 17. Ethereum 18. Fraxtal 19. Gnosis 20. Goat 21. Gravity 22. HyperEVM 23. Katana 24. KAVA EVM 25. Linea 26. Manta 27. Mantle 28. Merlin 29. Metis 30. Mode 31. Morph 32. opBNB 33. Optimism 34. Plasma 35. Polygon 36. Polygon zkEVM 37. Rootstock 38. Scroll 39. Sei v2 40. Solana 41. Soneium 42. Sonic 43. Symbiosis (Host Chain) 44. Taiko 45. Telos 46. TON 47. Tron 48. Unichain 49. ZetaChain 50. ZkLink 51. ZkSync Era The list may be slightly outdated. To access the most relevant information, simply call the [/v1/chains](https://api.symbiosis.finance/crosschain/docs/#/Chains/get_v1_chains) method.

Scheme 2. Blockchains supported by Symbiosis.

## More Information * There is an explanation of how sTokens get minted and burned: [Symbiosis Mint-Burn Process](/crosschain-liquidity-engine/synthesizing-process) # Symbiosis: Cross-Chain Swaps Discover the concepts of seamless and secure cross-chain swapping and bridging capabilities offered by the Symbiosis protocol. {% hint style="info" %} **Curious to see how it works?** Check it out with [Symbiosis WebApp](https://app.symbiosis.finance/swap?chainIn=Ethereum\&tokenIn=ETH) {% endhint %} The Symbiosis protocol was born for cross-chain operations. In the beginning it was cross-chain swaps and bridging, then more functionality was added to the protocol. This document explains the concepts of cross-chain swaps. For more information about sTokens and bridging concepts in the Symbiosis protocol, please refer to [Symbiosis sTokens and Supported Chains](/main-concepts/wrapped-tokens) Let’s consider an example: a user has MATIC tokens on the Polygon network and wants to exchange them for UNI on Ethereum, and wants to get the maximum possible amount of tokens and pay less on-chain and cross-chain fees.

Scheme 1. Cross-chain swap routing using stablecoins as transit tokens.

**Important notices for Scheme 1** * **Transit Token**\ In this example, USDC is used as the transit token for moving between networks, with the Octopool utilizing sStables on the host network. However, for cross-chain operations, other transit tokens such as WETH or WBTC may also be used. In such cases, the Symbiosis protocol will use either the Octopool with sWETH tokens or the Octopool with sWBTC tokens.\ \ When a user initiates an exchange, the Symbiosis protocol calculates various potential routes, using USDC, WETH, or WBTC as the transit token. The most efficient route is then presented to the user (Step 1). Comprehensive information on Octopools can be found here: [Symbiosis Octopools](/crosschain-liquidity-engine/symbiosis-octopools). * **Third party DEXs (Step 2.1. & Step 6.2.)** * When the token a user wants to exchange is different from the transit token, the user’s tokens will first be swapped into the transit token. DEX aggregators are used to find the best rates on the network where the swap occurs. In our example on Polygon, MATIC is exchanged for USDC. * Similarly, when the token a user wishes to receive is different from the transit token, the transit tokens will be swapped into the desired tokens on the destination network. DEX aggregators are again used to find the best rates on the destination network. In our example on Ethereum, USDC is exchanged for UNI. * **Host Chain**\ The Symbiosis Host Chain hosts Octopools, and all cross-chain operations pass through it. * **Step 6.2.** Once the last on-chain swap is accomplished, the user gets tokens to their address on the destination chain. * **Cross-chain fees**\ For more details on the fee calculating and withholding process, please refer to [Symbiosis & Fees](/main-concepts/symbiosis-and-fees) ## Guaranteed Transit Tokens Each cross-chain swap has a slippage tolerance limit that is set in Step 1. This value is distributed across all transactions of a cross-chain swap. This ensures that each individual transaction remains within its specified slippage tolerance fraction, guaranteeing that the cumulative price change doesn't exceed the overall slippage tolerance threshold. 1. If the transaction on the first (source) network surpasses the accepted price change, then assets stay in the wallet. 2. If the transaction on Symbiosis host chain surpasses the accepted price change, then the cross-chain swap gets halted. Please see [Symbiosis & Emergencies](/crosschain-liquidity-engine/symbiosis-and-emergencies) for more details. 3. If the transaction on the destination blockchain surpasses the accepted price change, then the user will receive an appropriate amount of the transit token: Step 9 will be omitted and transit tokens will be sent to the user's address. ## Depository and Solver Introduction {% hint style="info" %} **Note:** The Depository Contract is not yet deployed on all supported networks. All chains integrated with Symbiosis will eventually follow this updated execution flow. {% endhint %} To reduce the likelihood of sending transit tokens to users on the destination chain, Symbiosis introduces a Depository Contract and a Solver Service. The mechanism can be illustrated using the same example as above: swapping MATIC on Polygon for UNI on Ethereum.

Scheme 2. Cross-chain swap using Depository/Solver on the destination chain.

**Important notices for Scheme 2** **Step 6.1. & 6.2.** USDC is released and locked in the Depository contract. For each token lock, the Depository stores the following parameters: * Conditions under which the lock can be released * The destination token and minimum acceptable amount after the exchange * Destination addresses the tokens can be sent to (the user’s address) All this data is derived from the payload constructed in Step 1 and forwarded by Relayers from chain to chain. **Step 7.** * **Step 7.1.** The Solver continuously monitors lock events emitted by the Depository. * **Step 7.2.** When a lock event is detected, the Solver: * Finds an exchange route that satisfies the unlock conditions. * Sends a transaction calling the Depository to complete the swap. **Step 8.** If the release conditions are met, the following actions happen: * The locked USDC is released and exchanged through third-party liquidity sources (DEX aggregators are used). * One the on-chain swap is accomplished, the tokens are sent to the user's address on the destination chain. If the transaction fails, the USDC remains locked in the Depository, allowing the Solver to retry the operation. ### **Depository: Lock Release Conditions** * **Immediate Swap Completion:** The Depository releases the token lock without delay if the tokens are exchanged for an amount higher than the minimum required amount. * **Delayed Completion:** The Depository releases the lock with delay if the exchange results in an amount equal to the minimum acceptable amount. * **Transit Token**: If it becomes impossible to perform the exchange even at the minimum amount, then the transit token is sent to the user's address. **Example:** A USDC lock is created with a minimum acceptable output of 0.5 ETH on Ethereum. * If the Solver finds an exchange route that yields 0.501 ETH, the lock is released immediately. * If the Solver finds an exchange route that yields 0.5 ETH, the lock will be released with a delay. * If the Solver cannot find a route that produces even 0.5 ETH, even after a significant amount of time, the locked USDC tokens will be released and sent to the user's address on Ethereum. **Additional information:** [Slippage Tolerance Distribution in Cross-Chain Swaps](https://docs.symbiosis.finance/developer-tools/symbiosis-api/slippage-tolerance-distribution-in-cross-chain-swaps) ### What Is Solver The Solver service is an off-chain component that monitors new lock events and executes the steps required to complete a cross-chain swap. It computes the best available on-chain route that satisfies the defined conditions and performs the necessary transactions. The Solver can make multiple attempts to complete the swap, increasing the likelihood of successful execution. To ensure high availability and reliable performance across supported networks, Symbiosis maintains several Solver instances. The Solver is designed as a **permissionless service**: anyone can run a Solver instance and participate in executing cross-chain swaps. Over time, the ecosystem will expand to include multiple independent Solver operators, each capable of completing swaps and receiving fees for successful executions. ## More Information * For a more detailed explanation, please see [Symbiosis Routing Contracts](/crosschain-liquidity-engine/symbiosis-routing-contracts). * If you are curious to see how it works, try our web-based application: [Symbiosis WebApp](https://app.symbiosis.finance/swap). # Symbiosis as Interchain Communication Protocol Interchain communicating messaging with Symbiosis: Add any asset from one blockchain to a third-party protocol on a target chain using Symbiosis cross-chain zaps. {% hint style="info" %} **Curious to see how it works?** \ Check it with [Symbiosis WebApp > Cross-chain zaps](https://app.symbiosis.finance/zap?asset=ETH\&assetChain=Ethereum) **Looking for SDKs and API?** \ Check out our documentation for software developers: [Developer Tools](/developer-tools/symbiosis-developer-tools) {% endhint %} ## What is Interchain Communication The Symbiosis protocol facilitates interchain communication by allowing users to perform cross-contract calls. A cross-contract call is the ability to interact with third-party smart contracts on the target network after a cross-chain token exchange. The idea is that the tokens are not only exchanged but also immediately used within the desired protocol. **Implemented use cases:** * **Token Exchange for SOL and USDC (Solana) through the Chainflip bridge:** The Symbiosis protocol supports the exchange of any token from supported blockchains for SOL and USDC on Solana, utilising the Chainflip bridge to Solana. * **Token Exchange for BTC through the ThorChain BTC bridge:** The Symbiosis protocol supports the exchange of any token from supported blockchains for BTC on the Bitcoin network, utilising the ThorChain bridge. * **Token Exchange for BTC through the Chainflip BTC bridge:** The Symbiosis protocol supports the exchange of any token from supported blockchains for BTC on the Bitcoin network, utilising the Chainflip bridge. * **Token Exchange for TON through the TON bridge (depricated):** The Symbiosis protocol supports the exchange of any token from supported blockchains for TON on the TON network, utilising the TON native bridge. * **Cross-Chain Zap:** Users can directly supply assets in third-party protocols across different blockchains, streamlining the investment process. ## Exchange for SOL/USDC (Solana) though the Chainflip Bridge The Symbiosis protocol enables cross-chain token exchanges from any supported chain to **SOL** or **USDC** on Solana, utilizing the **Chainflip bridge** on Arbitrum One. Since the Chainflip protocol accepts **USDC** tokens on Arbitrum One, the Symbiosis protocol first swaps the user's assets into USDC on Arbitrum One, then deposits the USDC into Chainflip smart contracts, and facilitates the user receiving SOL or USDC on Solana. **Example Process** Consider a user holding **ETH** on the Ethereum network who wants to exchange it for **SOL** on the Solana network. The Symbiosis protocol swaps **ETH** from Ethereum to **USDC** on Arbitrum One. Once the USDC arrives, the protocol automatically deposits the tokens into Chainflip smart contracts on Arbitrum One to exchange for SOL through the Chainflip protocol. Once Chainflip receives the USDC, it sends SOL tokens on Solana to the address specified by the user in the initial step. This process is illustrated in Scheme 1.

Scheme 1. Exchanging for SOL on Solana thought Chainflip.

## Exchange for BTC though the ThorChain BTC Bridge The Symbiosis protocol facilitates cross-chain token exchanges from any supported chain to BTC on the Bitcoin network via the ThorChain BTC bridge, either on **Ethereum** or **Avalanche**. Since the ThorChain protocol only accepts **USDC** tokens, the Symbiosis protocol first swaps the user's assets into USDC on Ethereum or Avalanche, then deposits the USDC into ThorChain smart contracts for the user to receive BTC. Let’s consider an example: a user has MATIC tokens on the Polygon network and wants to exchange them for BTC on the Bitcoin network. The Symbiosis protocol swaps MATIC from Polygon for USDC on Ethereum or Avalanche. Once the USDC arrives, the protocol automatically deposits it into ThorChain smart contracts on Avalanche to exchange for BTC through the ThorChain protocol. Once ThorChain receives the USDC, it sends BTC to the Bitcoin address specified by the user in the initial step. This process is illustrated in Scheme 2.

Scheme 2. Exchanging for BTC thought ThorChain on Ethereum

**Important notices for Scheme 2** * **Ethereum or Avalanche?** When a user initiates an exchange on a supported chain, the Symbiosis protocol calculates two potential routes: one via Ethereum and the other via Avalanche. The most efficient route is then displayed to the user. * **What happens after the USDC is deposited to ThorChain?**\ Once ThorChain receives the USDC, it sends BTC to the Bitcoin address specified by the user in the initial step: Step 1. However, if for any reason ThorChain cannot accept the USDC, the USDC will be sent to the user’s address (the same as the sender's address) on either Ethereum or Avalanche. ## Exchange for BTC though the Chainflip BTC Bridge The Symbiosis protocol enables cross-chain token exchanges from any supported chain to BTC on the Bitcoin network via the Chainflip BTC bridge either on **Arbitrum**. The Chainflip protocol accepts **USDC** tokens, the Symbiosis protocol first swaps the user's assets into USDC on Arbitrum, then deposits the USDC into Chainflip smart contracts for the user to receive BTC. The workflow is similar to exchanging for BTC trough the ThorChain BTC bridge explained above. ## Exchange for TON though the TON Bridge (depricated) The Symbiosis protocol facilitates cross-chain token exchanges from any supported chain to TON on the TON network through the official TON bridges, either on **Ethereum** or **BNB Chain**. Since the TON bridges only accept WTON tokens, the Symbiosis protocol first swaps the user's assets into **WTON** on Ethereum or BNB Chain, then sends the WTON to the TON bridge contracts for the user to receive TON. Let’s consider an example: a user has MATIC tokens on the Polygon network and wants to exchange them for TON on the TON network. The Symbiosis protocol swaps MATIC from Polygon for WTON on Ethereum or BNB chain. Once the WTON arrives, the protocol automatically deposits it into TON bridge smart contracts on BNB chain to exchange for TON through the TON oficial bridge. Once the ton bridge receives the WTON, it sends TON to the TON address specified by the user in the initial step. This process is illustrated in Scheme 3.

Scheme 3. Exchanging for TON through the TON bridge on Ethereum

**Important notices for Scheme 3** * **Ethereum or BNB chain?** When a user initiates an exchange to TON, the Symbiosis protocol calculates two potential routes: one via Ethereum and the other via BNB Chain. The most efficient route is then presented to the user. * **USDC as the Transit Token in This Example**\ In this example, USDC is used as the transit token for moving between networks, and the Octopool with sStables is utilized on the host network. However, for exchanges to TON, other transit tokens such as WETH or WBTC may also be used. In such cases, the Symbiosis protocol will use either the Octopool with sWETH tokens or the Octopool with sWBTC tokens.
When a user initiates an exchange, the Symbiosis protocol calculates various potential routes, using USDC, WETH, or WBTC as the transit token. The most efficient route is then presented to the user (Step 1).\ \ Comprehensive information on Octopools can be found here: [Symbiosis Octopools](/crosschain-liquidity-engine/symbiosis-octopools) * **What happens after the WTON is deposited to the TON bridge?**\ Once the TON bridge receives the WTON, it sends TON to the TON address specified by the user in the initial step: Step 1. However, if for any reason the TON bridge cannot accept the WTON tokens, the WTON tokens will be sent to the user’s address (the same as the sender's address) on either Ethereum or BNB chain. ## Cross-chain Zap into Third-party Protocol Currently, cross-chain Zaps are supported for: * **Lending Protocols:** AAVE, * **Farming Protocols:** BEEFY, * **Liquid Staking Protocols:** LIDO {% hint style="info" %} **Transit tokens:** Tokens such as WETH, specific stablecoins, and WBTC serve as transit tokens within the Symbiosis protocol, facilitating cross-chain operations. Please refer to [Symbiosis sTokens and Supported Chains](/main-concepts/wrapped-tokens) for more details. {% endhint %} Let’s consider an example: a user has MATIC tokens on the Polygon network and wants to deposit USDC into AAVE on Avalanche (the same process applies when adding liquidity to other protocols). The Symbiosis protocol swaps MATIC from Polygon for USDC on Avalanche. Once the USDC arrives, the protocol automatically deposits it into AAVE smart contracts on Avalanche for lending. This process is illustrated in Scheme 4.

Scheme 4. Interchain communication routine with Symbiosis protocol V2.

**Important notices for Scheme 4** **Steps 2.** The Symbiosis protocol performs an on-chain swap on the user's behalf using a DEX aggregator. **Steps 4.2 and 7.2.** The Symbiosis protocol mints/releases tokens at a 1:1 ratio and withholds an amount equal to the transaction processing fee on the current blockchain. For more details on the fee withholding process, please refer to [Symbiosis & Fees](/main-concepts/symbiosis-and-fees) **Step 9.** Once the deposit operation is completed, the user receives LP tokens or other confirmation of the deposit into the protocol at their address on the destination chain. ## More Information * For a more detailed explanation, please see [Symbiosis Routing Contracts](/crosschain-liquidity-engine/symbiosis-routing-contracts). * If you are curious to see how it works, try our web-based application: [Symbiosis WebApp](https://app.symbiosis.finance/swap). # Symbiosis & Fees Who and how pays transaction fees for cross-chain operations conducted with the Symbiosis protocol. ## Who Pays Transaction Fees? The Symbiosis protocol implements the following on-chain and cross-chain operations: * On-chain swaps, * Cross-chain swaps, * Cross-chain zaps (adding liquidity to Symbiosis Octopools), * Interchain communicating, including: * Adding liquidity to third-party DeFi protocols via cross-chain Zaps, * Swaps to BTC trough ThorChain, * Swaps to Solana via Chainflip) * Bridging, * Reverting stuck cross-chain operations. Each cross-chain operation consists of multiple steps executed across the source blockchain, S-chain, and destination blockchain(s). For example, a cross-chain swap (see *Scheme 1*) follows a structured sequence of transactions across these networks.

Scheme 1. A cross-chain swap as an example of a cross-chain operation.

#### **Gas Fees and Cross-Chain Fees** For the user, a cross-chain operation appears as a single transaction (*Step 1 in Scheme 1*). The user signs and submits this transaction on the source blockchain (where their assets are held) and covers the gas fee for this transaction. In reality, a cross-chain operation consists of multiple transactions. The Symbiosis protocol executes additional transactions required to complete the swap (*Step 5 and Step 9 in Scheme 1*) and covers the gas fees for processing these transactions. Now, let’s examine how the user refunds the gas fees and pays cross-chain fees to Symbiosis. ## Withholding the Cost of Gas Let’s examine how gas costs are withheld using a cross-chain swap as an example. The same logic applies to other cross-chain operations. If the Symbiosis Host Chain is the source or destination blockchain, the cross-chain operation requires one less calldata and one fewer transaction. {% hint style="info" %} **Additional fees** If you want to collect additional fees beyond Symbiosis' standard logic, you must deploy and manage your own collector smart contracts. To accurately estimate gas fees and generate calldata, we recommend using the Symbiosis API. For detailed guidance, refer to our [Symbiosis Developer Tools](/developer-tools/symbiosis-developer-tools) {% endhint %} Next, we will extend *Scheme 1* by incorporating the gas withholding process on the S-chain and destination blockchain (*Scheme 2*).

Scheme 2. Withholding the cost of gas.

**Workflow of Withholding Gas Costs (*****Scheme 2*****)** #### **Step 1: Initial Transaction and Calldatas** The initial transaction contains **three calldatas**, defining the execution steps on different blockchains: * **Calldata0** – Instructions for the **source blockchain**. * **Calldata1** – Instructions for the **S-chain**, including the estimated gas fee in a stablecoin equivalent (**GasEstimatedUSD1**). * **Calldata2** – Instructions for the **destination blockchain**, including the estimated gas fee in a stablecoin equivalent (**GasEstimatedUSD2**). Additionally, the calldatas include execution constraints, such as slippage tolerance and deadline for the cross-chain operation These details are **finalized at the time of transaction signing** and cannot be modified afterward. By signing the initial transaction, the **user agrees** to all intermediate steps, restrictions, and fees. #### **Steps 2–4: Execution on the Source Blockchain** The Symbiosis protocol processes the instructions from **Calldata0** (*Step 1*). Once completed, it generates an Oracle request **—** a message for listeners **—** containing **Calldata1** and **Calldata2** for the next steps. #### **Step 5: Oracle Processing** The Symbiosis Relayer Network listens for Oracle requests from Symbiosis contracts. Once an Oracle request appears, the network: * Extracts **Calldata1** and **Calldata2** and perform validation checks, ensuring **GasEstimatedUSD1** is sufficient to cover gas costs on the S-chain. * If the checks pass, relayer nodes sign a transaction containing **Calldata1** and **Calldata2** using their **MPC key** and send it to the next blockchain (the blockchain is specified in the Oracle request). * Pays the gas fees required to execute this transaction. An amount equal to **GasEstimatedUSD1** is deducted from the transferred tokens at the next step. #### **Step 6-8: Execution on S-chain** The Symbiosis protocol processes instructions from **Calldata1:** * Tokens are minted on the **S-chain**. * An amount equal to **GasEstimatedUSD1** is deducted from the minted token amount and kept. * The remaining tokens continue through the cross-chain swap process. Once completed, it generates an Oracle request **—** a message for listeners **—** containing **Calldata2** for the next step. #### **Step 9: Oracle Processing** The Symbiosis Relayer Network listens for Oracle requests from Symbiosis contracts. Once an Oracle request appears, the network: * Extracts **Calldata2** and perform validation checks, ensuring **GasEstimatedUSD2** is sufficient to cover gas costs on the S-chain. * If the checks pass, relayer nodes sign a transaction containing **Calldata2** using their **MPC key** and send it to the next blockchain (the blockchain is specified in the Oracle request; in this example, it's Avalanche). * Pays the gas fees required to execute this transaction. An amount equal to **GasEstimatedUSD2** is deducted from the transferred tokens at the next step. #### **Step 10-11: Execution on the destination chain** The Symbiosis protocol processes instructions from **Calldata2:** * Tokens are released on the destination chain. * An amount equal to **GasEstimatedUSD2** is deducted from the released token amount and kept. * The remaining tokens continue through the cross-chain swap process. Once completed, tokens are sent to the user's address on the destination chain. it generates an Oracle request **—** a message for listeners **—** containing **Calldata2** for the next step. {% hint style="info" %} **Important Notes** The initial execution parameters (e.g., GasEstimatedUSD1, GasEstimatedUSD2, slippage, deadlines) are set in Step 1 and remain unchanged throughout the cross-chain operation. {% endhint %} ## Advisor The Symbiosis Relayers Network uses the **Advisor** microservice to fetch gas prices on the blockchains supported by Symbiosis, ensuring transactions will be executed successfully. **Advisor Microservice Functions:** 1. **Validates cross-chain operation limits** – Ensures the transaction amount complies with the limits imposed by the Symbiosis protocol. 2. **Estimates gas costs** – Estimates the gas cost (in the USD equivalent) to execute the given calldata 3. **Verifies gas sufficiency** – Checks whether the estimated gas fee is sufficient for executing the calldata (used by the Symbiosis Relayers Network). For **Points 2 and 3**, Advisor simulates calldata execution on the given blockchain by calling an appropriate method. If the calldata cannot be executed, then: * **Gas cost cannot be estimated.** * **The gas sufficiency check fails** (indicating that the transaction cannot be processed).

Scheme 3. Advisor

# Security Audits A collection of security audits done for the Symbiosis protocol. Each part of the Symbiosis protocol has been audited by a company that specializes in the technology specific to that part: * Symbiosis WebApp, * Symbiosis Core Smart Contracts, * Contracts of the Symbiosis BTC bridge, * Contracts of the Symbiosis TON bridge, * Symbiosis Octopool, * Relayers. The full collection of security audits can be found here: # Symbiosis SIS Token Overview of the SIS token, its utility, governance role, staking, use cases, and supported networks ## Overview SIS is the governance and utility token of the Symbiosis protocol. SIS is used for protocol governance, staking-related mechanisms, protocol incentives, and as the gas token on Symbiosis Chain. Users can also get, move, and swap SIS on supported networks where routes are available. This page gives a high-level overview of SIS utility, supported networks, and market data. #### Related Guides **For practical token operations**, see [SIS Token Guide](/sis-token/sis-token-guide). It covers contract addresses, wallet setup, getting SIS, moving SIS between chains, and swapping SIS for other tokens. **For governance-related benefits**, see [veSIS](/reward-programs/vesis). **For staking options and mechanics**, see [Symbiosis PoS Staking User Guide](/relayers-network/symbiosis-pos-staking-and-symbiotic-staking/symbiosis-pos-staking-user-guide). ## SIS and Supported Networks SIS was originally deployed on Ethereum and has since been partially bridged to a number of other networks. SIS is available as a token on Ethereum, BNB Chain, Arbitrum One, zkSync Era, Linea, and Scroll. On the Symbiosis chain, SIS is the native gas token. For current contract addresses, adding SIS to your wallet, and moving SIS between networks, see [SIS Token Guide](/sis-token/sis-token-guide) ## SIS Market Data SIS market data, price charts, and token information are available on external market data platforms: * [CoinMarketCap](https://coinmarketcap.com/currencies/symbiosis-finance/) * [CoinGecko](https://www.coingecko.com/en/coins/symbiosis) These platforms provide market data such as price, chart history, market capitalization, and trading information. # SIS Token Guide Supported SIS token networks, contract addresses, and bridging options ## Overview SIS is the governance and utility token of the Symbiosis protocol. It is used for governance, relayer staking, protocol incentives, and as the gas token on the Symbiosis chain. SIS holders can trade, transfer, or stake their tokens where supported. This guide explains where SIS is available and lists the addresses of the relevant token contracts. It also explains how to transfer SIS between supported networks and swap it for other tokens. ## Supported Chains and Addresses {% hint style="warning" %} Always check the network before adding, sending, or bridging SIS. SIS contract addresses are different on each network. Using the wrong network or contract address may result in loss of funds. Copy addresses only from this page or from the linked block explorer. {% endhint %} SIS was originally deployed on Ethereum and later bridged to other networks. SIS is currently available on the following networks:
NetworkContract addressExplorer
Ethereum0xd38BB40815d2B0c2d2c866e0c72c5728ffC76dd9Etherscan
BNB chain0xF98b660AdF2ed7d9d9D9dAACC2fb0CAce4F21835BscScan
Arbitrum One0x9e758b8a98a42d612b3d38b66a22074dc03d7370Arbiscan
zkSync Era0xdd9f72afED3631a6C85b5369D84875e6c42f1827zkSync Era Explorer
Linea0x6EF95B6f3b0F39508e3E04054Be96D5eE39eDE0dLineaScan
Scroll0x1467b62A6AE5CdcB10A6a8173cfe187DD2C5a136ScrollScan
Symbiosis chainNative gas token. No token contract address is required for gas usage.—
## Add SIS to Your Wallet If SIS is not shown in your wallet, add it as a custom token. When adding SIS manually, make sure the selected wallet network matches the SIS contract address you use. Use the SIS contract address for the selected network. Most wallets also ask for the token symbol and decimals. If these fields are not filled automatically, check the linked block explorer for the correct token details. For Symbiosis chain, SIS is the native gas token, so it may be displayed as the network’s native asset rather than as a custom token. ## Get SIS You can use [Symbiosis WebApp](https://app.symbiosis.finance/swap) to swap tokens for SIS: 1. In the **From** field, select the source chain and the token you have. In the **To** field, select the destination chain and the SIS token. 2. Enter token amount. 3. Check swap details:\ ![](/files/JyAwaPIDLKXOcIziufJg) 4. Connect your wallet and confirm the swap. ## Move SIS Across Supported Chains (SIS <> SIS) The most convenient way to move SIS tokens between supported networks is to use [Symbiosis WebApp](https://app.symbiosis.finance/swap) 1. In the **From** field, select the source chain and SIS. In the **To** field, select the destination chain and SIS. 2. Enter token amount:\ ![](/files/3x8BR3LIt09QVHXkNoPL) 3. Connect your wallet and confirm the swap. **Important:** If you are moving a large amount of SIS tokens and the Symbiosis WebApp shows unfavourable rates for your swap, use the official bridges to move your SIS tokens. **Example:** If you move SIS tokens from Arbitrum One to BNB chain using official bridges, then: 1. Bridge SIS tokens from Arbitrum One to Ethereum using [Arbitrum Official Bridge](https://bridge.arbitrum.io/) 2. Bridge SIS tokens from Ethereum to BNB chain using [Symbiosis Bridge](https://app.symbiosis.finance/bridge?chainIn=Ethereum\&chainOut=BNB\&tokenIn=0xd38BB40815d2B0c2d2c866e0c72c5728ffC76dd9\&tokenOut=0xF98b660AdF2ed7d9d9D9dAACC2fb0CAce4F21835) #### Bridge options | Route | Bridge | | -------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Ethereum `<>` BNB chain | [Symbiosis Bridge](https://app.symbiosis.finance/bridge?chainIn=Ethereum\&chainOut=BNB\&tokenIn=0xd38BB40815d2B0c2d2c866e0c72c5728ffC76dd9\&tokenOut=0xF98b660AdF2ed7d9d9D9dAACC2fb0CAce4F21835) | | Ethereum `<>` Arbitrum One | [Arbitrum Official Bridge](https://bridge.arbitrum.io/) | | Ethereum `<>` zkSync Era | [zkSync Era Official Bridge](https://portal.zksync.io/bridge/) | | Ethereum `<>` Linea | [Linea Official Bridge](https://bridge.linea.build/) | | Ethereum `<>` Scroll | [Scroll Official Bridge](https://scroll.io/bridge) | ## Swap SIS for Another Token (SIS <> Any) You can use [Symbiosis WebApp](https://app.symbiosis.finance/swap) to swap SIS for tokens on any supported chain: 1. In the **From** field, select the source chain and SIS. In the **To** field, select the destination chain and the token you want to receive. 2. Enter token amount. 3. Check swap details:\ ![](/files/zvtNfcXxRgogtVch2U23) 4. Connect your wallet and confirm the swap. ## Buy SIS on DEXs and CEXs SIS can be bought and sold on decentralized and centralized exchanges. See the up-to-date list of available DEXs and CEXs: ## Support {% hint style="warning" %} Never share your seed phrase, private keys, or wallet recovery information with anyone. {% endhint %} If you have any questions, please contact [our support team on Discord](). # Governing Symbiosis The ultimate Guide: how to participate in the Symbiosis DAO and unlock the full potential of decentralized governance. ## Symbiosis DAO A Decentralized Autonomous Organization (DAO) is an entity structure with no central authority that decentralizes decision-making among the members of the DAO. The Symbiosis DAO has its token: SIS token, which can be used in two ways: * Token holders can trade, exchange, or stake it. * Token holders can vote to influence the way the Symbiosis protocol is developing. Thus, users who have SIS tokens and vote on Symbiosis initiatives are members of the Symbiosis DAO. ## Getting Vote Power Users should lock their SIS tokens into a voting escrow to participate in governance. By staking SIS tokens, users get veSIS tokens that give voting power, rewards for participating in the Symbiosis DAO, and boosted APRs for providing liquidity. One veSIS token equals one vote. The longer SIS tokens are locked, the more rewards and voting power holders have: 1 SIS locked for 4 years = 1.00 veSIS\ 1 SIS locked for 3 years = 0.75 veSIS\ 1 SIS locked for 2 years = 0.50 veSIS\ 1 SIS locked for 1 years = 0.25 veSIS {% hint style="success" %} For a complete guide on how to get veSIS and rewards, please refer to [veSIS](/reward-programs/vesis) {% endhint %} ## Voting Proposals on the Symbiosis protocol get published on [the Snapshot dashboard](https://snapshot.org/#/symbiosisdao.eth). One veSIS token equates to one vote, and decisions with the most votes are adopted. To cast your vote on an active proposal: 1. Visit [the Symbiosis proposal dashboard](https://snapshot.org/#/symbiosisdao.eth). 2. Connect your wallet (you won't pay for any transaction; you just prove that you have voting power by your signature). 3. Open an active proposal, select your vote opinion, and add a comment (optional):\ ![](/files/QHTNVzPPSR04quHicFAC) 4. Confirm your vote with your signature via the wallet. You do not pay for any transaction; you just prove that you have voting power by your signature:\ ![](/files/Klx2OiFE7XJU3LjNz6h4) 5. Done:\ ![](/files/OvEz1uEmsdFGQEFZLmr2) You can change your vote while the proposal is active. Done \ \&#xNAN;**∎** # Symbiosis WebApp Use the Symbiosis WebApp to swap tokens across supported blockchain networks ## Overview The **Symbiosis WebApp** is the official web-based application for using the main user-facing features of the Symbiosis Protocol. The WebApp brings the main swap actions into one screen. From the swap page, you can select networks and tokens, connect wallets, adjust swap settings, switch between light and dark themes, and check swap history for connected wallets. {% hint style="success" %} Symbiosis WebApp is available at {% endhint %}
You can also use the top navigation to access other Symbiosis features, including Earn, staking, pools, explorer, and resources. ## Wallets and Supported Networks You can check swap rates without connecting a wallet. Wallets are only needed when you are ready to perform a swap. The Symbiosis WebApp allows users to connect the most popular wallets for different supported network types:
This covers most regular swap routes. Bitcoin routes work differently because Bitcoin does not use the same wallet connection flow as EVM, Tron, Solana, TON, and other supported networks. Because of this, swaps to or from Bitcoin uses a separate flow. Check here for more information: [Swap Bitcoin](/user-guide-webapp/swap-bitcoin) ## Swap History The WebApp shows swap history for connected addresses:
You can use swap history to review previous swaps, check operation status, and return to swaps that are still being processed. **Hint:** you can also use the **Symbiosis Explorer** at [https://explorer.symbiosis.finance](https://explorer.symbiosis.finance/) to track cross-chain operations. ## Symbiosis WebApp and Partner Apps Symbiosis WebApp is the official app built by Symbiosis. Some partner applications also use Symbiosis Protocol in the background. This means users can make swaps through partner apps as well, while the swap itself is still executed through Symbiosis infrastructure. The difference is the interface: * Symbiosis WebApp is the official Symbiosis swap interface * Partner apps provide their own user interface * Both can use Symbiosis Protocol for cross-chain swaps ## Non-custodial Use Symbiosis is non-custodial. Users keep control of their wallets and confirm all wallet actions themselves. Swaps are executed by protocol smart contracts according to the route selected and the transactions signed by the user. ## Swap Guides The Symbiosis WebApp is designed to be easy to use, and the guides below can help you better understand the swap process and manage swaps with more confidence. * **General swap guide:** [Swap Tokens](/user-guide-webapp/swaps)\ This guide explains what to check before starting a swap, how to set up a favorite token list, how to manage liquidity sources, and how to track or troubleshoot a swap if needed. * **Tron swap guide:** [Tron: Swap with Low Fees](/user-guide-webapp/swaps-to-and-from-tron)\ This guide explains how Tron fees work and how to reduce or avoid TRX burning when swapping from Tron. * **BTC swap guide:** [Swap Bitcoin](/user-guide-webapp/swap-bitcoin)\ This guide explains the swap flow for swaps from and to BTC. # Swap Tokens General walkthrough: How to swap tokens across supported blockchains using the Symbiosis WebApp This guide explains the standard swap flow in the Symbiosis WebApp. It covers what to check before starting a swap, how to track swaps, and how to manage favorite tokens and liquidity sources. Some swap routes have additional details. For these cases, see the dedicated guides: * **Tron swap guide:** [Tron: Swap with Low Fees](/user-guide-webapp/swaps-to-and-from-tron) \ Learn how Tron fees work and how to reduce or avoid TRX burning when swapping from Tron. * **BTC swap guide:** [Swap Bitcoin](/user-guide-webapp/swap-bitcoin)\ Learn how swaps from and to BTC work and what is different from regular wallet-connected swapsю ## Steps to Perform a Cross-Chain Swap Symbiosis WebApp is available at {% hint style="success" %} **Before you start:**\ Make sure you have enough **native tokens (gas)** on the **source network** to pay transaction fees. {% endhint %} 1. Select your **From** and **To** tokens and chains. 2. Enter the amount of tokens you want to swap (From). 3. Review swap details: **Do not skip this step**\ \ Symbiosis automatically finds the best route for your selected token pair and amount.\ Always review the output before confirming the swap.\ \ **Key values to check:** 1. The estimated amount to receive (1) 2. USD values (2) 3. Minimum received (4) Swap details complete explanation: {% columns %} {% column width="50%" %}
{% endcolumn %} {% column width="50%" %} **(1)** **To amount**: Estimated amount to be received on the destination network. The final amount may vary slightly due to slippage, but it will not be lower than the Minimum received amount **(4)**. **(2)** **USD values**: Approximate USD value of the selected amounts. Useful for comparison. **(3.1)**** Receive to another wallet:** The recipient address can be either taken from the connected wallet or entered manually. If an address is entered, it must be confirmed in **(3.2)** **(4)**** Minimum received:** The minimum guaranteed amount you will receive after the swap, based on current rates and settings. **(5)**** Other swap details:** * **Price**: Current conversion rate for your swap, influenced by trade size. * **Slippage Tolerance:** Percentage of the trade value you’re willing to accept as a price change. It can be adjusted via the settings icon. * **Estimated time:** Expected time to complete the cross-chain swap, based on historical data. * **Price impact:** How much this swap affects the market price. * **Discount:** veSIS holders are eligible for discounts on protocol fees for certain chains. * **Fee**: Total estimated fee for the swap. This excludes the transaction fee on the source chain. {% endcolumn %} {% endcolumns %} 4. **Connect wallet & switch network**\ Connect your wallet and switch to the required **source network** when prompted. 5. **Approve token (if needed)** 1. **Native tokens** (ETH, BNB, etc.) do **not** require approval. 2. **Non-native tokens** (USDC, USDT, etc.) require **Approve**. Approval gives Symbiosis permission to use the selected token for the swap. 6. **Confirm the swap**\ Click **Swap** and confirm the transaction in your wallet. 7. **Wait for completion**\ Cross-chain swaps usually take 1–3 minutes. Swaps involving the Bitcoin network may take longer. 8. **Track your swap**\ You can track the status and history of your swaps using [Symbiosis Explorer](https://explorer.symbiosis.finance/transactions). ## Basic and Pro Mode The Symbiosis WebApp has **Basic** and **Pro** swap modes**:**
**Basic mode** shows a simplified swap flow. It is suitable for standard swaps when you want the app to select the route automatically. By default, Basic mode uses the route with the **best return**. If route search takes longer and several routes are not available yet, Basic mode may use the first available route received by the app. **Pro mode** shows available routes for the selected tokens and chains. This mode is useful when you want to compare routes and choose one manually. Pro mode may take slightly longer to load because the app waits to show more available route options. {% hint style="info" %} A **route** is the sequence of operations used to exchange the selected source token for the selected destination token. {% endhint %} ## Private Mode The Symbiosis WebApp has **Private** swap mode**:**
**Private Swap** is a swap mode for routes that may use privacy-oriented assets, centralized providers, or semi-centralized providers. Unlike standard Symbiosis swaps, private swaps may not be fully traceable through the regular Symbiosis Explorer flow. Source and destination transactions may still be visible on their respective block explorers, but the full internal route may not be publicly traceable in the same way as a standard route. **This provides an additional layer of route privacy, but it does not make the swap fully anonymous.** In Private Swap mode, the app shows private routes separately from standard routes. A private route may include a **Private** step between the source and destination networks. A **Private** step means that the route is not executed through standard Symbiosis bridge and swap operations. Private swaps may take longer to complete than regular swaps. If the transfer is rejected during execution, the tokens will be returned to the sender’s address. ## Swap Routing and Liquidity Sources Symbiosis supports both cross-chain and on-chain swaps. Depending on the route, a swap may use Symbiosis infrastructure together with external liquidity sources, such as DEXs, pools, aggregators, or partner protocols. In the Symbiosis WebApp, users can manage available liquidity sources in settings:
**Important:** Disabling a source may remove some available routes or reduce the number of routing options for certain swaps. Here is an example:\ ![](/files/sVsjvOkrQKSgp8OHSbIi) ## Favorite Token List With the Symbiosis WebApp, you can create and manage your own custom token list. This feature is useful if you frequently swap a few specific tokens and want quick access to them instead of searching through the full token list each time. **Add a Token to the Favorite Token List** 1. Open the network and token sector (the **From** or **To** field) in the Symbiosis WebApp 2. Locate the token you want to add to your favorites, click the `...` button next to the token and select **Add to favorites**:\ ![](/files/A1PQ7MFEjX170XfVhH0D) **Choose a Token from the Favorite Token List:** 1. Open the network and token sector (the From or To fields) in the Symbiosis WebApp. 2. Open your **favorites list** (click the **star icon**) and select the token you want to use:\ ![](/files/NRLk3qJL5J2UuZiPK4lV) ## Tracking and Troubleshooting Swaps This document explains swap tracking and solutions to common issues: [Where Are My Tokens? → Troubleshooting Guide](/user-guide-webapp/where-are-my-tokens-troubleshooting-guide) ## Getting Support {% hint style="warning" %} Never share your seed phrase, private keys, or wallet recovery information with anyone. {% endhint %} If you have any questions or encounter any issue, please contact [our support team on Discord](). The following information will help us resolve the matter faster: * The transaction hash or a link to the transaction in the appropriate block explorer or in the [Symbiosis Explorer](https://explorer.symbiosis.finance/transactions). * The sender's wallet address. * Relative screenshots. For common questions and solutions, check out our [FAQ and Troubleshooting Guide](https://docs.symbiosis.finance/user-guide-webapp/where-are-my-tokens) # Swap Bitcoin BTC walkthrough: How to swap BTC across supported blockchains using the Symbiosis WebApp This guide shows how to swap BTC using Symbiosis. * For Tron-related swaps, see [Tron: Swap with Low Fees](/user-guide-webapp/swaps-to-and-from-tron) * For a deeper dive into the mechanics of BTC exchanges with Symbiosis, refer to this article [Symbiosis: To/From BTC](/main-concepts/symbiosis-cross-chain-swaps/symbiosis-to-from-btc) ## **Requirements** To exchange BTC for a token, ensure the following: * **BTC Availability**: BTC must be available on an address you control on the Bitcoin network. * **BTC Wallet**: Use a wallet that supports network operations, such as Electrum or Trust Wallet. * **Destination Address and Refund Addresses**: Use addresses that **you control**. ## **BTC Swap** #### **Connon Flow:** 1. **Specify Swap Details:** Open the Symbiosis WebApp and specify the swap details: a BTC amount, destination blockchain and token, destination and rufund addresses. 2. **Review the Quote and send BTC:** After receiving the quote, review the swap details. If the terms are acceptable, use your chosen Bitcoin wallet to send the specified BTC amount to the address provided in the quote. 3. **Receive Tokens:** Once the cross-chain operation is processed, the tokens will be sent to the specified address on the destination chain. Note that this process may take longer than typical cross-chain swaps between other blockchain networks. #### Guide 1. Navigate to [Symbiosis WebApp](https://app.symbiosis.finance/swap?amountIn\&chainIn=Ethereum\&chainOut=Bitcoin\&tokenIn=ETH\&tokenOut=0xc102C66D4a1e1865Ee962084626Cf4c27D5BFc74). 2. Specify swap details and review quated details: {% columns %} {% column %}
{% endcolumn %} {% column %} **(1)** Select BTC and enter the BTC amount to swap **(2)** Select the destination chain and token (e.g., USDT on Tron) **(3)** Specify the destination address: * Connect a wallet, select the desired address in the wallet, and it will be automatically used as the destination address. * Enter the address manually **(4)** Enter the **BTC refund address**: if something goes wrong on the initial stage, your BTC tokens will be automatically returned to the address **(5)** Enter **EVM refund address**: BTC swaps are routed through EVM chains. If the destination network is non-EVM, this address will be used for refunds if the swap cannot be completed during the EVM stage.\ By default, the address is taken from the connected EVM wallet. **(6 & 7)**** Review the swap details**\ Please note that if the specified BTC amount is sent, the exact amount you receive will fall between the estimated amount shown in the **To** field and the minimum received amount displayed in the swap details: * **(2)**** The estimated amount** is based on the exchange rates across the entire sequence of intermediary swaps needed to obtain the destination tokens. * **(6)**** The minimum received amount** is calculated from the estimated amount, taking into account the slippage tolerance set for this cross-chain operation. Both the estimated and minimum received amounts include all fees associated with the cross-chain exchange. If the terms are acceptable. When ready, press the **Continue** button {% endcolumn %} {% endcolumns %} 3. When you press the **Continue** button a unique BTC address that is specific for this swap is generated. Read and follow the instructions provided in the Symbiosis WebApp on the next step:\ ![](/files/n0Y04brgRBks9TXhrJiq)\ When you send the specified BTC amount to this address, it will initiate the cross-chain swap.\ \ **Important:** \ The BTC address is unique for each cross-chain swap. Please don't reuse the address.\ If the amount sent is incorrect, the time limit has expired, or BTC tokens are sent repeatedly to the same address, the swap will be stopped. Please refer to the [#problems-and-solutions](#problems-and-solutions "mention") section below for information on how to handle a problem if it occurs. 4. **Send the specified BTC amount to the specified BTC address.** For each swap a unique BTC address is generated. Sending the specified BTC amount to the provided BTC address triggers the cross-chain swap for the specified tokens. 5. **Receive tokens.** Once the cross-chain operation is processed, the tokens is sent to the specified address on the destination chain. Note that process may take longer than typical cross-chain swaps between other blockchain networks. #### Swap Tracking There are two ways to track your exchange: 1. **Keep Symbiosis WebApp Open:** Symbiosis WebApp will continue displaying the swap progress. 2. **Use** [Symbiosis Explorer](https://explorer.symbiosis.finance/transactions): You can also track your exchange by entering your transaction details into Symbiosis Explorer. ## Basic and Pro Mode The Symbiosis WebApp has **Basic** and **Pro** swap modes**:**
**Basic mode** shows a simplified swap flow. It is suitable for standard swaps when you want the app to select the route automatically. By default, Basic mode uses the route with the **best return**. If route search takes longer and several routes are not available yet, Basic mode may use the first available route received by the app. **Pro mode** shows available routes for the selected tokens and chains. This mode is useful when you want to compare routes and choose one manually. Pro mode may take slightly longer to load because the app waits to show more available route options. {% hint style="info" %} A **route** is the sequence of operations used to exchange the selected source token for the selected destination token. {% endhint %} ## Private Mode The **Private** swap mode is not available for swaps from and to the Bitcoin network**:**
**Private Swap** is a swap mode for routes that may use privacy-oriented assets, centralized providers, or semi-centralized providers. ## Problems and Solutions 1. **BTC deposited but Nothing Received** * **Issue:** You sent BTC to the specified address on the BTC blockchain but haven't received anything on the destination network. * **Why it happens:** * You sent a different BTC amount than required * A technical issue occurred (e.g., rates on an intermediate DEX changed). * **Solution:** To complete the exchange or to retrieve your BTC, please contact support: [#support](#support "mention"). 2. **Received WBTC or USDC Instead of the Specified Token** * **Issue:** You received **WBTC or USDC/USDT** instead of your originally selected token. * **Why it happens:** When exchanging tokens across blockchains, transactions aren't processed instantly. If the exchange rate on the destination network changes during processing, and the new conditions don't meet the original terms, you may receive WBTC or USDC/USDT instead of the token you selected. Symbiosis uses WBTC & USDC/USDT as transit tokens to process cross-chain operations. * **Solution**: WBTC/USDC/USDT can be exchanged for any other token on the supported networks. 3. **Received syBTC** * **Issue:** You received syBTC * **Why it happens:** * Rates changed on an intermediate DEX, preventing the swap from completing as expected. * You received syBTC after reverting a stuck swap. * **Solution:** You can swap syBTC for any supported token or unwrap it back to BTC. ## Support {% hint style="warning" %} Never share your seed phrase, private keys, or wallet recovery information with anyone. {% endhint %} If you have any questions, please contact [our support team on Discord](). # Tron: Swap with Low Fees How to swap assets on Tron with reduced transaction fees using the Symbiosis WebApp. is guide, we focus on points that are specific to **Tron** and on cross-chain swaps from the network. For instructions for other swap directions, please refer to [Swap Tokens](/user-guide-webapp/swaps) This guide starts with two common points that often confuse Tron users: 1. Transaction fees on Tron may be higher than expected, but they can often be reduced or avoided 2. Swaps involving tokens such as USDT usually require two transactions: approval first, then the swap itself ## Tron Transaction Fees ### How Fees Work on Tron On **Tron**, transaction fees work differently from Ethereum and many other networks. Instead of using a standard gas model, Tron relies on network resources: * **Bandwidth** for simple transfers. * **Energy**, together with some **Bandwidth**, for smart contract calls such as swaps, deposits, and other DeFi actions If the address does not have enough resources, **the network uses TRX** from the account balance to cover the transaction cost. **Bandwidth & Energy Origin** * Each address that holds TRX or tokens receives a small daily Bandwidth allowance. Empty accounts without any assets do not receive free Bandwidth. * Additional Bandwidth and Energy can be obtained by **staking TRX**. Staked TRX are locked for a minimum of **3 days** before they can be unstaked. * Additional Energy can also be rented. ### Why Transactions May Cost More Than Expected Simple transfers on Tron are often free or very cheap. However, transactions that interact with smart contracts, including swaps, deposits, lending, and other DeFi actions, may consume a significant amount of Energy. **If the account does not have enough staked or rented resources, TRX is spent from the account balance instead.** {% columns %} {% column width="58.333333333333336%" %} **Example** On the right, you can see an example of fee estimation for a swap from USDT on Tron to USDC on Ethereum. **In this example:** * The address has no staked or rented Energy * The smart contract does not provide sponsored Energy * As a result, **100% of the required Energy is covered by spending TRX** **Important:** these high fees can often be avoided. If you see that your TRX would be used mainly to pay Tron transaction fees, press **Reject** and continue to the next section of this guide. {% endcolumn %} {% column width="41.666666666666664%" %}
{% endcolumn %} {% endcolumns %} ### How to Avoid Spending TRX There are two main ways to reduce or fully avoid spending TRX on Tron transactions. **Rent Energy via JustLend** [JustLend DAO](https://app.justlend.org/energyRental?utm_source=chatgpt.com) is the first official lending platform on Tron that also provides an Energy rental service. Through its Energy Rental service, Energy can be rented for a fixed period at a lower cost than paying TRX directly. This is especially useful for occasional DeFi interactions. **Stake TRX to receive Energy and Bandwidth** By staking TRX, an account receives a daily allocation of Bandwidth and Energy. Staked TRX are locked for at least **3 days**. TRX can be staked either via [TronScan > Governance > TRX Staking](https://tronscan.org/#/sr/wallet-stake-home) or the TronLink wallet:
## Why Two Transactions May Be Needed If you are swapping a token such as USDT, two separate transactions may be required: 1. Token amount approval usually it's called token approval 2. The swap transaction itself
This is normal. Before a smart contract can use your token balance for a swap, you must first authorize it to spend the required token amount on your behalf. This authorization is called token approval. As a safety precaution, it is generally recommended to approve only the token amount needed for the current swap, rather than your full token balance. **Important** * Approval is a standard part of token swaps on many networks, including Tron * It is not the swap itself * After the approval is confirmed, you still need to initiate and confirm the actual swap transaction * If the required token amount was approved earlier, this step may be skipped ## Connecting Wallet To a connect your wallet that supports Tron at the [Symbiosis WebApp](https://app.symbiosis.finance/swap?amountIn\&chainIn=Tron\&tokenIn=0xa614f803b6fd780986a42c78ec9c7f77e6ded13c): click **Connect Wallet** and select your wallet from the list of the supported wallets:
If your preferred wallet is not listed, you can use **WalletConnect**. WalletConnect is a protocol that allows a secure connection between a wallet and a Web3 application. A common example is connecting a wallet installed on your smartphone to a web application opened on a desktop device. The connecting wallet must support both: Tron and WalletConnect v2. **Known issue** Some Tron-compatible wallets may not connect correctly if the Tron account was imported using a private key. If the same account is imported using a seed phrase instead, the wallet usually connects without issues. ## Cross-Chain Swaps from Tron Symbiosis WebApp is available at {% hint style="success" %} **Before you start:**\ You have enough **Energy** and **Bandwidth** to pay for sending transactions on Tron. {% endhint %} 1. Select your **From** and **To** tokens and chains. 2. Enter the amount of tokens you want to swap (From). 3. Review swap details: **Do not skip this step**\ \ Symbiosis automatically finds the best route for your selected token pair and amount.\ Always review the output before confirming the swap.\ \ **Key values to check:** 1. The estimated amount to receive **(1)** 2. Minimum received **(3)** Swap details complete explanation: {% columns %} {% column width="50%" %}
{% endcolumn %} {% column width="50%" %} **(1)** **To amount**: Estimated amount to be received on the destination network. The final amount may vary slightly due to slippage, but it will not be lower than the Minimum received amount. **(2)**** Receive to another wallet:** The recipient address is taken from the connected wallet. You can specify a different address here. **(3)**** Minimum received:** The minimum guaranteed amount you will receive after the swap, based on current rates and settings. **(4)**** Swap details** * **Price**: Current conversion rate for your swap, influenced by trade size. * **Slippage Tolerance:** Percentage of the trade value you’re willing to accept as a price change. It can be adjusted via the settings icon. * **Estimated time:** Expected time to complete the cross-chain swap, based on historical data. * **Price impact:** How much this swap affects the market price. * **Fee**: Total estimated cross-chain fee for the swap. This excludes the transaction fee on the source chain. {% endcolumn %} {% endcolumns %} 4. **Approve token (if needed)** 1. **Native tokens** (TRX on Tron) do **not** require approval. 2. **Non-native tokens** (USDT, etc.) require **Approve**. Approval gives Symbiosis permission to use the selected token for the swap. 5. **Confirm the swap**\ Click **Swap,** check **transaction fee estimation** in your wallet, confirm the transaction in your wallet if you agree to pay these fees. 6. **Wait for completion**\ Cross-chain swaps usually take 1–3 minutes. Swaps to the Bitcoin network may take longer. 7. **Track your swap**\ You can track the status and history of your **cross-chain swaps** using [Symbiosis Explorer](https://explorer.symbiosis.finance/transactions) or your transaction history available in the Symbiosis WebApp\ In case of **on-chain swaps**, please use ## Basic and Pro Mode The Symbiosis WebApp has **Basic** and **Pro** swap modes**:**
**Basic mode** shows a simplified swap flow. It is suitable for standard swaps when you want the app to select the route automatically. By default, Basic mode uses the route with the **best return**. If route search takes longer and several routes are not available yet, Basic mode may use the first available route received by the app. **Pro mode** shows available routes for the selected tokens and chains. This mode is useful when you want to compare routes and choose one manually. Pro mode may take slightly longer to load because the app waits to show more available route options. {% hint style="info" %} A **route** is the sequence of operations used to exchange the selected source token for the selected destination token. {% endhint %} ## Private Mode The Symbiosis WebApp has **Private** swap mode**:**
**Private Swap** is a swap mode for routes that may use privacy-oriented assets, centralized providers, or semi-centralized providers. Unlike standard Symbiosis swaps, private swaps may not be fully traceable through the regular Symbiosis Explorer flow. Source and destination transactions may still be visible on their respective block explorers, but the full internal route may not be publicly traceable in the same way as a standard route. **This provides an additional layer of route privacy, but it does not make the swap fully anonymous.** In Private Swap mode, the app shows private routes separately from standard routes. A private route may include a **Private** step between the source and destination networks. A **Private** step means that the route is not executed through standard Symbiosis bridge and swap operations. Private swaps may take longer to complete than regular swaps. If the transfer is rejected during execution, the tokens will be returned to the sender’s address. ## Tracking and Troubleshooting Swaps This document explains swap tracking and solutions to common issues: [Where Are My Tokens? → Troubleshooting Guide](/user-guide-webapp/where-are-my-tokens-troubleshooting-guide) ## Getting Support {% hint style="warning" %} Never share your seed phrase, private keys, or wallet recovery information with anyone. {% endhint %} If you have any questions, please contact [our support team on Discord](). # Bridge sUSDC, sWETH, sWBTC How to bridge synthetic assets (sUSDC, sWETH, sWBTC) using the Symbiosis WebApp. ## sTokens Overview **sTokens** (sUSDC, sUSDC.e, sWETH, sWBTC) are minted on the **Symbiosis chain** (the Symbiosis Host Chain) and are used within the Symbiosis protocol to enable cross‑chain operations. Users cannot trade sTokens directly, but they may receive them when adding or removing liquidity in **Symbiosis Octopools**. If you have sTokens and don’t want to simply hold them, you have two options: 1. **Provide liquidity:**\ Add your sTokens (sUSDC, sWETH, sWBTC, etc.) to a Symbiosis liquidity pool and earn rewards.\ See [Farming on Octopools](/reward-programs/farming-on-octopools) for details. 2. **Bridge back to native tokens:**\ sUSDC, sWETH, sWBTC, etc. can be bridged 1:1 to USDC, WETH, WBTC, and other supported tokens (see instructions below). ## **About gas on the Symbiosis chain** The Symbiosis chain uses **SIS** as its native gas token (bridged from Ethereum). SIS can be obtained in two ways: 1. Via the official L2 bridge at 2. Via [Symbiosis WebApp](https://app.symbiosis.finance/swap?chainIn=Symbiosis\&chainOut=Symbiosis\&tokenIn=SIS\&tokenOut=SIS) ## Bridging sUSDC, sWETH, sWBTC, etc. sUSDC, sWETH, sWBTC, etc. can be bridged 1:1 back to their native tokens (USDC, WETH, WBTC, etc.) on a corresponding networks. 1. Go to the **Mint and Burn** section in Symbiosis WebApp: \ \ **Important:** \ The **Mint and Burn** section is different from the **Swap** section:\ ![](/files/Zg9cMnXtPDbNjJBGM3Pe)
2. Connect your wallet. 3. In the **From** field, choose the sToken to bridge (e.g., sWETH on the Symbiosis chain):\ ![](/files/hrsswqpPUYtL4aXIriZv)
4. In the **To** field, select the destination token (only one option is available for each sToken type, e.g., sWETH → WETH on Arbitrum One).\ ![](/files/COO19g2IFLnnYQ34NcdO)
5. Enter the amount to bridge:\ ![](/files/y2WFqQ6C610r18ExpH93)
6. Switch to the Symbiosis chain: click the **Switch network to Symbiosis button**. 7. Press **Burn**, then confirm the transaction in your wallet. 8. Wait for confirmation: the tokens are bridged to the destination network. {% hint style="info" %} You can always check status of your cross-chain operations in [Symbiosis Explorer](https://explorer.symbiosis.finance/transactions). {% endhint %} Done \ \&#xNAN;**∎** ## Support {% hint style="warning" %} Never share your seed phrase, private keys, or wallet recovery information with anyone. {% endhint %} If you have any questions, please contact [our support team on Discord](). # Where Are My Tokens? → Troubleshooting Guide Troubleshooting guide for locating tokens after a swap via Symbiosis: tracking, partial fills, mismatches, and synthetic assets (sTokens). In this document, you’ll find solutions to common issues, explanations of key aspects, and helpful tips for locating your tokens: 1. [#where-and-how-to-track-swaps](#where-and-how-to-track-swaps "mention") 2. [#h\_9326ae80ce](#h_9326ae80ce "mention") 3. [#received-less-tokens-than-expected](#received-less-tokens-than-expected "mention") 4. [#received-a-different-token-than-expected](#received-a-different-token-than-expected "mention") 5. [#received-stokens-susdc-sweth-etc.-how-to-bridge-them](#received-stokens-susdc-sweth-etc.-how-to-bridge-them "mention") 6. [#received-sybtc-how-to-bridge-it](#received-sybtc-how-to-bridge-it "mention") ## Where and How to Track Swaps ### On-Chain Swap If your swap occurs **within the same blockchain** (for example: ETH → USDC on Ethereum), you can track it directly using the blockchain explorer for that network. Examples: * **Ethereum** → Etherscan * **BNB Chain** → BscScan * **Polygon** → Polygonscan Copy the **transaction hash** or **your wallet address** from your wallet and paste the **transaction hash** into the explorer search bar to view the transaction details. ### Cross-Chain Swap If your swap involves **multiple blockchains** (for example Ethereum → Tron), you can track it in two ways: 1. **Transaction history (WebApp)** 1. Open the [Symbiosis WebApp](https://app.symbiosis.finance/swap) 2. Connect your wallet and open the transaction history:
2. **Symbiosis Explorer** 1. Open the [Symbiosis Explorer](https://explorer.symbiosis.finance/) in your browser. 2. Copy one of the following: transaction hash or your wallet address 3. Paste it into the search bar.
**Swap Statuses:**
StatusMeaning
PendingThe swap is still being processed
SuccessThe swap has been completed
RevertedThe swap could not be completed and the tokens were returned
## Pending Swap: What Does It Mean The **Pending** status on a cross-chain swap means that the swap is still be processed. In most cases, the swap will complete once the required conditions are met. If the swap cannot be completed, the operation will eventually be reverted and the tokens will be returned automatically. ## Received Less Tokens Than Expected All swap details are displayed in the **Symbiosis WebApp** before you confirm the transaction in your wallet. Once the transaction is signed, it cannot be modified. In most cases, the amount of tokens you receive will be between the estimated amount and the minimum received amount shown in the Symbiosis WebApp. If you believe the amount you received differs from the quote shown before the swap, please contact our support team on **Discord** (contacts are listed at the end of this document). **What to Consider Before Performing a Swap:** 1. **Slippage Tolerance** * The number of tokens shown as **To receive** includes all liquidity provider fees and cross-chain fees. * **Important:** The final amount received may differ slightly but will remain within the range defined by your slippage tolerance. * **Example:** If 1,000 tokens are shown as **To receive** and your slippage tolerance is set to 2%, the actual amount received could range between **980 and 1,000 tokens**. * For more information, see [More about Slippage Tolerance](/user-guide-webapp/more-about-slippage-tolerance) 2. **Cross-Chain Fees** * When swapping to a blockchain network with high transaction fees (e.g., Ethereum or Tron), cross-chain fees can significantly impact the number of tokens you receive — **especially for small swap amounts**. * **Example:** Let’s consider a cross-chain swap from BNB Chain to Ethereum. The difference in fees is noticeable:\ ![](/files/NZx8468pI8y3CZprkmXS) 3. **Swap size** * The size of your swap can greatly affect the number of tokens received due to liquidity constraints and fees. * **Tip:** Always keep an eye on the **price impact** and the **token amounts to send and receive**, especially in their USD equivalents, to ensure the swap remains profitable:\ ![](/files/g6lTbGN8YdwVDV5yLAoD) For more information on how cross-chain fees are calculated and deducted, please refer to [Symbiosis & Fees](/main-concepts/symbiosis-and-fees) ## Received a Different Token Than Expected In rare cases, you may receive stablecoins (USDC, USDT), WETH, or WBTC on the destination network, even if you selected a different token as the destination token. {% hint style="info" %} If you don't have gas tokens to complete the swap on the destination chain, please contact our support on Discord (contacts are at the end of this document). They will assist you. {% endhint %} **Why Does This Happen?** Cross-chain swaps involve swapping assets between different blockchains, and these operations are not instantaneous. If the exchange rate on the destination network changes during the processing time and the new conditions no longer meet the stated ones, the Symbiosis protocol will deliver a stablecoin, WETH, or WBTC instead of the originally selected token. **Why stablecoins, WETH, or WBTC tokens?** Stablecoins, WETH and WBTC tokens have the same face value across different networks, making them ideal transit tokens for routing cross-chain operations within the Symbiosis protocol. ## Received sTokens (sUSDC, sWETH, etc.): How to Bridge Them The Symbiosis protocol uses **sTokens (e.g., sUSDC, sUSDC.e, sWETH, sWBTC)** to perform cross-chain operations. While end-users cannot trade sTokens, they may receive them when adding or removing liquidity from Symbiosis Octopools. **What Can By Done with sTokens?** 1. **Provide Liquidity and Earn Rewards**\ You can add your sTokens (sUSDC, sUSDC.e, sWETH, sWBTC) to a Symbiosis liquidity pool and earn rewards for providing liquidity. For more information, see the [Farming on Octopools](/reward-programs/farming-on-octopools) guide. 2. **Bridge sTokens to Their Equivalent Assets**\ You can bridge sTokens (sUSDC, sUSDC.e, sWETH, sWBTC) 1:1 for their equivalent assets (USDC, USDC.e, WETH, WBTC) via [the dedicated section of the Symbiosis WebApp](https://app.symbiosis.finance/bridge).\ For a detailed step-by-step guide, please refer to this guideline: [Bridge sUSDC, sWETH, sWBTC](/user-guide-webapp/dealing-with-stokens) ## Received syBTC: How to Bridge It syBTC is a wrapped BTC on several EVM chains. In rare cases these tokens can be sent to the user's address whan a cross-chain swap cannot be completed:\ ![](/files/iHPmjRtBq7NezpAvtHTw) **What Can Be Done with syBTC?** Via the [Symbiosis WebApp](https://app.symbiosis.finance/swap) you can: 1. **Unwrap** the syBTC back to the Bitcoin network 2. **Swap** the syBTC to any token ## I NEED MORE HELP! {% hint style="warning" %} Never share your seed phrase, private keys, or wallet recovery information with anyone. {% endhint %} If the above information did not help resolve your issue or you have some questions, please contact [our support team on Discord](). To ensure faster assistance, please include the following details: * **Type of operation:** Bridging, exchange, liquidity withdrawal, etc. * **Tokens and chains involved.** * **Transaction hash** or a link to the transaction in the appropriate block explorer. * **Wallet address.** * A brief explanation of the issue or what went wrong. # Provide Liquidity to Symbiosis Octopools This guide explains how to provide liquidity to Symbiosis Octopools, how address for LP tokens work, and how to withdraw liquidity from pools. ## Symbiosis Octopools Overview Symbiosis uses **Octopools** for cross-chain operations. Each cross-chain transaction goes through an Octopool located on the **Symbiosis chain**, also referred to as the **Symbiosis Host Chain**. An Octopool is a multi-token pool. There are three main Octopools: * With stable coins (USDC, USDT, etc.) bridged from supported chain, * With wETH tokens bridged from supported chain, * With wBTC bridged from supported chains The easiest way to view supported tokens and chains is through the [**Pools**](https://app.symbiosis.finance/liquidity-v2/pools) section in the Symbiosis WebApp:
* **Token:** the token available for liquidity provision. * **Chain:** the chain from which the token can be supplied. * **Total Locked:** total tokens locked in the pool. * **Pool Balance:** current balance ratio for this token in the pool. It affects deposits, withdrawals, and route availability. * **APR:** annual percentage rate for liquidity provision. ## How Liquidity Is Added Symbiosis Octopools are located on the **Symbiosis chain**. Because of this, when liquidity is supplied from another blockchain, the token first needs to be moved to the Symbiosis chain and then added to the pool. In the standard WebApp flow, this is done in one deposit operation: 1. The source token is locked in a dedicated contract on the source network. 2. The bridged token is minted on the Symbiosis chain. 3. The token is added to the Octopool. 4. LP tokens are issued on the Symbiosis chain. Advanced users can also do this manually in two steps: bridge the token to the Symbiosis chain first, then add it to the pool. ## Address for LP tokens When liquidity is added, LP tokens are issued. These tokens are required to withdraw your assets, so make sure they are sent to an address you control. If you add liquidity from an **EVM EOA wallet**, LP tokens are sent by default to the same EVM-compatible address on the Symbiosis chain. If you add liquidity from a **non-EVM network**, such as Solana or TON, provide an **EVM-compatible address** on the Symbiosis chain to receive LP tokens. If you use a **multisig contract** or another smart contract wallet, make sure to set a valid LP token receiver address on the Symbiosis chain. Contract addresses may differ between the source network and the Symbiosis chain. To set a custom LP token receiver address, enable the receiver address switch in the WebApp and enter an address you control.
## Depositing Liquidity To deposit liquidity to a Symbiosis Octopool: 1. Go to [Symbiosis WebApp > the *Pools* tab](https://app.symbiosis.finance/liquidity-v2/pools). 2. Connect your wallet. 3. Find the token and chain you want to supply liquidity for, then press **Manage** (for example, WETH on Arbitrum One):\ ![](/files/gMdNQ112U52VksJJCSV9)
4. Enter the amount to deposit:\ ![](/files/Al4LB98rsvHadNBThAdm)\ \ **Important:**\ If a **multisig contract** is used to sign transactions, provide a valid address on the Symbiosis chain for receiving LP tokens. Multisig contract addresses often differ between the source blockchain (where liquidity is sent from) and the destination blockchain (the Symbiosis chain).\ \ To set a custom LP token address, enable the switch in the WebApp and enter a valid address you control:\ ![](/files/htqm1HXs4c4JX352diQS)
5. If prompted, press *Switch network to \* and confirm in your wallet. 6. If prompted, press *Approve \* button and confirm in your wallet. 7. Review the details, then press *Add liquidity* and confirm in your wallet. 8. Wait for confirmation — liquidity is added to the pool. 9. To check, go to [Symbiosis WebApp > the *Pools* tab > My Liquidity](https://app.symbiosis.finance/liquidity-v2) to view your deposits:\ ![](/files/vOSNI5X0k2hBsREDWBT2) Done \ \&#xNAN;**∎** ## Withdrawing Liquidity Symbiosis Octopools are hosted on the **Symbiosis chain**. Liquidity can be withdrawn only on this chain. **About gas on the Symbiosis chain:** The network uses **SIS** as its native gas token (bridged from Ethereum). SIS can be obtained in two ways: 1. Via the official L2 bridge at 2. Via [Symbiosis WebApp](https://app.symbiosis.finance/swap?chainIn=Symbiosis\&chainOut=Symbiosis\&tokenIn=SIS\&tokenOut=SIS) ### Withdrawal Process Liquidity withdrawal has two steps: 1. **Remove liquidity** from the pool. 2. **Bridge sTokens** (e.g., sUSDC, sWETH, sWBTC) into the corresponding native assets (USDC, WETH, WBTC, etc.). Do not miss the instructions below: [#bridging-susdc-sweth-swbtc-etc](#bridging-susdc-sweth-swbtc-etc "mention") ### Removing Liquidity To withdraw liquidity from Symbiosis Octopool: 1. Go to [Symbiosis WebApp > the *Pools* tab > My Liquidity](https://app.symbiosis.finance/liquidity-v2):\ ![](/files/cpeBRW8gP4wEHyapOkD9)
2. Press *Manage* for the asset you want to withdraw. 3. Press *Remove*:\ ![](/files/8SUUMrM72fpgJjeUybnU)
4. Select the amount to withdraw (e.g. 75%):\ ![](/files/0RgKg3guXklYlkSq5UDS)
5. If prompted, press *Switch network to \* and confirm in your wallet. 6. Press *Remove* and confirm in your wallet. 7. Wait for confirmation — liquidity is removed from the pool. **Note:**\ When liquidity is withdrawn, you receive **sTokens** (e.g., sUSDC, sWETH, sWBTC) on the **Symbiosis** chain.\ These can be bridged 1:1 to their native tokens (USDC, WETH, WBTC, etc.).\ See instructions below for bridging. Done \ \&#xNAN;**∎** ### Bridging sUSDC, sWETH, sWBTC, etc. When liquidity is withdrawn from Octopools, you receive **sTokens** (sUSDC, sWETH, sWBTC, etc.) on the **Symbiosis chain**. These sTokens can be bridged 1:1 back to their native tokens (USDC, WETH, WBTC, etc.) on your target network. To bridge sTokens: 1. Go to the **Bridge** section in Symbiosis WebApp: \ \ **Important:** \ The **Bridge** section is different from the **Swap (Exchange)** section \ ![](/files/SVsbgyeis0rUWtQgM04H)
2. Connect your wallet. 3. In *Transfer From*, select the **Symbiosis chain** and choose the sToken to bridge (e.g., sWETH).\ ![](/files/vy0H3mAyCrWfgw0jQIh5)
4. In *Transfer To*, select the destination token (only one option is available for each sToken type, e.g., sWETH → WETH on Arbitrum One).\ ![](/files/CP5s40uCFfcuU8SHZJ0p)
5. Enter the amount to bridge:\ ![](/files/BU74O2kibx35O7ubulbX)
6. Press *Burn*, then confirm the transaction in your wallet. 7. Wait for confirmation — the tekens are bridged to the destination network. {% hint style="info" %} You can always check status of your cross-chain operations in [Symbiosis Explorer](https://explorer.symbiosis.finance/transactions). {% endhint %} Done \ \&#xNAN;**∎** ## Support {% hint style="warning" %} Never share your seed phrase, private keys, or wallet recovery information with anyone. {% endhint %} If you have any questions, please contact our [support team on Discord](). # Octopool: Withdraw Liquidity Symbiosis: How to withdraw liquidity from Octopool and redeem assets. ## Symbiosis Octopools Overview Symbiosis uses **Octopools** for all cross-chain operations. Every cross-chain transaction goes through an Octopool located on the **Symbiosis chain**, also referred to as the **Symbiosis Host Chain**. Although liquidity can be provided from any supported chain in one operation, withdrawals must be performed only on the Symbiosis Host Chain. **About gas on the Symbiosis chain:** The network uses **SIS** as its native gas token (bridged from Ethereum). SIS can be obtained in two ways: 1. Via the official L2 bridge at 2. Via [Symbiosis WebApp](https://app.symbiosis.finance/swap?chainIn=Symbiosis\&chainOut=Symbiosis\&tokenIn=SIS\&tokenOut=SIS) ## Withdrawal Process Liquidity withdrawal has two steps: 1. **Remove liquidity** from the pool. 2. **Bridge sTokens** (e.g., sUSDC, sWETH, sWBTC) into the corresponding native assets (USDC, WETH, WBTC, etc.). Do not miss the instructions below: [#bridging-susdc-sweth-swbtc-etc](#bridging-susdc-sweth-swbtc-etc "mention") ## Removing Liquidity To withdraw liquidity from Symbiosis Octopool: 1. Go to [Symbiosis WebApp > the *Pools* tab > My Liquidity](https://app.symbiosis.finance/liquidity-v2):\ ![](/files/cpeBRW8gP4wEHyapOkD9)
2. Press *Manage* for the asset you want to withdraw. 3. Press *Remove*:\ ![](/files/8SUUMrM72fpgJjeUybnU)
4. Select the amount to withdraw (e.g. 75%):\ ![](/files/0RgKg3guXklYlkSq5UDS)
5. If prompted, press *Switch network to \* and confirm in your wallet. 6. Press *Remove* and confirm in your wallet. 7. Wait for confirmation — liquidity is removed from the pool. **Note:**\ When liquidity is withdrawn, you receive **sTokens** (e.g., sUSDC, sWETH, sWBTC) on the **Symbiosis** chain.\ These can be bridged 1:1 to their native tokens (USDC, WETH, WBTC, etc.).\ See instructions below for bridging. Done \ \&#xNAN;**∎** ## Bridging sUSDC, sWETH, sWBTC, etc. When liquidity is withdrawn from Octopools, you receive **sTokens** (sUSDC, sWETH, sWBTC, etc.) on the **Symbiosis chain**. These sTokens can be bridged 1:1 back to their native tokens (USDC, WETH, WBTC, etc.) on your target network. To bridge sTokens: 1. Go to the **Bridge** section in Symbiosis WebApp: \ \ **Important:** \ The **Bridge** section is different from the **Swap (Exchange)** section \ ![](/files/SVsbgyeis0rUWtQgM04H)
2. Connect your wallet. 3. In *Transfer From*, select the **Symbiosis chain** and choose the sToken to bridge (e.g., sWETH).\ ![](/files/vy0H3mAyCrWfgw0jQIh5)
4. In *Transfer To*, select the destination token (only one option is available for each sToken type, e.g., sWETH → WETH on Arbitrum One).\ ![](/files/CP5s40uCFfcuU8SHZJ0p)
5. Enter the amount to bridge:\ ![](/files/BU74O2kibx35O7ubulbX)
6. Press *Burn*, then confirm the transaction in your wallet. 7. Wait for confirmation — the tekens are bridged to the destination network. {% hint style="info" %} You can always check status of your cross-chain operations in [Symbiosis Explorer](https://explorer.symbiosis.finance/transactions). {% endhint %} Done \ \&#xNAN;**∎** ## Support {% hint style="warning" %} Never share your seed phrase, private keys, or wallet recovery information with anyone. {% endhint %} If you have any questions, please contact our [support team on Discord](). # Symbiosis Explorer How to track swaps, and transaction data in the Symbiosis Explorer. ## Explorer Overview Symbiosis Explorer collects and stores data related to cross-chain operations performed via the Symbiosis protocol. It allows users to search for real-time and historical information about cross-chain operations by hash or address. {% hint style="info" %} Symbiosis Explorer is available at [https://explorer.symbiosis.finance](https://explorer.symbiosis.finance/transactions) {% endhint %}

Scheme 1. Symbiosis Explorer (general view).

Explorer sorts cross-chain operations in chronological order, with the most recent on top. Transaction amounts are displayed in USD, ETH or BTC equivalent, depending on the swap currency. ## Search To check the status of your cross-chain operation, copy and paste the transaction hash or your address into the search bar at the top. For instance:

Scheme 2. Searching by address.

You can get full information about the cross-chain operation by clicking *View*:\ ![](/files/WiA0VKrUT40Kxdz2WhT3) ## TXs States Possible states are: **In progress**, **Success**, **Success\***, **Interrupted**, and **Reverted**.
StatusMeaning
In progressThe swap is still being processed.
SuccessThe swap was completed.
Success*The swap was completed, and transit tokens (USDC, USDT, wETH, wBTC, or SyBTC) were delivered on the destination chain instead of the expected destination token.
InterruptedThe swap was interrupted during routing. The tokens were sent to the provided fallback address.
RevertedThe swap could not be completed and the tokens were returned on the source chain.
# More about Slippage Tolerance What slippage tolerance is, how it affects swaps, and how to configure it. This article explains the importance of slippage tolerance and what happens when an on-chain or cross-chain swap cannot be completed because the slippage tolerance limit has been exceeded. ## Importance of Slippage Tolerance Let's begin with an example. Suppose you want to swap 101 USDT for USDC on Ethereum, which is an on-chain swap. The Symbiosis WebApp identifies the best route for this swap and displays certain values:\ ![](/files/JdOS6rIFI4IMWfB1CIyZ) The 'to receive' token amount you see already accounts for the liquidity provider fees and other operational fees. But will you actually receive this exact amount? The real amount of tokens you receive might vary slightly from the displayed number, but it will always stay within the boundaries set by the slippage tolerance. Slippage tolerance represents the maximum price fluctuation you're willing to accept for your trade to go through. To illustrate, if you see '100 tokens' as the 'to receive' amount and your slippage tolerance is set at 2%, the actual number of tokens you might end up with could be anywhere between 98 and 100. The calculation of cross-chain swaps is handled in a similar way, see the explanation below: [#cross-chain-swap](#cross-chain-swap "mention") **Now, one might wonder: Why have slippage tolerance at all? Why not set it to 0%?** Setting a slippage tolerance to 0% would mean that you're not willing to accept any price deviation from the price displayed when initiating a trade. While this may sound appealing at first, there are practical reasons why it's not typically possible or recommended: * **Price Volatility** Especially in DEXs and DeFi platforms, prices can swing wildly. Minute market movements can cause a ripple in prices. At 0% slippage tolerance, even the slightest price drift would halt your trade. * **Real-time Updates** The price shown on your screen might lag slightly, given delays in data retrieval and display. By the time you press 'swap', the prevailing market price might have shifted, stopping your trade if you have no slippage tolerance. * **Blockchain Confirmation Times** There's a time gap between when you send a transaction to a blockchain and when it gets confirmed. Within this period, any ongoing transaction can nudge the price, potentially derailing your trade. While it might be technically possible to set a very tight slippage tolerance close to 0%, doing so raises the odds of your transaction not going through. It's usually wise to set a realistic slippage tolerance, striking a balance between an acceptable price and the real-world mechanics of dynamic markets. ## What happens if the price change for a trade surpasses the set limit (the slippage tolerance value)? It's essential to differentiate between on-chain and cross-chain swaps: ### **On-chain Swap** If you do an on-chain swap and the price change goes beyond your set limit, your assets stay in your wallet. But remember, you'll still lose the fees (often called "gas" on many platforms) you paid to start the transaction. ### Cross-chain Swap Let's begin with an example. Suppose you want to swap 101 USDT on Ethereum for USDC on the BNB chain, which is a cross-chain swap. The Symbiosis WebApp identifies the best route for this swap and displays certain values:\ ![](/files/O4Jwozm5FrqqX8Dod5gO) It's similar to an on-chain swap but still there are some differences. The 'to receive' token amount you see already accounts for the liquidity provider fees and cross-chain fees. The actual amount of tokens you receive might vary slightly from the displayed number, but it will always stay within the boundaries set by the slippage tolerance. Slippage tolerance represents the maximum price fluctuation you're willing to accept for your entire trade to go through. To illustrate, if you see '100 tokens' as the 'to receive' amount and your slippage tolerance is set at 2%, the actual number of tokens you might end up with could be anywhere between 98 and 100. **We come to the most interesting part: what happens when the price change surpasses our limit in the case of a cross-chain swap?** To understand this, it's essential to recognize that a cross-chain swap typically involves three sequential transactions across three distinct blockchain networks, equating to one transaction for each network. Our example of a cross-chain swap: USDT on Ethereum for USDC on the BNB chain also consists of three transactions on different blockchain networks: 1. Swap of USDT for USDC on Ethereum, 2. Shift between Ethereum and the BNB chain on Symbiosis host chain, 3. Swap of BUSD for USDC on the BNB chain. {% hint style="info" %} USDC on Ethereum and BUSD on the BNB chain serve as "transit tokens" for their respective blockchains. Transit tokens are used to facilitate cross-chain swaps between different blockchains. {% endhint %} The slippage tolerance limit ![](/files/W6kJ1RYVHv3JOn85GuHx)gets distributed among these three transactions. This ensures that each individual transaction remains within its designated slippage tolerance fraction, guaranteeing that the cumulative price variation doesn't breach the overall slippage tolerance threshold. 1. If the transaction on the first (source) network surpasses the accepted price change, then your assets stay in your wallet. 2. If the transaction on Symbiosis host chain surpasses the accepted price change, then the cross-chain swap gets halted. For more details, please see this guide: [Swap Stuck?](/user-guide-webapp/swap-stuck) 3. If the transaction on the destination blockchain surpasses the accepted price change, then you will receive an appropriate amount of the transit token. In our example, it's BUSD on the BNB chain. ## When Minimum Received Applies The **Minimum received** value applies when the swap route is fully executed. To understand what this means, consider the following example. A swap from **USDT (Arbitrum) → USDT (Avalanche)** spans three steps: 1. **USDT → USDC** on Arbitrum **→** 2. **sUSDT (Arbitrum) → sUSDC (Avalanche)** on Symbiosis **→** 3. **USDC → USDT** on Avalanche While the cross-chain transfer is in progress, the price in the **USDC ↔ USDT** pool on the destination chain may change. If the final swap can no longer be executed within the allowed slippage, the protocol does not perform the swap at a worse rate. Instead, it: * completes the cross-chain transfer and delivers the **transit token (USDC)** on the destination network In this situation, the route is not fully executed and the **Minimum received** value does not apply. In most cases, the amount received in the transit token is equal to or higher than the Minimum received value. However, in rare situations — such as when temporary arbitrage opportunities in the final liquidity pool disappear — the amount received in the transit token may be lower than the Minimum received value. ## Setting Slippage Tolerance Limit The default value for slippage tolerance value is 2% and this value can be changed.\ When exchanging stablecoins, it's okay to set a lower slippage tolerance value. Still, please be aware that low slippage tolerance value may result in higher transaction fees, delays in transaction execution, or even failure to execute the transaction. You can change the current value for slippage tolerance by pressing the cogwheel icon in [Symbiosis WebApp](https://app.symbiosis.finance/swap?chainIn=Ethereum\&tokenIn=ETH):\ ![](/files/L9PYD3pj7e0FiEu3FrB6) Select or type a new value and save your changes:\ \ ![](/files/hEJSiNYujemHniNAKCzi) # Symbiosis Reward Programs Earn rewards by providing liquidity with the Symbiosis protocol: explore Cross-chain Farming, SIS LP Farming, and veSIS programs. A comprehensive comparison of reward opportunities. ## Programs Overview Symbiosis offers the following reward programs for users who provide liquidity to the Symbiosis protocol:
Shares of LP FeesBy providing liquidity to the Symbiosis Octopools used for cross-chain operations, users receive shares of LP fees while also contributing to the growth and liquidity of the DeFi ecosystem.APR 0.1 - 7.1% (in pool tokens)
Rewards can be received at the time of liquidity withdrawal. 		/pages/KAh4blcLUb2ZEY9VM8IJ
veSISBy staking SIS tokens, users can receive rewards, and most importantly, gain voting power to shape the Symbiosis DAO.APR 7 - 10% (in SIS tokens)
Rewards are distributed once a week and can be claimed at any time as they become available. 		/pages/U0xqYEml0jNsiyp69MZB
SIS LP FarmingSymbiosis owns liquidity pools with Uniswap, SushiSwap, and Panackeswap. Users who provided liquidity to these pools can increase their rewards by staking LP tokens.APY 10 - 20% (in SIS tokens)
Rewards are daily auto-compound and can be claimed at any time. 		/pages/F4TD5kA0FNST2ItNIjZF
# Farming on Octopools Unlock Rewards with the Symbiosis Liquidity Program: receive rewards for providing assets to Symbiosis liquidity pools (Octopools). ## Rewards for Providing Liquidity The Symbiosis protocol owns two AMM multi-token liquidity pools: Octopools to implement cross-chain operations. The Symbiosis Octopools are located on the Symbiosis Host Chain. Once you supply liquidity to one of these pools, you will become a liquidity provider and receive a share of liquidity provider fees at the time you will withdraw your assets from the pool. The longer assets stay in a liquidity pool, the more you receive. You can withdraw assets in full at any time at your convenience. #### Liquidity Provider Fees The liquidity provider fees are charged for all swaps performed on Octopools. The fees taken during trades are added to the total liquidity of the pool. When a liquidity provider withdraws their assets from the pool, they also receive a proportional share of all fees collected since the liquidity was first added. This mechanism is a part of the AMM pool protocol. The main points here: * You get rewards once: when you withdraw liquidity, * The rewards are in the tokens of the pool, * The reward amount depends on the trading activity in the pool. ## User Guide ### Adding Assets to Octopool To add assets to a Symbiosis liquidity pool: 1. Open 2. Connect your wallet. 3. Press the **Manage** button below the token you are going to add. 4. If you see the *Switch network to \* button, switch to the network by pressing the button and confirming the action in your connected wallet: 5. Enter an amount you are going to add and hit the **Add Liquidity** button below. 6. Once tokens get added, you will find them in [Symbiosis WebApp > the *Pools* tab > the *My liquidity* section](https://app.symbiosis.finance/liquidity-v2) Done\ \&#xNAN;**∎** ### Checking and Claiming Rewards Liquidity providers are eligible for proportional shares of all fees collected since the liquidity was first added. The reward amount depends on the trading activity in the pool and the liquidity providers will receive the reward at the time the assets are withdrawn from the pool. To withdraw liquidity, please refer to [Octopool: Withdraw Liquidity](/user-guide-webapp/octopool-withdraw-liquidity) ### Withdrawing Liquidity To withdraw liquidity, please refer to [Octopool: Withdraw Liquidity](/user-guide-webapp/octopool-withdraw-liquidity) # veSIS ## Introducing veSIS veSIS provides an excellent opportunity to maximize the benefits of crypto assets. By staking SIS tokens, [the token of the Symbiosis protocol](/sis-token/symbiosis-sis-token), for a chosen period, users receive veSIS tokens, unlocking a range of exclusive benefits, including: 1. **Voting power in the Symbiosis DAO**\ For more information, refer to [Governing Symbiosis](/sis-token/governing-symbiosis) 2. **Cross-chain fees reductions**\ Enjoy up to 60% reductions on cross-chain fees. For more information, [refer to this article](https://medium.com/@symbiosis_fi/introducing-a-fee-discount-system-for-vesis-holders-087e9172d6af) 3. **Rewards for staking SIS tokens** \ For more information, continue reading this document ## How it works Users can stake SIS tokens in Symbiosis smart contracts on the following chains: Ethereum, BNB Chain, zkSync EVM, and Linea. The longer the SIS tokens are locked, the greater the rewards and voting power for the holders. Consider the following examples: * 1 SIS locked for 4 years = 1.00 veSIS * 1 SIS locked for 3 years = 0.75 veSIS * 1 SIS locked for 2 years = 0.50 veSIS * 1 SIS locked for 1 years = 0.25 veSIS Rewards in SIS tokens are distributed weekly, on Thursday at 00:00 UTC. {% hint style="info" %} Rewards are accrued for the full week; for example, if you lock SIS tokens on a Friday, the first portion of rewards for that lock will be available in 13 days, not 6. {% endhint %} The number of veSIS tokens gradually decreases until, by the end of the lock period, there are 0 veSIS tokens, and the locked SIS tokens become available for withdrawal. Users can claim their rewards in full at any time; there is no vesting period. Locked SIS tokens become available for withdrawal once the chosen lock period is over.
Weekly Rewards Calculation Example **Given:** * **Total Locked SIS**: 100,000 * **Total veSIS issued**: 1,000 **Personal:** * **Your Locked SIS**: 500 * **Your veSIS**: 100 **Assumption:** * **APR**: 10%, which translates to a weekly rate of approximately 0.192% (since 1 year approximately contains 52 weeks). **Rewards Calculation:** 1. **Total Rewards for All Holders**: Total Rewards = 100,000 × 0.00192 = 192 SIS 2. **Rewards per veSIS**: Rewards per veSIS = 192 / 1,000 = 0.192 SIS 3. **Your Share**: Your Rewards = 100 × 0.192 = 19.2 SIS Thus, with 100 veSIS, you would receive **19.2 SIS** as your reward for the week.
## User Guide There are two steps on the path to veSIS rewards, voting power, and other benefits: 1. **Getting SIS Tokens**: Obtain SIS tokens on Ethereum, the BNB Chain, zkSync Era, and/or Linea.\ For information about how to add SIS token to you wallet and obtain SIS tokens, please refer to [SIS Token Guide](/sis-token/sis-token-guide) 2. **Staking SIS Tokens**: Get veSIS tokens by staking SIS tokens on Ethereum, the BNB Chain, zkSync Era, or Linea. Users can stake SIS tokens on multiple networks simultaneously to maximize their benefits. ### Joining the veSIS Program To join the veSIS reward program and receive rewards, discounts, and voting power, you need to lock your SIS tokens first. When you lock SIS tokens, you will receive veSIS tokens in exchange. The more veSIS tokens you have, the more rewards and voting power you will receive. You can lock SIS tokens on Ethereum, BNB chain and zkSync Era. If you have SIS tokens locked on more than one chain, the SIS tokens of all chains will be taken into account for voting and discounts. To lock SIS tokens: 1. Open 2. Connect your wallet. 3. Select the blockchain (Ethereum, BNB chain, zkSync Era, or Linea) where you want to lock your SIS tokens. 4. If you don't have SIS tokens click **Get SIS***.*\ You will be redirected to the Swap section of Symbiosis WebApp. Once you have SIS tokens, navigate back to 5. Enter the number of SIS tokens you are going to lock, choose the duration of the lock (during this period, you will accrue rewards once a week, where 52 weeks are approximately 1 year), and press the **Confirm** **lock** button 6. If you see the *Switch network to Ethereum/BNB/zkSync Era/Linea* button, switch to the network by pressing the button and confirming the action in your connected wallet. 7. If you see *Approve SIS amount* button, approve the token use by pressing the button and approve the transaction in your wallet:. 8. Press the **Create Lock** button\ \ **Important:** *APR*, *Weekly Rewards*, and *Total Rewards* listed for your lock are estimated values. They are calculated based on the total number of SIS tokens locked at the time of calculation and the reward amount allocated weekly.
9. Once the transaction of the lock creation is mined, you will return to the top page, where you will see your lock. Expand **More About Your Lock** to see details of the lock.
{% hint style="info" %} The number of veSIS tokens gradually decreases until, by the end of the lock period, there are 0 veSIS tokens, and the locked SIS tokens become available for withdrawal. **Note:** Weekly and total rewards listed for your lock are estimated values. They are calculated based on the total number of SIS tokens locked at the time of calculation and the reward amount allocated last week. {% endhint %} ### Managing Your Lock You can extend an existing lock and/or add more SIS tokens to an existing lock. To change existing lock: 1. Open 2. Connect your wallet. 3. Select the blockchain where you have created your lock. 4. If you have a lock, you will see:\ ![](/files/46r3091oYejVDp7lns1g)
5. Click the cogwheel icon:\ ![](/files/Ns4pLWb47ABivazvYfYD) 6. Here you can manage your lock: add more SIS tokens and/or increase the lock duration:\ ![](/files/WaBzt8k18lBa4oTdBfjY)\ \ **Amount:** To increase the amount of SIS tokens, enter the number of SIS tokens you want to add to your existing lock, and press the *Change Lock* button:\ ![](/files/bCtI4CLW48aVn1ui29kc)\ \ **Time:** To extend the time, enter the amount of time you want to extend your lock, and press the *Change Lock* button:\ ![](/files/ICA1X9Om0aDglI1GTVrw)\ \ **Important:** The lock duration and add more SIS tokens cannot be done in a single operation.
7. Confirm the transaction in your wallet. {% hint style="info" %} Once the lock time has ended, the SIS tokens can be unlocked. Please claim rewards first, then you will be able to unlock SIS tokens. {% endhint %} ### Checking and Claiming Rewards {% hint style="info" %} * Rewards are distributed once a week, on Thursday at 00:00 UTC. * Rewards are accrued for the full week. For example, if you lock SIS tokens on Friday, the first portion of the rewards for that lock will be available in 13 days, not 6. * The number of veSIS tokens gradually decreases until, by the end of the lock period, there are 0 veSIS tokens, and the locked SIS tokens become available for withdrawal. {% endhint %} {% hint style="info" %} The time depth of rewards information to be displayed is 50 weeks (approximately one year). {% endhint %} To check and claim your rewards: 1. Open 2. Connect your wallet. 3. Select the blockchain where you have locked SIS tokens. 4. If you have a lock you will see \ ![](/files/sDSFBhd49sAF6PcgmApg)
5. Press the **Claim Rewards** button, and confirm the transaction in your wallet. Once the transaction is mined, the reward tokens will be sent to your address. \ \ **Important:** Due to the complexity of the smart contract, there is a maximum time depth of 50 weeks (approximately one year) for claiming rewards. If you haven't claimed rewards for more than 50 weeks, you will need to do so multiple times. ### Withdrawing SIS tokens Once the lock time is over, the SIS tokens can be unlocked. Please claim rewards first, then you can withdraw your SIS tokens. **Important:** Due to the complexity of the smart contract, there is a maximum time depth of 50 weeks (approximately one year) for claiming rewards. If you haven't claimed rewards for more than 50 weeks, you will need to do so multiple times. # Symbiosis Relayers Network ## Symbiosis Relayers Network Introduction

Components of the Symbiosis protocol

The Symbiosis Relayers Network is a peer-to-peer (P2P) network that enables the reliable and secure transmission of data required for cross-chain operations within the Symbiosis protocol. As the off-chain component of the Symbiosis protocol, it facilitates communication between blockchain networks. Why is communication between blockchain networks needed? Blockchain networks are designed to operate in isolation, unaware of events occurring outside their boundaries. While this approach works well for operations limited to a single chain, cross-chain operations require an off-chain component to coordinate actions and transfer data across multiple networks. The Symbiosis Relayers Network fulfills this role by ensuring data integrity and accuracy during cross-chain operations handled by the Symbiosis protocol. ## Symbiosis Relayers Network Economics The security and incentives of the Symbiosis protocol are maintained through two complementary mechanisms: 1. Symbiosis PoS Staking, and 2. Symbiotic Staking. These mechanisms work together to secure the protocol and incentivize participants. ## Next Steps
Economics and Security: Symbiosis PoS Staking & Symbiotic StakingDiscover how Symbiosis PoS Staking and Symbiotic Staking secure the protocol, incentivize participants, and strengthen network resilience. Learn about the roles of Validators, Delegators, and Symbiotic Operators.
Read more →/pages/ktubJcEpVALdH2Wltww5
Architecture and Operations: Symbiosis Relayers NetworkExplore the technical design of the Symbiosis Relayers Network, including its components, decentralized coordination mechanisms, and the execution of cross-chain operations. Understand how these elements work together to facilitate secure and efficient communication across blockchains.Read more →/pages/zjHksOLesLBfIp156O6K
# Symbiosis PoS Staking & Symbiotic Staking ## Overview The security and incentives of the Symbiosis protocol are built upon two complementary mechanisms: 1. **Symbiosis PoS Staking**\ Proof of Stake (PoS) Staking ensures the security and stability of the Symbiosis protocol by allowing participants to lock (stake) their tokens to support the operation of the Symbiosis Relayers Network.\ **Learn how to participate:** [Symbiosis PoS Staking User Guide](/relayers-network/symbiosis-pos-staking-and-symbiotic-staking/symbiosis-pos-staking-user-guide) 2. **Symbiotic Staking**\ As an additional layer of security, Symbiotic Staking strengthens the Symbiosis protocol by adding collateral and linking it to a wider network of stakers and systems. To better understand the interplay between these components, let’s examine the following: * The relationship between Symbiosis PoS Staking and the Symbiosis Relayers Network. * The transition process from Symbiosis Validators to Symbiotic Operators. * Practical guidance on participating in the staking ecosystem and receiving rewards. The following diagram (Scheme 1) illustrates the interaction between these components and participants within the Symbiosis protocol:

Scheme 1. Symbiosis PoS Staking and Symbiotic Components

## Symbiosis PoS Staking The **Symbiosis Relayers Network** is powered by independent relayer nodes, each running relayer software and registered in the **Symbiosis PoS Staking Contracts**. These contracts, deployed on the **Symbiosis PoS Host Chain**: Arbitrum, perform two key functions: * Storing information required to verify and authorize relayer nodes for participation in network operations. * Facilitating staking activities and distributing rewards to participants, including **Validators** and **Delegators**. #### Roles in Symbiosis PoS Staking Participants in the Symbiosis PoS Staking can engage in two roles: * **Validators** supporting Relayer Node Runners, * **Delegators** supporting Validators by staking additional assets. Let’s examine these roles in more detail: 1. **Relayer Node Runner**\ A Relayer Node Runner is responsible for running and maintaining a registered relayer node, ensuring its continuous operation, performing updates, and managing software and hardware. 2. **Validator**\ A Validator provides the required stake for a relayer node by locking tokens in the Symbiosis PoS Staking Contracts as collateral. This stake supports the node’s operations and contributes to the protocol’s overall security. Validators receive rewards proportional to the node's performance.\ \ **Note:** Typically, the Node Runner and Validator are the same entity, but this is not a strict requirement. 3. **Delegator**\ A (stake) Delegator contributes tokens to the Symbiosis PoS Staking Contracts, supporting one or more Validators by increasing their stake pool. In return, Delegators receive a share of the rewards generated by the nodes they support. #### Symbiosis PoS Incentives and Penalties To ensure reliable operations and incentivize active participation, Symbiosis PoS Staking implements the following mechanisms: * **Rewards:** Validators and Delegators earn rewards based on the performance and contributions of the relayer nodes they support. * **Blocking:** Misbehavior by relayer nodes can result in blocking within the Symbiosis PoS Staking Contracts. A blocked node is excluded from network operations and cannot receive rewards. ## Symbiotic Staking **Symbiotic Staking** serves as an additional layer of security for the Symbiosis protocol, increasing the assets locked as collateral and enhancing the protocol's resilience. Validators who are already responsible for registering relayer nodes and providing staking in the **Symbiosis PoS Staking Contracts** can expand their role by registering in Symbiotic. **Note:** Registration in Symbiotic does not require additional staking from Validators. #### How It Works: Upon registration, Symbiosis Validators become **Symbiotic Operators**, expanding their role to include participation in Symbiotic Vaults. Within Symbiotic Vaults, specific amounts of assets are allocated for each Symbiotic Operator. These allocations are recorded in the **Symbiotic Vault Contracts** and **Symbiotic Staking Contract**, reflecting the assets attributed to each operator for securing the protocol. The Symbiotic Staking Contract (contract-connector), the Symbiotic Vault Contracts, and other supporting infrastructure are deployed on the **Symbiotic Host Chain**: Ethereum. #### Symbiotic Incentives and Penalties: To ensure active and reliable participation, Symbiotic implements the following mechanisms: * **Rewards:** Operators receive rewards based on their contributions. * **Slashing:** Misbehavior can result in penalties applied to the allocated stakes in the Symbiotic Vaults. ## How to Participate
Symbiosis PoS StakingSymbiosis PoS Staking is the backbone of the Symbiosis Protocol. Individuals and organizations become Validators and Delegators, securing the protocol.Learn how participate/pages/yihQ4qSh5agfdUXjHeve
SIS Restaking VaultThe vault funds are used to secure the Symbiosis Protocol by supporting relayer nodes within the Symbiosis Relayer Network.Learn how to participate/pages/caxfEGbnT9nkoiLAMAgb
# Symbiosis PoS Staking User Guide Symbiosis PoS Staking Introduction The **Proof of Stake (PoS)** mechanism secures and stabilizes the Symbiosis protocol.\ It is implemented in the **Symbiosis PoS Staking Contracts**, which handle two main functions: * Storing data required to verify and authorize relayer nodes for participation in operations of the Symbiosis Relayers Network. \ For more details, see [Relayers Network: Architecture and Operations](/relayers-network/symbiosis-relayers-network-architecture-and-operations) * Facilitating staking activities and distributing rewards to participants, including **Validators** and **Delegators**. \ This guide explains how to stake, track staking activities, check rewards, etc.. ## Roles And Participants * **Validator**: A Validator is responsible for registering a relayer node and staking SIS tokens as collateral in the Symbiosis PoS Staking Contracts. Each Validator supports one relayer node and cannot delegate tokens to other validators. * **Delegator**: A Delegator supports Validators by delegating SIS tokens to their stake pool via the PoS Staking Contracts. A Delegator can support multiple Validators. * **Validator Group**: A Validator Group consists of a Validator and the Delegators supporting the same relayer node. ## Symbiosis PoS Staking Details * **Network**: Arbitrum * **Interface**: * **Staking/Reward Token**: SIS * **Rewards:** [Symbiosis PoS Staking Rewards](/relayers-network/symbiosis-pos-staking-and-symbiotic-staking/symbiosis-pos-staking-rewards) * **Penalties:** Blocking ## SIS Token Overview The **SIS token** is the utility token of the Symbiosis protocol. It plays a central role in operations such as governance, transaction fees, staking, and more. Originally deployed on **Ethereum**, SIS tokens have been bridged and are now available on the following networks: Ethereum, BNB chain, Arbitrum One, zkSync Era, Linea, and Scroll. To participate in **Symbiosis PoS Staking**, SIS tokens must be held on **Arbitrum One**. The easiest way to get SIS tokens on Arbitrum One is via Symbiosis WebApp at [app.symbiosis.finance](https://app.symbiosis.finance/swap?chainOut=Arbitrum\&tokenOut=0x9E758B8a98a42d612b3D38B66a22074DC03D7370), which supports two main scenarios: * Holding SIS tokens on another blockchain and bridging them to Arbitrum * Exchanging other tokens for SIS directly on Arbitrum {% hint style="info" %} When swapping or bridging, always check the **Price Impact**. If it is high, consider: * Swapping smaller amounts * Trying a different blockchain {% endhint %} **Additional Information** For full details about the SIS token — including token addresses, total supply, supported bridges, use cases, etc. — see [Symbiosis SIS Token](/sis-token/symbiosis-sis-token) ## Validator Guidelines Becoming a Validator involves two steps: 1. Install and run a relayer node. 2. Stake and register your relayer node in the Symbiosis PoS Staking Contracts. ### 1. Relayer Node Installation {% hint style="info" %} **Symbiosis PoS Staking is currently in a limited rollout with a small validator group.** The relayer software and setup instructions will be shared publicly after this phase. If you are interested in running and supporting your own relayer node, please fill out the [form](https://docs.google.com/forms/d/108L_jS7Ukg-lWOxfAZIJjT__FaMB8l_L7Za8aH9jf30/). We will contact you as soon as participation becomes available. {% endhint %} ### 2. Staking and Node Registration To register a relayer node and provide a stake: 1. Go to 2. Connect your wallet. 3. Click **Register as Validator**:\ ![](/files/spvCTLJiNDDwtef5SsUl) 4. Specify the amount for staking:\ ![](/files/WPTKOBMuaf8m2NLtv0B3)\ \ **Note:** The amount can be changed later, though it cannot be less the minimum required. 5. Enter the address corresponding to your node private key:\ ![](/files/ebkPisHatQzJRaL2m30L)\ \ **Important:** if the node private key is changed, the address registered in the Symbiosis PoS Staking must be updated as well. 6. Specify the Validator name and type a short introduction (this information can be changed later on):\ ![](/files/KhCL2xKOPTfrqVtHMa5a) 7. Check the registration details. 8. Approve token use. 9. Submit registration. ### Validator Statuses A validator’s lifecycle in Symbiosis PoS Staking goes through several statuses: `Pending -> Registered -> Active -> Inactive` Additional status: `Offline` **Status transitions occur discreetly: at the time of an epoch change**. * **Pending**: Registration request received. Information is being processed. * **Registered**: Registration completed. `uptime = 0`. The relayer node has not yet proven it is running. Delegation is not available. * **Active**: `uptime > 0`. The node is up and running, participating in network operations. **Delegation of tokens is allowed only in this status.** * **Inactive:** The validator has withdrawn their stake. The node is no longer active in the network. * **Offline**: The validator is currently unavailable. The node cannot participate in network activities. **Staked and delegated tokens remain safe and can be withdrawn.** ## Delegator Guidelines Delegators support Validators by delegating SIS tokens to their stake pool via the PoS Staking Contracts. A Delegator can support multiple Validators. ### New Delegation To select a Validator or Validators and delegate SIS tokens: 1. Go to 2. Connect your wallet. 3. Click **Delegate to Validator**:\ ![](/files/spvCTLJiNDDwtef5SsUl) 4. Choose a Validator from the list and click **Details**:\ ![](/files/6C8mP2pjdg21IpMl6gzL) 5. Review details and click **Delegate**:\ ![](/files/5FLjtIrf8he4hpp19DI1) 6. Specify the amount for staking and click **Next Step**:\ ![](/files/pLYsRVvvV82GdwZrBGrr) 7. Review the delegation summary:\ ![](/files/kS7iL27FdJJY3m9LJJtu) 8. Approve token use. 9. Delegate tokens: \ ![](/files/O3tyKajff4n9PTnLbNHW)\ \ **Important:** Once you delegate your tokens, you need to wait for an epoch change, which typically occurs approximately every 24 hours. After the epoch change, your delegated tokens will be accounted for in Symbiosis PoS Staking, and you will start accruing rewards.\ \ The status will change from `Pending` to `Active`:\ ![](/files/Z9SnTelxLJdZh3q6Dfmd) ### Reviewing Delegations To review your existing delegations: 1. Go to 2. Connect your wallet. 3. Click **Delegator Overview**:\ ![](/files/C5S7VrgKG1N3oNO2BwV2) 4. Click **Manage** next to a Validator you delegated for:\ ![](/files/l74z7sZIv8dPndYteoNZ) 5. Check details:\ ![](/files/4P2kfmmtcUT6O1XB9Xzd)\ \ **Important:** Once you delegate your tokens, you need to wait for an epoch change, which typically occurs approximately every 24 hours. After the epoch change, your delegated tokens will be accounted for in Symbiosis PoS Staking, and you will start accruing rewards.\ The status will change from `Pending` to `Active`\
# Symbiosis PoS Staking Rewards Symbiosis Proof of Stake (PoS) Staking ensures the security and stability of the Symbiosis protocol by enabling participants – Validators and Delegators – to stake tokens in support of the Symbiosis Relayers Network. In return, Validators and Delegators receive rewards based on protocol-defined rules and the actual performance of the relayer nodes they support. This document details how rewards are calculated and distributed. {% hint style="info" %} **Disclaimer:** The reward calculation and distribution mechanisms described in this document are applicable to all Validators and Delegators. These terms are effective as of the date of publication and may be updated at the discretion of the Symbiosis protocol. {% endhint %} ## Roles And Participants * **Validator**: A Validator is responsible for registering a relayer node and staking SIS tokens as collateral in the Symbiosis PoS Staking Contracts. Each Validator supports one relayer node. * **Delegator**: A Delegator supports Validators by delegating SIS tokens to their stake pool via the PoS Staking Contracts. A Delegator can support multiple Validators. * **Validator Group**: A Validator Group consists of a Validator and the Delegators supporting the same relayer node. ## Reward Summary **Who receives rewards?**\ Validator Groups whose relayer nodes participated in signing the epoch change. **How often are rewards distributed?**\ Rewards are calculated and distributed at the time of an epoch change – but only if the epoch was completed by the Symbiosis Relayers Network. \>> More information about the **Epoch Change Procedure** can be found here: [Relayers Network: Architecture and Operations](/relayers-network/symbiosis-relayers-network-architecture-and-operations#epoch-change-process) **What is the epoch duration?**\ The default epoch duration is 24 hours. The actual epoch duration may differ from the default epoch duration. **In what form are rewards distributed?**\ All PoS Staking rewards are distributed in SIS tokens. **Where is staking and reward data stored?**\ All staking and reward data is stored on-chain in the Symbiosis PoS Staking Contracts deployed on Arbitrum. **How to participate in the Symbiosis PoS Staking and receive rewards?**\ Use the [Symbiosis PoS Staking App](https://staking.symbiosis.finance/), which provides a user-friendly interface to interact with the Symbiosis PoS Staking Contracts. This is the recommended method for Validators and Delegators. ## Reward Calculation Details Rewards are determined based on two values stored in the Symbiosis PoS Staking Contracts: * Default epoch duration * Reward pool per default epoch ### Actual Reward Pool per Real Epoch In practice, the actual duration of an epoch may differ from the default. In such cases, the reward pool is adjusted proportionally. For example, if: * Default epoch duration = 24 hours * Reward pool = X SIS tokens Then: * If the real epoch lasts 24 hours, the reward pool = X * If it lasts 12 hours, the reward pool = X / 2 * If it lasts 25 hours, the reward pool = X + X / 24 Epoch start and end times are determined by the timestamps of the corresponding blocks recorded on-chain. ### Reward Pool Distribution The actual reward pool is distributed only among Validator Groups whose relayer nodes participated in signing the epoch change. Distribution is proportional to the group stake size, where the group size is the validator stake plus the delegator stakes. ### Reward Distribution within Group Once the Validator Group receives its share, rewards are split within the group as follows: * The **Validator** receives **7.5%** of the group's total reward; * The remaining **92.5%** is then distributed proportionally between the **Validator and Delegators** based on their stake share. **Example:** Validator Group total stake: 200,000 SIS, where * Validator stake: 170,000 SIS (85%) * Delegators stake: 30,000 SIS (15%) Reward for the epoch earned by this validator group: 1,000 SIS * Validator receives: * 7.5% base reward: 1,000 × 0.075 = 75 SIS * Plus 85% of the remaining 925 SIS: (1,000 \* 0.925) \* 0.85 = 786.25 SIS * Validator Total: 861.25 SIS * Delegators receive: (1,000 \* 0.925) \* 0.15 = 138.75 SIS ### Reward Accumulation * Validator rewards are automatically added to their stake and begin compounding – thus Validators receive APY. * Delegator rewards must be claimed manually and do not compound automatically – hence Delegators receive APR. # Symbiosis X Symbiotic: SIS Restaking Vault User Guide ## Introduction This guide explains what the **SIS Restaking Vault** is and provides instructions on how to deposit and withdraw SIS tokens. ## What is the SIS Restaking Vault? Symbiotic is a **permissionless restaking protocol** that enables decentralized protocols and ecosystems to access economic security from those who provide staked assets. In Symbiotic, staked assets are locked into Vaults – smart contract-based pools, each configured to accept a specific ERC-20 token. These Vaults allow stake providers to contribute assets and receive rewards, while protocols utilize the staked assets to enhance security, particularly for cross-chain operations. The **Symbiotic infrastructure**, including Vault contracts, operates on **Ethereum**. ### SIS Vault Parameters Symbiosis has deployed a **Symbiotic Vault** with the following parameters: * **Vault Token:** SIS * **Vault Limit:** Initially set at 1,000,000 SIS tokens. * **Seeded Funds:** **250,000 SIS** provided by the **Symbiosis Foundation** * **Open Deposits:** The remaining tokens are available for SIS holders to deposit 250,000 SIS tokens have been seeded by the Symbiosis Foundation. The remaining tokens are open for deposits from SIS token holders. The vault funds are used to secure the **Symbiosis Protocol** by supporting relayer nodes within the **Symbiosis Relayer Network**. ## Why Stake in the SIS Vault? Staking SIS tokens in the vault helps secure the **Symbiosis Protocol** by increasing its economic backing. Users who deposit SIS tokens into the vault are eligible to receive: 1. **Liquidity rewards** for providing staked assets 2. **Symbiotic Points** as additional incentives (details: [Symbiotic Points Session 2](https://docs.symbiotic.fi/points-season2/)) ## Guidelines ### How to Deposit #### Getting SIS Tokens Since the entire **Symbiotic infrastructure**, including Vault contracts, operates on **Ethereum**, you must first obtain **SIS tokens on Ethereum** before making a deposit. The easiest way to swap any token for **SIS** or bridge **SIS tokens** to **Ethereum** is through the **Symbiosis WebApp.** Steps to Get SIS Tokens Using the Symbiosis WebApp: 1. Open the [Symbiosis WebApp](https://app.symbiosis.finance/swap?amountIn=0.1\&chainIn=Ethereum\&chainOut=Ethereum\&tokenIn=ETH\&tokenOut=0xd38BB40815d2B0c2d2c866e0c72c5728ffC76dd9). 2. Connect your wallet. 3. In the **"From"** field: Select the **source chain** and **token** you want to exchange. 4. In the **"To"** field: Select **Ethereum** and **SIS**:\ ![](/files/gtwgdjhAklsifUQxB0r2) 5. Complete the swap. #### Depositing {% hint style="info" %} **Note:** Withdrawals of deposited tokens may have a delay of 7–14 days. {% endhint %} Steps to Deposit into the SIS Vault: 1. Open the [**SIS Vault details** in the Symbiotic web application](https://app.symbiotic.fi/vault/0x2eE8fe221AFD5Da36a5cfD4fee12BE5dAb562397):\ ![](/files/e3uIh2fo1sChJDgQQan8) 2. Connect your wallet (*make sure the active account is the one with SIS tokens*):\ ![](/files/YOUzQPHoIc4d5xKWxZLe) 3. Go to the "Action" tab:\ ![](/files/5dvYpY6g2gqUcdBA0QuD) 4. Switch the network if required. 5. Enter the deposit amount and click "Deposit":\ ![](/files/gkxSX7W9IBLnseHaeBoF) 6. Approve the token spending in your wallet:\ ![](/files/f1lbPODBLZcJEeGUp90r) 7. Confirm the deposit transaction in your wallet:\ ![](/files/3kYakqryvhkExaNHNG6u) 8. Deposit completed!\ ![](/files/5drBiHTncX6qKdUQUU5j) All your Positions and Withdrawals in Symbiotic vaults can be viewed in the [Dashboard](https://app.symbiotic.fi/dashboard/positions):\ ![](/files/Q5jSypAXEAaNPrrsE6c5) ### How to Withdraw {% hint style="info" %} **Note:** Withdrawals of deposited tokens may have a delay of 7–14 days. {% endhint %} Steps to Withdraw Your Deposited Tokens from the SIS Vault: 1. Open the [**SIS Vault details** in the Symbiotic web application](https://app.symbiotic.fi/vault/0x2eE8fe221AFD5Da36a5cfD4fee12BE5dAb562397):\ ![](/files/e3uIh2fo1sChJDgQQan8) 2. Connect your wallet (*make sure the active account is the one used for the deposit*). 3. Go to the "Action" tab:\ ![](/files/5dvYpY6g2gqUcdBA0QuD) 4. Switch the network if required. 5. Go to "Withdraw":\ ![](/files/QV9HxmkuElAZaK0yOw4f) 6. Enter the withdrawal amount and click "Request Withdrawal":\ ![](/files/JS5t9786OvNbmp86isIV) 7. Confirm the withdrawal transaction in your wallet:\ ![](/files/cCk7ezmCkRE3vkOLQA5l) 8. Withdrawal request placed! All your Positions and Withdrawals in Symbiotic vaults can be viewed in the [Dashboard](https://app.symbiotic.fi/dashboard/positions):\ ![](/files/Q5jSypAXEAaNPrrsE6c5) # Relayers Network: Architecture and Operations ## Overview Symbiosis Relayers Network is a blockchain-agnostic, P2P network consisting of registered relayer nodes. It facilitates the secure and efficient transmission of data between supported blockchain networks, ensuring data integrity and resilience against potential attacks through various technical approaches and crypto-economic incentive mechanisms. In this article we take a closer look at the components of the relayers ecosystem, their roles, and how they interact to facilitate cross-chain operations within the Symbiosis protocol. ## Relayers Ecosystem The components of the relayers ecosystem (Scheme 1) can be grouped into two main categories based on their application: 1. Cross-Chain Operation Processing 2. Relayers Network Organization and Coordination

Scheme 1. Components of the Symbiosis Relayers Ecosystem

### Cross-Chain Operation Processing At the heart of the Symbiosis protocol are the **Core Smart Contracts (1)**, which implement the on-chain logic for cross-chain operations. These smart contracts are deployed across all blockchain networks supported by Symbiosis and are fine-tuned to handle requests specific to each network. When the smart contracts process a request, they generate events called Oracle requests. These events contain all the necessary data to execute the next steps of cross-chain operations on other chains and are key triggers for the relayers’ activity. Relayer nodes of the **Symbiosis Relayers Network (2)** continuously monitor new blocks on all supported blockchains, searching for Oracle requests created by the Core Smart Contracts. Once relayer nodes detect a request, they validate the event, compose calldata with the instructions from the request, sign it, and then send it to the appropriate blockchain. In a nutshell, this is how instructions for cross-chain operations are transmitted from network to network. It’s worth mentioning two microservices that relayer nodes use when validating, and sending signed calldata with instructions for processing operations across blockchains: **Advisor (3)** and **Broadcaster (4)**: * **Advisor (5):** This microservice is used to fetch gas prices on the blockchains supported by Symbiosis, ensuring that transactions will be processed. * **Broadcaster (6):** This microservice sends transactions with calldata signed by relayers to the respective blockchains. {% hint style="info" %} **Note on Microservices Design:** Some of the relayer’s functionalities were isolated into the Advisor and Broadcaster microservices to accelerate software development and minimize potential issues caused by the interaction of various components. These microservices cannot modify transaction data and do not have access to the user's or node runner's funds at any time. However, it’s worth mentioning that, despite being simple, secure, and reliable, these microservices are currently centralized components. In the future, we may explore decentralized alternatives, such as: 1. Running multiple instances of each microservice type and delegating them to microservice runners for a fee. 2. Merging the microservice functions back into the relayer’s software. 3. Running the microservices as a separate decentralized service on a group of relayers. {% endhint %} With the process of cross-chain operations clarified, let’s move on to the structure and organization of the Symbiosis Relayers Network. How does a decentralized network coordinate and execute complex collective actions? ### Relayers Network Organization and Coordination The Symbiosis Relayers Network consists of independent relayer nodes, each running relayer software and registered in the **Symbiosis PoS Staking Contracts (5)**. These contracts store information required to verify and authorize relayer nodes to participate in relaying operations and provide staking and rewards functionality. {% hint style="info" %} **Important:** Nodes running the relayer software but not registered in the Symbiosis PoS Staking Contracts cannot participate in relaying operations and are not recognized as relayer nodes or as part of the Relayers Network. {% endhint %} Another critical component of the Relayers Ecosystem is the **Relayers On-Chain Config Contract (6)**. This contract contains configuration data required for relayer collaboration, such as: the current size of the MPC group, the actual address of the Symbiosis PoS Staking Contracts, and other essential parameters. Each relayer regularly queries the On-Chain Config Contract for updates to ensure alignment with the latest network configuration. Additionally, relayer nodes registered in the PoS Staking Contracts can optionally register in the **Symbiotic Staking Contract** **(7)**. This registration does not require additional staking. Instead, specific amounts of assets are allocated to each Symbiotic Operator (an entity registered in the Symbiotic Staking Contract) within **Symbiotic Vault Contracts** **(8)**. The stake provided in the Symbiosis PoS Staking Contracts and the assets allocated in the Symbiotic Vaults are both considered when selecting the MPC group (see [#epoch-change](#epoch-change "mention")). As a result, the Symbiosis Relayers Network operates as a blockchain-agnostic, P2P network of registered relayer nodes. It facilitates the secure and efficient transmission of data between supported blockchain networks, ensuring data integrity and resilience against potential attacks through various technical approaches and crypto-economic incentive mechanisms. ### Network Structure and Role Distribution To effectively carry out its functions, the Symbiosis Relayers Network is structured into distinct groups, each with a specific role in maintaining network functionality and security. These groups ensure efficient coordination and reliable execution of cross-chain operations. The organization of these groups is illustrated in Scheme 2 below ![Scheme 2. The Relayers Network divided by groups.](/files/zu25yucTQyngKHFHWOTx) Where: 1. The **Symbiosis Relayers Network** comprises all relayer nodes registered in the Symbiosis PoS Staking Contracts. The maximum number of relayer nodes is defined in these contracts. 2. The **Bootstrap Group** is responsible for providing connection information to new relayer nodes joining the network. By default, the relayer software includes a configuration file listing bootstrapping nodes. Newly joining relayer nodes use this information to connect to the network. Any relayer node currently connected to the network can function as a bootstrapping node. 3. The **MPC Group (Multi-Party Computation Group)** is the active group for the current epoch, selected by an algorithm executed on each relayer node at the start of an epoch. It is responsible for: 1. **Validating and signing calldata:** Processing Oracle requests emitted by Core Contracts and routing the signed calldata to appropriate blockchains. A valid signature requires at least 2/3 of the MPC Group members. 2. **Generating and storing an MPC key:** Each relayer node in the MPC Group holds a fragment of the key. 3. **Updating the MPC address:** Replacing the MPC address of the previous epoch stored in the Core Contracts with a new one. 4. The **Veto Group** of trusted relayer nodes that play a critical role in ensuring transaction security. * **Full Participation Required:** Every member of the Veto Group must participate in generating a valid signature. If even one member abstains, the signature is invalid, and the Symbiosis Protocol halts processing of the associated calldata. * **Veto by Inaction:** Instead of explicitly blocking transactions, the Veto Group members **do not sign** transactions they consider suspicious. This prevents unauthorized or potentially malicious transactions from being executed.\ \ **Governance of the Veto Group:** Currently, trusted relayer nodes are manually flagged in the Symbiosis PoS Staking Contracts by Symbiosis sysadmins. In the future, the Relayers Network aims to transition to a decentralized method of setting the Veto Group. ## Functions of the Symbiosis Relayers Network The Symbiosis Relayers Network performs the three key functions: 1. **Connecting to the Network:** This involves authenticating and connecting relayer nodes to the network, enabling them to participate in relaying operations 2. **Cross-Chain Data Transfer:** Facilitates the processing of cross-chain operations, ensuring secure and reliable data transmission across supported networks. 3. **Epoch Change:** At the start of a new epoch, a new MPC (Multi-Party Computation) group is selected, and a new MPC key is generated, ensuring decentralized and continuous network operation. #### Important Considerations Before continuing, two key points should be highlighted: **1. Multisig Protection** Symbiosis PoS Staking Contracts, On-Chain Configuration, and Core Contracts have functionalities that allow their state to be modified. These changes can only be made by the contract owner, which is assigned to a Multisig contract.\ \ **Why this matters:** Symbiosis administrators can only update contract states via Multisig, reducing the risks associated with lost or compromised private keys and minimizing human error. **2. RPC Consensus Mechanism** Each relayer in the Relayers Network monitors blocks across all supported blockchains, searching for specific events emitted by Symbiosis contracts. There are two ways a relayer node can validate block and event data: * **Full Nodes:** the relayer node runner supports full nodes for all supported blockchains. In this case, the relayer node retrieves data from trusted, self-operated nodes. * **RPC Consensus:** if a relayer node runner cannot support full nodes for all blockchains, the relayer node relays on multiple RPC endpoints per blockchain. An event is considered valid if it is confirmed by at least two independent RPC sources. \ \ **Note:** The RPC consensus model may vary for blockchains that experience RPC-related issues. ### Connecting to the Relayers Network When a relayer node starts or reconnects to the Relayers Network, it first connects to the bootstrapping nodes listed in its configuration file. #### **Authentication Process** The relayer node receiving the connection request verifies the identity of the connecting relayer node by: 1. **Checking Registration Status:** * Ensuring that the relayer node's address is present in the Symbiosis PoS Staking Contracts. * Verifying that the relayer node is not blocked. 2. **Verifying Ownership:** * Confirming that the connecting relayer node possesses a private key corresponding to its registered address. If any of these checks fail, the connection request is rejected. In the case of suspicious or repeated failed attempts, additional security measures may be triggered. #### **Establishing Network Connectivity** Once a relayer node is successfully authenticated: 1. The verifying relayer broadcasts information about the newly connected node to the Relayers Network. 2. The verifying relayer sends a list of active connections to the new relayer node. 3. The new relayer establishes secure connections with all currently active relayer nodes. #### **Maintaining Secure Connections** After authentication, all relayer nodes maintain active, encrypted connections with each other to ensure secure communication. For more details on the key management process for relayer nodes, please refer to [Symbiosis Relayer Node](/relayers-network/symbiosis-relayer-node) ### Cross-Chain Data Transfer {% hint style="info" %} For details on on-chain processes during cross-chain operations, please refer to [Symbiosis Routing Contracts](/crosschain-liquidity-engine/symbiosis-routing-contracts). This document focuses specifically on the role of the Relayers Network. {% endhint %} The primary function of the Symbiosis Relayers Network is fast and secure cross-chain data transfer, ensuring that messages containing instructions for cross-chain operations are reliably transmitted between blockchains without modification. Core Smart Contracts handle the on-chain logic for cross-chain operations and are deployed on all supported blockchains. When processing a request, they generate an `OracleRequest` — an event containing the data needed for the next steps. These events trigger The Relayers Network activity for cross-data transfer. #### Monitoring OracleRequest Events {% hint style="info" %} Relayer nodes store information about supported blockchain networks and contract addresses in their configuration files. {% endhint %} Each relayer node in the Symbiosis Relayers Network continuously monitors blocks across all supported blockchains, searching for `OracleRequest` events issued by specific contracts. Each `OracleRequest` event includes calldata that contains: * **Destination network information:** The target network ID and the contract address on that blockchain. * **Execution instructions:** Instructions for the Symbiosis Core Contracts on the destination blockchain. #### Processing OracleRequest Events Once an `OracleRequest` event is detected: 1. Each relayer node validates it to ensure authenticity and integrity. 2. The MPC group signs the calldata, ensuring its validity. 3. The signed calldata is promptly transmitted to the appropriate blockchain according to the event details. See Scheme 3 below for an illustration of this process. ![Scheme 3. Data transfer routine.](/files/cCTYHQ1aLjCj5vlAkUbm) 1. The Core Contracts on Blockchain A emits an `OracleRequest` event. 2. Each relayer in the Relayers Network detects and validates the `OracleRequest` event. 3. The leader of the MPC group is the relayer node with the largest stake in the group. 4. The leader verifies that the approved fee specified in the `OracleRequest` event is sufficient by querying Advisor. \ \&#xNAN;*For more details on fees for cross-chain operations, see* [Symbiosis & Fees](/main-concepts/symbiosis-and-fees) 5. TSS Signature Generation: 1. The leader initiates the TSS signature generation for the calldata from the `OracleRequest` event within the MPC group. 2. Each relayer in the MPC group validates the calldata, signs it with its MPC key, and sends the signed data back to the lider. 6. The leader collects the signatures to complete the TSS signature and sends the signed calldata to Broadcaster. 7. Broadcaster fetches the optimal gas price from Advisor. 8. Broadcaster signs a transaction containing the signed calldata and sends the transaction to the destination blockchain. The use of the Hierarchical Threshold Signature Scheme (HTSS) ensures that all members of the Veto group participate in the creation of the TSS signatures. 2/3 of the MPC group is sufficient to create a valid signature. #### **Security & Consensus Mechanism** * The Hierarchical Threshold Signature Scheme (HTSS) ensures that all Veto group members participate in the TSS signature creation. * A valid TSS signature requires approval from at least 2/3 of the MPC group. ### Epoch Change An epoch is a fixed time period during which a selected MPC group handles cross-chain data transfer using a single MPC key. Under normal operation, each epoch lasts 24 hours, and the epoch change process takes less than a minute. **The epoch change triggers:** * Reorganization of the Relayers Network and MPC key generation. * Distribution of rewards for the previous epoch. #### Epoch Change Process

Scheme 4. Four stages of epoch change process.

The process consists of four key stages: 1. Epoch change initialization. 2. Epoch change preparation. This stage includes: 1. Formation of a new MPC group, 2. Generation of a new MPC key, 3. Approval of the epoch change by holders of at least 2/3 of the total stake. 3. Epoch change in the PoS Staking Contracts, including rewards distribution. 4. MPC address update in the Core Contracts on all supported chains. #### 1. Epoch Change Initialization The PoS Staking contracts have a method that solely emits the `PrepareEpochChange` event without modifying the contract’s state. This event acts as a trigger for the epoch transition. An epoch change can be initiated in one of two ways: * **By the Relayers Network**, which collectively signs a transaction to call the method. * **By the Symbiosis team**, manually invoking the method. {% hint style="info" %} Currently, initiating an epoch change is the responsibility of the Symbiosis team. However, in the future, the Relayers Network will transition to a decentralized process for initiating epoch changes. {% endhint %} Each relayer node continuously monitors blockchain blocks, searching for events emitted by the PoS Staking contract. * When the `PrepareEpochChange` event is issued by the PoS Staking contracts, each relayer node detects and validates this event before proceeding with the epoch transition. * Upon confirming a `PrepareEpochChange` event, each relayer determines a new RPC group using a predefined algorithm *(see next section: Epoch Change Preparation).* #### 2. Epoch Change Preparation All active relayer nodes (excluding blocked and offline nodes) participate in the epoch change preparation, which consists of three stages: 1. New MPC group formation 2. New MPC key generation 3. Epoch change approval **2.1.** **New MPC Group Formation** After confirming a `PrepareEpochChange` event, each relayer determines a new MPC group as follows: 1. Fetch a list of **all non-blocked relayer nodes** from the PoS Staking Contracts (includes both online and offline nodes). 2. **Sort the List:** 1. All Veto relayer nodes come first, 2. Remaining relayer nodes are **ordered by stake**, combining PoS Staking and Symbiotic delegated amounts. ⇒ Since every relayer runs the same algorithm on the same data, the output is a consistently ordered list across all relayer nodes. 3. **Select the Base MPC Group:** the top 18 relayer nodes in the ordered list form the base group (15 primary + 3 reserve). 4. **Determines the Group Leader:** the relayer node with the **largest stake** in the base group is selected as the group leader. 5. **Finalize the New MPC Group:** the leader verifies which of the top 15 nodes are online. The first 15 online relayers form the new MPC group.\ \ The maximum MPC group size is 15, but the actual size is defined in the PoS Staking Contracts. Relayer nodes retrieve this value from the PoS Staking Contracts and use it when selecting the new MPC group. **2.2. New MPC Key Generation (by the New MPC Group)** All relayer nodes in the new MPC group participate in generating an **MPC key pair**. As part of the algorithm's execution, each relayer node in the group derives **a segment of the private MPC key.** Upon completion, each relayer node logs the **MPC address**, which is derived from the **public MPC key.** **2.3. Approval of the Epoch Change (by the Relayers Network)** Once the **new MPC key** is generated, the **Relayers Network** must approve the epoch change through the following process: 1. The leader of the new MPC group retrieves the signature base for epoch change from the PoS Staking contracts, signs it with its private key, and broadcasts it to the Relayers Network. 2. Each relayer verifies the leader’s signature and the signature base. If valid, the relayer signs the base with its private key and sends it back to the leader. 3. After collecting all responses, the leader sends the collection to Broadcaster. 4. Broadcaster signs a transaction containing the data received from the leader and sends it to the PoS Host Chain. #### 3. Epoch Change in the PoS Staking Contracts The PoS Staking Contracts allow epoch changes to be executed in two ways: **(1) Automatic Epoch Change by the Relayers Network** The Relayers Network submits a transaction containing the necessary data to change the epoch (see the section above: 2.3. Approval of the Epoch Change (by the Relayers Network). The epoch change is finalized when the following conditions are met: * At least 2/3 of the total stake have signed. * All veto group members have signed. * All new MPC group members have signed. If all conditions are met, the PoS Staking Contracts update the current MPC address, the MPC group, and emit the `EpochChanged` event. **(2) Manual Epoch Change by Symbiosis Administrators** Symbiosis administrators can manually update the epoch using the MPC address and MPC group data prepared by the new MPC group. This manual process may be required in the following cases: * Zero epoch initialization. * Relayers Network failure (e.g., an insufficient number of online relayer nodes to sign the epoch change). Once executed, the PoS Staking Contracts update the current MPC address, the MPC group, and emit the `EpochChanged` event. **3.1. Reward Distribution** Once the epoch is updated in the PoS Staking Contracts, rewards for the previous epoch are distributed among: * Relayer nodes who signed the previous epoch change (*this is omitted if the previous epoch was change manually by the Symbiosis team*). Rewards are added to each eligible relayer node’s stake (the PoS Staking Contracts) and become available for claim after the next epoch change. #### 4. MPC Address Update in Core Contracts The Symbiosis Core Contracts, deployed across all supported blockchains, store an MPC address and only process operations signed by the corresponding MPC key. Relayer nodes track MPC addresses stored in Core Contracts and sign calldata using the appropriate MPC key for each blockchain. To ensure security and functionality, the MPC address stored in Core Contracts must remain in sync with the PoS Staking Contracts. MPC address updates can be performed in two ways: **(1) Automatic Epoch Change by MPC Groups** When the PoS Staking Contracts emit an `EpochChanged` event, it triggers relayer nodes to begin updating MPC addresses across all supported networks. The process follows these steps: 1. The MPC group holding the MPC key corresponding to the Core Contract's stored address is responsible for updating it. 2. The MPC group composes, signs and submits a transaction to update the MPC address. 3. The update is finalized when: * At least 2/3 of the MPC group have signed. * All Veto group members have signed. Once these conditions are met: * The Core Contracts update the current MPC address and emit a `LogChangeMPC` event. * Each relayer node detects this event and updates its locally stored information. **(2) Manual Epoch Change by Symbiosis Administrators** In some cases, Symbiosis administrators may need to manually update the MPC address in Core Contracts on some or all supported blockchains. This manual process may be required when: * The Relayers Network is unable to update the MPC address due to an insufficient number of online nodes in the corresponding MPC group.\ \ For example, if a blockchain has been offline for several days and multiple epochs have passed, the MPC group holding the corresponding key may no longer have quorum to generate a valid TSS signature for the update. Once executed: * The Core Contracts update the current MPC address and emit a `LogChangeMPC` event. * Each relayer node detects this event and updates its locally stored information. ![Scheme 5. MPC address change in the BridgeV2 contract.](/files/zY5QPRezXMG1G8VTq2Wz) 1. The PoS Staking Contracts emit an `EpochChanged` event. 2. Each relayer node in the Relayers Network detects and validates the `EpochChanged` event. 3. The leader in the MPC group is the relayer with the largest stake in the group. 4. TSS Signature Generation: 1. The leader initiates the TSS signature generation for the calldata needed to update the MPC address in the Core Contracts. 2. Each relayer in the MPC group validates the calldata, signs it with its MPC key, and sends the signed data back to the lider. 5. The leader collects the signatures to complete the TSS signature and sends the signed calldata to Broadcaster. 6. Broadcaster signs a transaction containing the signed calldata and sends the transaction to the appropriate blockchain. 7. Once the transaction is mined, the Core Contracts update the MPC address and emit a `LogChangeMPC` event. 8. Each relayer node in the Relayers Network detects and validates the `LogChangeMPC` event and updates its locally stored data for that blockchain. This ensures that each relayer node always knows which MPC key should be used for each blockchain. #### **Security & Consensus Mechanism** * The Hierarchical Threshold Signature Scheme (HTSS) ensures that all Veto group members participate in the TSS signature creation. * A valid TSS signature requires approval from at least 2/3 of the MPC group. # Symbiosis Relayer Node Relayer Node: Introduction, Functions, Keys and Registration. ## Introducing Relayer Node A relayer node is a physical or virtual machine running the Symbiosis relayer software and registered in the Symbiosis PoS Staking Contracts. Only registered nodes are authorized to participate in the operations of the Symbiosis Relayers Network. Relayer nodes are designed to coordinate with one another to execute cross-chain operations and to manage network activity in a decentralized manner. {% hint style="info" %} **Important:** Nodes running the relayer software but not registered or blocked in the PoS Staking Contracts are not considered part of the Relayers Network and cannot participate in relaying operations. {% endhint %} ## Relayer Node Keys Each relayer node operates with two types of cryptographic keys: 1. Relayer node's private key, 2. MPC key fragments. ### 1. Relayer Node’s Private Key Every relayer node has its own unique private key, which is generated during the installation and setup of the relayer software. The corresponding address must be registered in the PoS Staking Contracts, and the key is used for: * Authenticating the relayer node within the Relayers Network. * Signing transactions related to epoch changes. If the private key needs to be regenerated (e.g., due to loss or security issues), the associated address in the Symbiosis PoS Staking Contracts must be updated. Otherwise, the node will no longer be recognized by the network and cannot participate in relaying operations. ### 2. MPC Key Fragments An MPC key (Multi-Party Computation key) is a cryptographic key that is generated and managed collectively by a group of relayer nodes. Instead of a single entity holding the full private key, each relayer node in the group holds only a fragment of the key. Together, the group can produce valid signatures without ever reconstructing the full key. When a relayer node is selected as part of an MPC group for a given epoch, it generates and stores its fragment of the MPC private key. These fragments are used to: * Sign cross-chain calldata during the epoch in which the MPC key is active. * Update the MPC address stored in the Symbiosis Core Contracts when a new epoch begins — but only if the relayer node holds a key fragment corresponding to the current MPC address in the contracts. For more information about the MPC key generation, see [Relayers Network: Architecture and Operations](/relayers-network/symbiosis-relayers-network-architecture-and-operations#epoch-change). ## Relayer Node Registration To participate in the Symbiosis Relayers Network, relayer nodes must be registered in the Symbiosis PoS Staking Contracts. This section outlines what is required for registration, which parameters can be updated later, and which are permanent. **Roles Involved** * A **Relayer Node Runner** is responsible for maintaining the relayer node: keeping it online, updating software, and managing infrastructure. * A **Validator** provides the required **stake** by locking tokens in the **PoS Staking Contracts**. This stake supports the relayer node's operation and contributes to the network’s security. **Note:** Typically, the Node Runner and Validator are the same entity, but this is not a strict requirement. #### Information Required for Registration Registration and staking occur in a **single transaction**. The following parameters must be provided: * **Validator address**\ The address from which the stake is provided. This address is permanent and cannot be changed after registration. To switch validator addresses, a new registration is required. * **Stake Amount**\ Tokens locked as collateral in the PoS Staking Contracts. The amount can be increased or decreased later, but must never fall below the minimum required threshold. * **Relayer Node Address**\ The address corresponding to the relayer node’s private key. If the private key is rotated, the address must be manually updated in the Staking Contracts for the node to remain active in the network. {% hint style="info" %} **Optional:** Validators registered in the PoS Staking Contracts can optionally register as Symbiotic Operators.\ This does not require additional staking but extends the validator’s role within the shared security layer provided by Symbiotic. {% endhint %} **Rewards** Validators receive rewards based on the performance and contributions of the relayer nodes they support. ## Additional Information
Economics and Security: Symbiosis PoS Staking & Symbiotic StakingDiscover how Symbiosis PoS Staking and Symbiotic Staking secure the protocol, incentivize participants, and strengthen network resilience. Learn about the roles of Validators, Delegators, and Symbiotic Operators.
Read more →/pages/ktubJcEpVALdH2Wltww5
Architecture and Operations: Symbiosis Relayers NetworkExplore the technical design of the Symbiosis Relayers Network, including its components, decentralized coordination mechanisms, and the execution of cross-chain operations. Understand how these elements work together to facilitate secure and efficient communication across blockchains.Read more →/pages/zjHksOLesLBfIp156O6K
# Symbiosis Relayers Network: Emergencies Symbiosis Relayers Network: Detection and resolution of operational failures. ## MPC Group Inefficiency
QA
What does it look like?The relayers network stops to proceed oracle requests for all blockchains.
How do we notice it?Alerts
What may be a cause?
  • There are not enough relayers to compose TSS signatures.
  • The leader of the MPC group is offline.
How do we solve this?
  1. Ban offline relayers in the Staking contract,
  2. Initiate epoch change.
## Epoch Change Failure Once epoch change is triggered, the following stages should be completed: 1. Epoch change preparation. This stage includes: 1. Formation of a new MPC group, 2. Generation of a new MPC key, 3. Approval of the epoch change by holders of 2/3 of the total stake. 2. Epoch change in the Staking contract. 3. Epoch change in BridgeV2 contracts. On each stage an emergency can happen. ### **New MPC group formation failure**
QA
What does it look like?Relayers cannot generate a new MPC key.
What may be a cause?
  • Many relayers are offline, and the rest are not enough to form a new MPC group.
  • The leader of the MPC group is offline.
How do we solve this?
  1. Ban offline relayers in the Staking contract,
  2. Set the MPC group size to a smaller value,
  3. Initiate epoch change one more time.
### **Epoch change failure in the Staking contract**
QA
What does it look like?Relayers cannot save a new MPC address in the Staking contract.
What may be a cause?Many relayers are offline, and the rest cannot provide enough signatures for epoch change.
How do we solve this?Save the new MPC address manually.
### **MPC address change failure in the BridgeV2 contract(s)** | Q | A | | ----------------------- | ------------------------------------------------------------------------------------------ | | What does it look like? | The relayers network does not proceed oracle requests for a particular blockchain. | | How do we notice it? | Alerts | | What may be a cause? | There are not enough relayers to compose a proper TSS signature to change the MPC address. | | How do we solve this? | Replace the MPC address with a new one manually. | # Symbiosis Core Smart Contracts Overview Symbiosis Core Smart Contracts: Overview {% hint style="info" %} * If you are curious to see the Symbiosis Protocol in action, check out \ [Symbiosis WebApp](https://app.symbiosis.finance/swap?chainIn=Ethereum\&tokenIn=ETH). * The Symbiosis Core Smart Contracts are open source and available at\ . * For security audits, please refer to [Security Audits](/main-concepts/security-audits). {% endhint %} The Symbiosis Core Smart Contracts implement the on-chain logic for cross-chain operations. These smart contracts are deployed across all blockchain networks supported by Symbiosis and are fine-tuned to handle requests specific to each network. When the smart contracts process a request, they generate events called Oracle requests. These events contain all the necessary data to execute the next steps of cross-chain operations on other chains and are key triggers for the relayers’ activity. The Symbiosis protocol has two slightly different sets of smart contracts: Scheme 1.

Scheme 1. The Symbiosis Core Contracts.

Let's see what each contract does: 1. The **MetaRouterGateway** contract secures the interactions of the MetaRouter contract with users’ ERC20 tokens. Users’ ERC20 tokens should only be approved for this contract. 2. The **MetaRouter** contract manages calls to other Symbiosis contracts on one blockchain within a cross-chain operation. 3. The **Portal** contract locks and unlocks users' stablecoins during cross-chain operations. 4. The **BridgeV2** contract is a proxy between the Symbiosis Relayers Network and the Synthesis/Portal contracts. 5. The **Synthesis** contract mints and burns sTokens during cross-chain operations. 6. A **Symbiosis Octopool** is an AMM liquidity pool containing several types of tokens of the same nominal value. For more information, see [Symbiosis Octopools](/crosschain-liquidity-engine/symbiosis-octopools). 7. The **MulticallRouter** contract manages calls to Symbiosis contracts on on the Symbiosis Host Chain within a cross-chain operation, when the Symbiosis Host Chain isn't the source or destination blockchain of the cross-chain operation. [Symbiosis Routing Contracts](/crosschain-liquidity-engine/symbiosis-routing-contracts) document explains how the Core Smart Contracts interact during cross-chain operations. ## More Information * sTokens (sStable tokens, sWETH, sWBTC, etc.) are explained here: [Symbiosis sTokens and Supported Chains](/main-concepts/wrapped-tokens). * Here is an explanation of how the Symbiosis Protocol handles cross-chain operations [Symbiosis Routing Contracts](/crosschain-liquidity-engine/symbiosis-routing-contracts). # Symbiosis Mint-Burn Process Symbiosis Core Smart Contracts: Portal/Synthesis contracts and mint/burn processes. ## Minting and Burning Introduction {% hint style="info" %} * If you are curious to see the Symbiosis Protocol in action, check out \ [Symbiosis WebApp](https://app.symbiosis.finance/swap?chainIn=Ethereum\&tokenIn=ETH). * The Symbiosis Core Smart Contracts are open source and available at\ . * For security audits, please refer to [Security Audits](/main-concepts/security-audits). {% endhint %} The Symbiosis Protocol mints and burns sTokens during cross-chain operations performed via the Symbiosis Protocol. The Portal and Synthesis contracts are the main smart contracts of the mint-burnt process: * Whenever Portal locks tokens, Synthesis mints the same amount of sTokens (Scheme 1), * Whenever Synthesis burns sTokens, Portal on the corresponding blockchain releases the same amount of tokens (Scheme 2) on the corresponding blockchain. While Symbiosis has the capability to take any token from one blockchain and mint a synthetic counterpart on another, the protocol primarily engages with a select group: namely stablecoins, WETH (Wrapped ETH), and WBTC (Wrapped BTC). {% hint style="info" %} **Transit tokens:** WBTC, WETH and specific stablecoins can be seen as transit tokens in the Symbiosis protocol, since they are used to enable cross-chain operations within the protocol. {% endhint %} More about sTokens can be found in [Symbiosis sTokens and Supported Chains](/main-concepts/wrapped-tokens). Schemes 1 and 2 show minting and burning routines.

Scheme 1. The minting routine of the Symbiosis protocol.

Scheme 2. The burning routine of the Symbiosis protocol.

Steps 1-7 shown in Schemes 1 and 2 are part of every cross-chain operation. Please refer to [Symbiosis Routing Contracts](/crosschain-liquidity-engine/symbiosis-routing-contracts) to see how the Core Smart Contracts interact with each other during cross-chain operations performed via the Symbiosis Protocol. **The Symbiosis Relayers Network:** See [Relayers network](/relayers-network/symbiosis-relayers-network) for more information. ## **No Double Spending** Any cross-chain operation in Symbiosis protocol v2 consists of two or three transactions. If the Symbiosis Host Chain isn't the source or destination blockchain of a cross-chain operation, there will be three transactions: 1. The first transaction (signed and sent by a user) is on the source blockchain, 2. The second transaction (signed and sent by the Relayers Network) is on the Symbiosis Host Chain, and 3. The third transaction (signed and sent by the Relayers Network) is on the destination blockchain. If the Symbiosis Host Chain is the source or destination blockchain of a cross-chain operation, there will be two transactions: 1. The first transaction (signed and sent by a user) is on the source blockchain, and 2. The second transaction (signed and sent by the Relayers Network) is on Symbiosis Host Chain. or 1. The first transaction (signed and sent by a user) is on the Symbiosis Host Chain, and 2. The second transaction (signed and sent by relayers) is on the destination blockchain. Each cross-chain operation has its unique ID that is calculated using the calldata of the cross-chain operation. The Portal and Synthesis contracts check the ID of each processing cross-chain operation and keep records of executed ones. **Example:** Consider the sToken minting operation: Synthesis mints tokens and records the operation within the same transaction: * **If the transaction is completed** and the tokens are minted, then a record of the operation is created. The contract will not mint tokens a second time for the transaction with the same ID. * **If the transaction fails**, no sTokens are minted and no information about the operation is recorded. ## Emergencies Since every cross-chain operation is a sequence of transactions that must be executed one by one on different blockchains, there is always a chance that something may go wrong. For instance, the time set for a cross-chain operation is over or exchanging rates in one of DEXs changes, and the transaction cannot be executed due to non-acceptable slippage change. An emergency means that the transaction on the source blockchain has been processed, but there is no transaction on the destination blockchain, or that transaction is failed. If an emergency occurs, the entire cross-chain operation gets stuck. {% hint style="info" %} For a detailed explanation of how Symbiosis handles such emergencies, please refer to [Symbiosis & Emergencies](/crosschain-liquidity-engine/symbiosis-and-emergencies). {% endhint %} # Symbiosis BridgeV2 Contract Symbiosis core smart contracts: BridgeV2 contract as a proxy between Synthesis/Portal contracts and the Symbiosis realayer network. {% hint style="info" %} * If you are curious to see the Symbiosis Protocol in action, check out \ [Symbiosis WebApp](https://app.symbiosis.finance/swap?chainIn=Ethereum\&tokenIn=ETH). * The Symbiosis Core Smart Contracts are open source and available at\ . * For security audits, please refer to [Security Audits](/main-concepts/security-audits). {% endhint %} In the previous article: [Symbiosis Mint-Burn Process](/crosschain-liquidity-engine/synthesizing-process), we explained the core concept of cross-chain operations: * When the **Portal** locks tokens on one blockchain, **Synthesis** mints tokens on another blockchain. * When **Synthesis** burns tokens on one blockchain, the **Portal** releases tokens on the original blockchain. Now let’s take a closer look at the `BridgeV2` contract. An instance of the `BridgeV2` contract is deployed on each blockchain supported by Symbiosis. It acts as a proxy between the **Rrelayers Network** and the **Portal/Synthesis** contracts. `BridgeV2` accepts calls from two sources: 1. **Portal/Synthesis contracts** deployed on the same blockchain\ When invoked by these contracts, `BridgeV2` emits an **Oracle request** (i.e., a smart contract event) that contains all the necessary data and instructions to carry out the corresponding operation on the destination blockchain. 2. **Relayers Network**\ These are off-chain entities submitting transactions signed with an MPC (multi-party computation) key. The corresponding MPC address is stored in the `BridgeV2` contract. When `BridgeV2` is called via such a transaction, it executes the instructions included in the transaction calldata on-chain. **Scheme 1** below illustrates the `BridgeV2` workflow during cross-chain operations:

Scheme 1. BridgeV2 routine.

{% hint style="info" %} **Relayers Network:** See [Relayers network](/relayers-network/symbiosis-relayers-network) for more details. {% endhint %} # Symbiosis Routing Contracts Symbiosis core smart contracts: MetaRouterGateway, metaRouter, and multicallRouter. {% hint style="info" %} * If you are curious to see the Symbiosis Protocol in action, check out \ [Symbiosis WebApp](https://app.symbiosis.finance/swap?chainIn=Ethereum\&tokenIn=ETH). * The Symbiosis Core Smart Contracts are open source and available at\ . * For security audits, please refer to [Security Audits](/main-concepts/security-audits). {% endhint %} Each cross-chain operation in the Symbiosis protocol consists of multiple intermediate steps executed across different blockchains. Let’s walk through how this works. ## Implemented Cross-Chain Operations The Symbiosis protocol supports the following types of cross-chain operations: 1. Bridging 2. Cross-chain swap 3. Cross-chain zap 4. Interchain messaging ### Bridging Bridging refers to a cross-chain operation in which: 1. **Scenario 1: Minting**\ A user deposits stablecoins or other transit tokens (such as WETH or WBTC) on one blockchain and receives wrapped representations — **sTokens** — on another blockchain (Scheme 1). 2. **Scenario 2: Burning**\ A user burns sTokens on one blockchain and receives the underlying assets (stablecoins, WETH, WBTC, etc.) on another supported chain (Scheme 2)

Scheme 1. Bridging routine that involves minting.

**Important notices for Scheme 1** **Step 2.** The initial transaction includes two separate calldatas: 1. Calldata0: the sequence of steps to be executed on the source blockchain. 2. Calldata1: the sequence of steps to be executed on the Symbiosis Host Chain. Both calldatas may include additional constraints, such as a deadline for completing the cross-chain operation. All of this information is finalized at the time of the initial transaction signing and cannot be changed afterward. By signing the transaction, the user agrees to: all intermediate steps; any specified restrictions; the estimated fees. The user pays the gas fee for executing the transaction on the source blockchain (Polygon in the example). **Steps 3 — 5.** These steps are executed within a single transaction. This ensures atomicity — if any check or step fails, all changes are rolled back. * **Steps 5.** The contract emits an Oracle request containing all the data required to validate, route, and complete the cross-chain operation. **Step 6.** The Relayers Network validates the Oracle request, signs and sends data for the newt chain. Relayers cover the gas fee for this transaction. Later, in Step 8, the user reimburses this expense. For more details about the Symbiosis Relayers Network, see [Relayers network](/relayers-network/symbiosis-relayers-network). **Steps 7 — 9.** These steps are executed within a single transaction. This ensures atomicity — if any check or step fails, all changes are rolled back. * **Step 7.** sTokens are minted at a 1:1 ratio with the tokens locked in Portal (Step 3). * **Step 8.** The amount approved in Step 2 is deducted from the amount of minted tokens (Step 7) to refund the transaction fee paid by the Relayers Network (Step 6). The remaining sTokens are sent to the user's address on the destination blockchain of the bridging operation.

Scheme 2. Bridging routine that involves burning.

**Important notices for Scheme 2** **Step 1.** The initial transaction includes two separate calldatas: 1. `Calldata0`: the sequence of steps to be executed on the source blockchain (the Symbiosis Host Chain). 2. `Calldata1`: the sequence of steps to be executed on the destination blockchain. Both calldatas may include additional constraints, such as a deadline for completing the cross-chain operation. All of this information is finalized at the time of the initial transaction signing and cannot be changed afterward. By signing the transaction, the user agrees to: all intermediate steps; any specified restrictions; the estimated fees. The user pays the gas fee for executing the transaction on the source blockchain. **Steps 2 — 4.** These steps are executed within a single transaction. This ensures atomicity — if any check or step fails, all changes are rolled back. * **Steps 4.** The contract emits an Oracle request containing all the data required to validate, route, and complete the cross-chain operation. **Step 5.** The Relayers Network validates the Oracle request, signs and sends data for the newt chain. Relayers cover the gas fee for this transaction. Later, in Step 7, the user reimburses this expense. For more details about the Symbiosis Relayers Network, see [Relayers network](/relayers-network/symbiosis-relayers-network). **Steps 6 — 8.** These steps are executed within a single transaction. This ensures atomicity — if any check or step fails, all changes are rolled back. * **Step 6.** Tokens are released at a 1:1 ratio to the sTokens burned in Step 2. * **Step 7.** The amount approved in Step 1 is deducted from the amount of released tokens (Step 5) to refund the transaction fee paid by the Relayers Network (Step 5). The remaining tokens are sent to the user's address on the destination blockchain of the bridging operation. ### Cross-chain Swap * **Thansit Tokens**\ To perform cross-chain swaps, the Symbiosis protocol uses transit tokens — highly liquid assets like stablecoins, WETH, and WBTC — available on supported blockchains.\ These tokens are used because their value is uniform across chains, making them ideal for cross-chain routing and minimizing price slippage. * **Multirouting**\ When a swap is requested between two blockchains, Symbiosis checks which transit tokens are available for that pair — this can be one, two, or all three (stablecoins, WETH, WBTC).\ For each available option, the protocol builds a route and then selects the most efficient one — the route that provides the highest output for the user. Scheme 3 shows an example of routing via stablecoins. Routing via WETH or WBTC works the same way.

Scheme 3. Contract interactions during a cross-chain swap: GNS on Polygon for AVAX on Avalanche.

**Important notices for Scheme 3** **Step 1.** * Users approve ERC-20 tokens only for the `MetarouterGateway` contract. Approving tokens for any other contract may result in loss of funds. * If the source token is the native currency of the source blockchain, this step is skipped. **Step 2.** The initial transaction includes three separate calldatas: 1. `Calldata0`: the sequence of steps to be performed on the source blockchain. 2. `Calldata1`: the sequence of steps on the Symbiosis Host Chain. This calldata includes the estimated gas fee for the transaction execution on the Symbiosis Host Chain in the stablecoin equivalent: `GasEstimatedUSD1` in Scheme 3. If routing is via another transit token, the fee will be denominated in that transit token. 3. `Calldata2`: the sequence of steps to be performed on the destination blockchain. This calldata includes the estimated gas fee for the transaction execution on the destination blockchain in the stablecoin equivalent: `GasEstimatedUSD2` in Scheme 3. If routing is via another transit token, the fee will be denominated in that transit token. The calldatas may include additional constraints, such as a deadline for completing the cross-chain operation. All of this information is finalized at the time of the initial transaction signing and cannot be changed afterward. By signing the transaction, the user agrees to: all intermediate steps; any specified restrictions; the estimated fees. The user pays the gas fee for executing the transaction on the source blockchain. **Steps 3 — 7.** These steps are executed within a single transaction. This ensures atomicity — if any check or step fails, all changes are rolled back. * **Step 4.** In this example, USDC is used as the transit token on Polygon. If the input token is not USDC, it is exchanged for USDC via a third-party DEX (or multiple DEXs) selected during the transaction composition (Step 2). * **Steps 5 and 15.** The contract emits an Oracle request containing all the data required to validate, route, and complete the cross-chain operation. **Steps 8 and 16.** Relayers validate the Oracle request, sign and send the data to the appropriate blockchain. They cover the gas fees for these transactions. Users reimburse these fees later (Step 14 and Step 18). For more details about the Symbiosis Relayers Network, see [Relayers network](/relayers-network/symbiosis-relayers-network). **Step 9.** sTokens are minted at a 1:1 ratio to the tokens locked in Portal (Step 5). **Step 10.** The amount approved in Step 2 is deducted from the amount of minted tokens (Step 9) to refund the transaction fee paid by the Relayers (Step 8). The remaining tokens continue to participate in the intermediate steps of the cross-chain swap. **Step 12.** sTokens backed by assets on the source chain are exchanged for sTokens backed by assets on the destination chain via the Octopool. This swap enables further bridging into the destination chain. **This is the step where the logical cross-chain transition takes place.** **Step 13.** Synthesis burns the sTokens for the destination chain. **Steps 9 — 15.** These steps are executed within a single transaction. This ensures atomicity — if any check or step fails, all changes are rolled back. **Steps 17 — 20.** These steps are executed within a single transaction. This ensures atomicity — if any check or step fails, all changes are rolled back. * **Step 17.** Tokens are released at a 1:1 ratio to the sTokens burned by Synthesis (Step 13). * **Step 18.** The gas fee approved in Step 2 is deducted from the released amount to reimburse the Relayers (Step 8). The remaining tokens proceed through the intermediate swap steps. * **Step 20.** Once the last intermediate swap is completed, the tokens are sent to the user's address on the destination blockchain of the cross-chain operation. {% hint style="info" %} In some cases Step 20 may be skipped. In this case, transit tokens will be sent to the user's address. Please see the [#guaranteed-transit-tokens](#guaranteed-transit-tokens "mention")section for details. {% endhint %} #### Guaranteed Transit Tokens Each cross-chain swap has a **slippage tolerance** defined in **Step 2**. This value is distributed across all transactions that make up the swap, ensuring that each segment of the operation stays within its allocated share of the total slippage. This mechanism guarantees that the cumulative price impact does not exceed the overall slippage threshold. 1. If the transaction on the first (source) network surpasses the accepted price change, then the swap is not initiated and the assets remain in the user's wallet. 2. If the transaction on Symbiosis Host Chain surpasses the accepted price change, then the cross-chain swap is halted. Please see [Symbiosis & Emergencies](/crosschain-liquidity-engine/symbiosis-and-emergencies) for more details. 3. If the transaction on the destination blockchain exceeds the slippage tolerance, Step 20 is skipped, and the user receives the transit token instead of the final token. ### Cross-chain Zap Cross-chain zapping has been implemented to facilitate liquidity supplying to Symbiosis Octopools located on the Symbiosis Host Chain. Having any assets on any (supported) blockchain, liquidity providers can supply the assets to this pool via cross-chain zapping (Scheme 4).

Scheme 4. Contract interactions during a cross-chain zap: GNS on Polygon to a Symbiosis Octopool.

**Important notices for Scheme 4** **Step 1.** * Users approve ERC-20 tokens only for the `MetarouterGateway` contract. Approving tokens for any other contract may result in loss of funds. * If the source token is the native currency of the source blockchain, this step is skipped. **Step 2.** The initial transaction includes two separate calldatas: 1. `Calldata0`: the sequence of steps to be performed on the source blockchain. 2. `Calldata1`: the sequence of steps on the Symbiosis Host Chain. This calldata includes the estimated gas fee for the transaction execution on the Symbiosis Host Chain in the stablecoin equivalent: `GasEstimatedUSD1` in Scheme 4. If routing is via another transit token, the fee will be denominated in that transit token. The calldatas may include additional constraints, such as a deadline for completing the cross-chain operation. All of this information is finalized at the time of the initial transaction signing and cannot be changed afterward. By signing the transaction, the user agrees to: all intermediate steps; any specified restrictions; the estimated fees. The user pays the gas fee for executing the transaction on the source blockchain. **Steps 3 — 7.** These steps are executed within a single transaction. This ensures atomicity — if any check or step fails, all changes are rolled back. * **Steps 7.** The Oracle request contains all the information needed to verify and route the cross-chain operation. **Step 8.** Relayers validate the Oracle request, sign and send the data to the appropriate blockchain. For more details about the Symbiosis Relayers Network, see [Relayers network](/relayers-network/symbiosis-relayers-network). **Steps 9 — 11.** These steps are executed within a single transaction. This ensures atomicity — if any check or step fails, all changes are rolled back. * **Step 9.** sTokens are minted at a 1:1 ratio to the tokens locked in Portal (Step 3). * **Step 10.** The amount approved in Step 2 is deducted from the amount of minted tokens (Step 9) to refund the transaction fee paid by the Relayers (Step 8). * **Step 11.** Tokens are added to the liquidity pool, and the LP tokens are sent to the user's address on the blockchain. ### Interchain Communication The interchain communication routine closely follows the structure of a cross-chain swap (see Scheme 3), with one key difference: an additional step is included on the destination blockchain — depositing assets into a third-party protocol, and transferring LP tokens (or other protocol-issued proofs) to the user's address. Scheme 5 shows an example of a cross-chain swap followed by depositing tokens into the BENQI protocol. Routing in this example is performed via stablecoins; routing via WETH or WBTC works in the same way.

Scheme 5. Contract interactions during interchain communication: swapping GNS on Polygon for DAI on Avalanche and adding to BENQI on Avalanche.

**Important notices for Scheme 5** **Steps 1 — 18.** These steps follow the standard **cross-chain swap** flow. **Steps 19 — 21.** In some cases, Steps 20 and 21 may be skipped. When this happens, transit tokens are sent directly to the user's address on the destination blockchain instead of performing the final swap and depositing assets into a third-party protocol. Please see the section below for more details. #### Guaranteed Transit Tokens Each cross-chain swap has a **slippage tolerance** defined in **Step 2**. This value is distributed across all transactions that make up the swap, ensuring that each segment of the operation stays within its allocated share of the total slippage. This mechanism guarantees that the cumulative price impact does not exceed the overall slippage threshold. 1. If the transaction on the first (source) network surpasses the accepted price change, then the swap is not initiated and the assets remain in the user's wallet. 2. If the transaction on Symbiosis Host Chain surpasses the accepted price change, then the cross-chain swap is halted. Please see [Symbiosis & Emergencies](/crosschain-liquidity-engine/symbiosis-and-emergencies) for more details. 3. If the transaction on the destination blockchain exceeds the slippage tolerance, Step 20 and 21 are skipped, and the user receives the transit token on the destination chain. # Symbiosis & Emergencies ## Failed Cross-chain Operations A cross-chain swap consists of several transactions executed on different blockchains (Scheme 1): * **TXN0** — on the source chain (e.g., Polygon) * **TXN1** — on the Symbiosis Host Chain * **TXN2** — on the destination chain (e.g., Avalanche)

Scheme 1. A cross-chain swap of GNS on Polygon for AVAX on Avalanche.

Since these transactions depend on each other and happen across different chains, there’s always a chance something might go wrong.\ For example: * The operation timeout may expire * The price on a DEX may change too much, causing the transaction to exceed the allowed slippage * A network error may occur When this happens, it’s called an **emergency** — the cross-chain operation was started, but couldn't be completed. Usually this means that TXN0 (on the source chain) was successful, but the transaction on the intermediate — the Host Chain (TXN1) or the destination chain (TXN2) either failed or never happened. ## Revert Introduction If a cross-chain operation cannot be completed, it is reverted. How does reverting work? * **After February 9, 2025:**\ Cross-chain swaps labeled "Stuck" are automatically reverted within one hour. * **Before February 8, 2025:**\ Users need to manually revert the swap using Symbiosis WebApp. ### General Notes #### **Who Can Revert** The revert transaction must be sent **from the same address** used in the original operation — or, in special cases, from a specifically designated address stored in the transaction data. #### **Important** * Portal and Synthesis contracts keep records and states of cross-chain operations and revert requests that go through the smart contracts. A specific state is set for each record to eliminate double spending. * Each reverting operation is a cross-chain operation, so it can also get stuck. * All steps within a blockchain are performed in a single transaction. #### Revert Result: Address, Token Type and Chain When a cross-chain operation is reverted, the user receives tokens back the source address on the source blockchain — the one where the original operation began. Reverts always follow the **same transit token type** used in the original route: * If the initial swap used **stablecoins**, the revert will also use stablecoins * If it used **WETH**, the revert will use WETH * If it used **WBTC**, the revert will use WBTC > For example, if USDC was the transit token on **Polygon**, the user will receive **USDC on Polygon**, even if they originally sent another token (see Scheme 1). ## Cross-chain Operation Structure: TXN0 (Chain1) → TXN1 (Host Chain) → TXN2 (Chain2) A standard cross-chain operation includes three transactions: * **TXN0** — on the **source chain** (Chain1) * **TXN1** — on the Symbiosis Host Chain * **TXN2** — on the destination chain (Chain2) Two failure scenarios are possible: * **Emergency Case 1:** TXN0 **X** TXN1 -> TXN2 * TXN0 (on Chain1) was successful * TXN1 (on Host Chain) failed * TXN2 (on Chain2) did not happen * **Emergency Case 2:** TXN0 -> TXN1 **X** TXN2 * TXN0 and TXN1 were successful * TXN2 failed ### Emergency **Case 1:** TXN0 X TXN1 -> TXN2 **Conditions** * The user’s tokens were **locked in Portal** on Chain1 (Polygon in our example). * These tokens can only be **unlocked** if **Synthesis** on the Symbiosis Host Chain sends a valid revert request. **Challenge** The straightforward way to revert would be to send a transaction directly to the Host Chain.\ However, this creates friction for the user: * They may not know the Host Chain exists * They likely don’t hold its native token to pay gas fees * They probably don’t want to deal with it at all **UX-Friendly Solution** To solve this, Symbiosis introduced a flow that lets users initiate the revert **entirely from Chain1**, without having to interact with the Host Chain directly. **Reverting Workflow (Scheme 2)** `portal.metaRevertRequest()` on Chain1 ->\ `synthesis.revertSynthesizeRequestByBridge()` on the Host Chain ->\ `portal.revertSynthesize()` back on Chain1 > If this process fails (e.g., due to timing or gas issues), the user may need to send another revert transaction on **Chain1**.

Scheme 2. Revert scheme for Emergency Case 1.

**Important notes for Scheme 2 (Case 1)** **Step 1.** The user signs a transaction that includes: 1. `Calldata0`: the sequence of steps to be executed on Polygon. 2. `Calldata1`: the sequence of steps to be executed on the Symbiosis Host Chain. This includes an estimated gas fee value for Polygon:`GasEstimatedUSD` This is the only case where the user does not reimburse gas fees on the Symbiosis Host Chain. **Step 2.** Calling `portal.metaRevertRequest()` **Step 6.** Only the BridgeV2 contract is allowed to call `synthesis.revertSynthesizeRequestByBridge()`. **Step 8.** The emitted Oracle request includes a call to `portal.revertSynthesize()`on Polygon. It also includes the gas fee value:`GasEstimatedUSD` for Polygon, as approved in Step 1. **Step 10.** Only the BridgeV2 is allowed to call `portal.revertSynthesize()` **Step 11.** From the amount being released: * The gas fee approved in Step 1 is deducted to reimburse the relayers (who paid for the transaction in Step 9) * The remaining tokens are transferred to the user's wallet on Polygon. **If it fails, another transaction should be sent Chain1 with revert instructions (Step 1).** ### Emergency **Case 2:** TXN0 -> TXN1 X TXN2 **Conditions and restrictions** * The user’s tokens were **locked in Portal** on Chain1 (Polygon in our example). * These tokens can only be **unlocked** if **Synthesis** on the Symbiosis Host Chain sends a valid revert request. In its turn, **Synthesis** will only send such a request if it receives instructions from the **Portal**, which is located on Chain2 (Avalanche in our example). **Reverting Workflow (Scheme 3)** `portal.metaRevertRequest()` on Chain2 -> \ `synthesis.revertMetaBurn()` on the Host Chain -> \ `synthesis.metaBurnSyntheticToken()` on the Host Chain -> \ `portal.metaUnsynthesize()` on Chain1 **If the reverting operation fails between Chain2 (Avalanche in our example) and the Host Chain, another transaction should be sent to Chain2 with revert instructions (Step 1).** **If the reverting operation fails between the Host Chain and Chain1 (Polygon in our example), see the subcase.**

Scheme 3. Revert scheme for Emergency Case 2.

**Important notes for Scheme 3 (Case 2)** **Step 1.** The user signs a transaction that includes: 1. `Calldata0`: the sequence of steps to be executed on Avalanche. 2. `Calldata1`: the sequence of steps to be executed on the Host Chain. This calldata includes the estimated gas fee for the transaction execution on the Host Chain in the stablecoin equivalent: `GasEstimatedUSD1` in Scheme 3. 3. `Calldata2`: the sequence of steps to be executed on the destination blockchain. This calldata includes the estimated gas fee for the transaction execution on the destination blockchain: `GasEstimatedUSD2`. The transaction is sent to Chain2 (Avalanche in our example). **Step 2.** Calling `p``ortal.metaRevertRequest()` **Step 6.** Only BridgeV2 is allowed to call `synthesis.revertMetaBurn()` **Step 7.** The amount approved in Step 1 is deducted from the amount of minted tokens (Step 6) to refund the transaction fee paid by the relayers (Step 5). The remaining stablecoins continue to participate in the intermediate steps of the reverting operation. **Step 12.** The Oracle request contains a call to `portal.revertSynthesize()`on Polygon. The parameters include the estimated gas fee value for Polygon:`GasEstimatedUSD2` **Step 14.** Only BridgeV2 is allowed to call `portal.metaUnsynthesize()`. Stablecoins are released at a 1:1 ratio to the sTokens burned by Synthesis (Step 10). **Step 15.** The amount approved in Step 1 is deducted from the amount of released tokens (Step 14) to refund the transaction fee paid by the relayers (Step 13). The remaining tokens are deposited to the user’s address on Polygon. **If the reverting operation fails between Chain2 (Avalanche in our example) and S-chain, another transaction should be sent to Chain2 with revert instructions (Step 1).** **If the reverting operation fails between the Host Chain and Chain1 (Polygon in our example), see the subcase.** ### Emergency Case 3: Subcase of Emergency Case 2 **Conditions and restrictions** * There was an attempt to revert a cross-chain operation (Case 2). That reverting operation was stuck on the Host Chain. * The user’s tokens are still locked in Portal on Chain1 (Polygon in our example) * Portal will only release the tokens if it receives a request from Synthesis, which is located on the Host Chain. Synthesis will only send such a request if it receives instructions from the Portal, which is located on Chain2 (Avalanche in our example). **Reverting Workflow (Scheme 4)** `portal.metaRevertRequest()` on Chain2 -> \ `synthesis.revertBurnAndBurn()` on the Host Chain -> \ `portal.unsynthesize()` on Chain1 **If it fails, another transaction should be sent to Chain2 with revert instructions.**

Scheme 4. Completing revert for Emergency Case 3.

**Important notes for Scheme 4 (Case 3)** **Step 1.** The user signs a transaction that includes: 1. `Calldata0`: the sequence of steps to be executed on Avalanche. 2. `Calldata1`: the sequence of steps to be executed on the Host Chain. This calldata includes the estimated gas fee for the transaction execution on the Host Chain: `GasEstimatedUSD1` . 3. `Calldata2`: the sequence of steps to do on the destination blockchain. This calldata includes the estimated gas fee for the transaction execution on the destination blockchain : `GasEstimatedUSD2` . **Step2.** Calling `portal.metaRevertRequest()` **Step 6.** Only BridgeV2 is allowed to call `synthesis.revertBurnAndBurn()`. **Step 7.** Synthesis mints the number of sTokens equaling to `GasEstimatedUSD1` approver in Step 1. **Step 9.** The Oracle request contains a call to `portal.unsynthesize()`on Polygon. The parameters include the estimated gas fee value for Polygon:`GasEstimatedUSD2` **Step 11.** Only BridgeV2 is allowed to call `portal.unsynthesize()`. **Step 12.** The amount approved in Step 1 is deducted from the amount of released tokens (Step 11) to refund the transaction fee paid by the relayers (Step 10). The remaining tokens are deposited to the user’s address on Polygon. **If it fails, the user should send another transaction to Chain2 with revert instructions (Step 1).** ## Cross-chain Operation: TXN0 (Chain1) → TXN1 (Host Chain) If the Host Chain is the destination chain of a cross-chain operation (Cheme 5), then there are two transactions: * **TXN0** — on the **source chain** (Chain1) * **TXN1** — on the Symbiosis Host Chain One failure scenario is possible: * **Emergency Case 4:** TXN0 **X** TXN1 * TXN0 completed successfully, * TXN1 failed. ![Scheme 5. A cross-chain swap of GNS on Polygon for tokens on the Host Chain.](/files/XD5FKvnzndeCvaKEsleH) ### Emergency **Case 4:** TXN0 (Chain1) X TXN1 (S-chain) **Conditions and restrictions** * The user’s tokens are locked in Portal on Chain1 (Polygon in our example). * Portal will only release the tokens if it receives a request from Synthesis, which is located on the Host Chain. **Reverting Workflow (Scheme 6)** `synthesis.revertSynthesizeRequest()` on the Host Chain -> \ `portal.revertSynthesize()` on Chain1 **If it fails, another transaction should be sent to Host Chain with revert instructions.**

Scheme 6. Revert scheme for Emergency Case 4.

**Important notes for Scheme 6** **Step 1.** The user signs a transaction that includes: 1. `Calldata0`: the sequence of steps to be executed on the Host Chain. 2. `Calldata1`: the sequence of steps to be executed on Chain1 (Polygon in our example). This calldata includes the estimated gas fee for the transaction execution on Chain1: `GasEstimatedUSD1`. **Step2.** Calling `synthesis.revertSynthesizeRequest()`. **Step 6.** Only BridgeV2 is allowed to call `portal.revertSynthesize()`. **Step 7.** The amount approved in Step 1 is deducted from the amount of released tokens (Step 6) to refund the transaction fee paid by the relayers (Step 5). The remaining tokens are deposited to the user’s address on Polygon. **If it fails, another transaction should be sent to the Host Chain with revert instructions (Step 1).** ## Cross-chain Operation: TXN0 (Host Chain) → TXN1 (Chain2) If the Host Chain is the source chain of a cross-chain operation (Cheme 7), then there are two transactions: * **TXN0** — on the source chain (the Host Chain) * **TXN1** — on the destination chain (Chain2) One failure scenario is possible: * **Emergency Case 5:** TXN0 **X** TXN1 * TXN0 completed successfully, * TXN1 failed. ![Scheme 7. A cross-chain swap of USDT on the Host Chain for AVAX on Avalanche.](/files/5LnW7heJIM1vMfNWgzqR) ### Emergency **Case 5:** TXN0 (Host Chain) X TXN1 (Chain2) **Conditions and restrictions** * The user’s tokens were exchanged for sTokens and burn on the Host Chain. * Synthesis will only mint new sTokens if it receives a request from Portal, which is located on Chain2. **Reverting Workflow (Scheme 7)** `portal.revertBurnRequest()` on Chain2 -> \ `synthesis.revertBurn()` on the Host Chain **If it fails, another transaction should be sent to Chain2 with revert instructions.**

Scheme 7. Revert scheme for Emergency Case 5.

**Important notes for Scheme 7** **Step 1.** The user signs a transaction that includes: 1. `Calldata0`: the sequence of steps to be executed on Avalanche. 2. `Calldata1`: the sequence of steps to be executed on the Host Chain. This calldata includes the estimated gas fee for the transaction execution on the Host Chain. The transaction is sent to Chain2 (Avalanche in our example). **Step 2.** Calling `portal.revertBurnRequest()` **Step 6.** Only BridgeV2 is allowed to call `synthesis.revertBurn()` **Step 7.** The amount approved in Step 1 is deducted from the amount of minted tokens (Step 6) to refund the transaction fee paid by the relayers (Step 5). The remaining tokens continue to participate in the intermediate steps of the reverting operation. **If it fails, another transaction should be sent to Chain2 with revert instructions (Step 1).** # Symbiosis Octopools Symbiosis Octopool is an AMM liquidity pool that facilitates cross-chain operations. ## Introducing Octopool {% hint style="info" %} For security audits, please refer to [Security Audits](/main-concepts/security-audits). {% endhint %} A Symbiosis Octopool is an AMM liquidity pool containing several types of tokens of the same nominal value. The pool design allows for: 1. **No Token-Pair Constraints**: Any token can be exchanged for another within the pool without being limited to specific token pairs. 2. **Single-Sided Liquidity Provision/Withdrawal**: Liquidity can be added or removed from the pool with a single type of token, instead of needing to supply or withdraw a pair of tokens. 3. **Addition of New Tokens**: New tokens can be added to the existing pool, provided they are of the same nominal value as the tokens already in the pool. The design of the Symbiosis Octopool ensures that token exchanges within the pool are executed efficiently, maximizing the use of the pooled capital. The Symbiosis protocol uses Octopools to facilitate cross-chain operations. ## Tokens in Octopools {% hint style="info" %} **sToken:** sToken is a type of a wrapped token used within the Symbiosis protocol to perform cross-chain operations. For more information about sTokens, please refer to [Symbiosis sTokens and Supported Chains](/main-concepts/wrapped-tokens) {% endhint %} Symbiosis operates several Octopools, all of them are located on the Symbiosis Host Chain. Each Octopool contains several types of sTokens of the same nominal value bridged from supported blockchain networks: 1. **Stablecoins:** Octopool with synthesized stablecoins or sStables, containing sUSDC, sUSDT, sUSDC.e, sRUSDT, sUSDbC, sUSDt. 2. **WETH:** Octopool with synthesized WETH tokens or sWETH. 3. **WBTC:** Octopool with synthesized wBTC tokens or sWBTC, containing sWBTC, sWRBTC, sBTCB, sCOREBTC 4. **SIS:** Octopool with synthesized SIS tokens or sSIS 5. **LADYS:** Octopool with synthesized LADYS tokens or sLADYS Octopools 1, 2, and 3 are used to exchange any tokens between supported chains. Octopools 4 and 5 are used to exchange SIS and LADYS tokens only between chains where the tokens are bridged. All sTokens are minted 1:1 to corresponding tokens on corresponding chains and added to Octopools with corresponding sTokens: sStables, sWETH, sWBTC, etc. ## Octopools for General Routing Octopools with sStables, sWETH and sWBTC are used for general routing: to exchange any tokens between supported chains. Let's see how it works.

Scheme 1. Types of sTokens in the Symbiosis Octopools.

**Cross-Chain Token Swaps via Octopools** Symbiosis always routes cross-chain swaps through an Octopool. For instance, moving from Chain 2 to Chain 1 or Chain 3 can be achieved by using USDC/USDT and the sStables Octopool. Similarly, swaps from Chain 2 to Chain 3 can utilize WETH tokens and the Octopool with sWETH tokens. **Multiple Routes** When multiple routes are available for a given blockchain network pair, the optimal route is selected. For example, moving from Chain 2 to Chain 3 can be done using either stablecoins or WETH. The optimal route is a sequence of swaps that results in the maximum number of tokens received on the destination network for a given blockchain network pair and token pair. **No Direct Route** If there is no common Octopool for a given blockchain network pair, it indicates that direct token cross-chain operations are not supported. For example, moving from Chain 1 to Chain N is not possible, since Chain 1 only supports USDC and Chain N lacks stablecoins used for cross-chain token exchanges within the Symbiosis protocol. Users can still perform the swap between the chains in two steps: first, they can move from Chain 1 to Chain 2 using the sStables Octopool, and then from Chain 2 to Chain N using either the sWETH or sWBTC Octopool. Symbiosis does not support such complex cross-chain operations within a single transaction. **Third-Party Liquidity Pools** Symbiosis only owns and supports Octopools. If either the source or destination token of a cross-chain operation differs from the tokens used by Symbiosis, the tokens will be swapped in third-party liquidity pools via decentralized exchange (DEX) aggregators. Please refer to [Symbiosis Routing Contracts](/crosschain-liquidity-engine/symbiosis-routing-contracts) for a comprehensive explanation on how Symbiosis handles cross-chain operations. ## Octopools with Specific Tokens There are several Octopools that contain specific, not well-distributed, and commonly used tokens such as sSIS, sLADYS, etc. Let's examine the purpose of such Octopools using the example of the SIS token, the governance token of the Symbiosis protocol. SIS tokens were minted on Ethereum and then some SIS tokens have been bridged to five other blockchain networks (see Scheme 2 below).

Scheme 2. SIS token on different blockchain networks.

When a token has been bridged across multiple blockchain networks, direct transfers between any two of these networks are not possible without going to the original blockchain first. The Octopool with sSIS tokens is used to enable cross-chain operations for the SIS token for any blockchain network pair where the SIS token is present.

Scheme 3. Octopool with sSIS tokens.

If the source and destination tokens of a swap are SIS tokens, the Octopool with sSIS is used to perform the operation. This optimizes transaction fees and exchange rates for cross-chain operations that evolve SIS tokens. ## Symbiosis Octopool Token Details sToken is ERC20 standard. The pool LP token is ERC1155 standard. Decimal values are in the 18th digit. # Symbiosis Developer Tools Symbiosis Developer Tools include Symbiosis JS SDK, and Symbiosis API. ## Overview Symbiosis Developer Tools provide resources for integrating swaps and other supported operations with the Symbiosis protocol. The main integration method is the **Symbiosis API**. {% hint style="info" %} The Symbiosis JS SDK is deprecated. Existing integrations that still use the SDK should migrate to the Symbiosis API. {% endhint %} ## Available Features The Symbiosis API provides access to supported cross-chain and on-chain operations: 1. Swaps across 50+ supported chains, including Ethereum, Tron, Solana, Bitcoin, and other networks. * **Cross-chain swaps:** Swap supported tokens across supported blockchain networks. * **On-chain swaps:** Swap supported token pairs on a supported network. 2. **Interchain communication** Transfer tokens to third-party protocols. 3. **Cross-chain zapping** Zap supported tokens into a Symbiosis-managed liquidity pool. 4. **Bridging** Mint or burn protocol tokens used for transfers between supported chains and the Symbiosis Host Chain. This feature is mainly used for tokens that support Symbiosis cross-chain swap infrastructure. It is not a general-purpose bridge for any token to any chain. For more details, see [Symbiosis sTokens and Supported Chains](/main-concepts/wrapped-tokens). If a custom token needs to be bridged, it requires additional review and setup on the Symbiosis side. This is handled separately from the standard API integration flow. 5. **Cross-chain operation status tracking** Retrieve transaction status updates. **Note:** “Supported tokens” and “supported token pairs” refer to tokens that can be exchanged through available Symbiosis routes and supported liquidity sources. ## Related Links * [Symbiosis API](/developer-tools/symbiosis-api) * [Symbiosis Core Smart Contracts Overview](/crosschain-liquidity-engine/symbiosis-core-smart-contracts-overview) * [Security Audits](/main-concepts/security-audits) * Cross-chain swap concepts: [Symbiosis: Cross-Chain Swaps](/main-concepts/symbiosis-cross-chain-swaps) # Symbiosis API Symbiosis API | Symbiosis Finance | Swagger ## What is the Symbiosis API? The Symbiosis API allows you to integrate the core functionalities of the Symbiosis Protocol into your application, platform, or protocol. It provides decentralized cross-chain swaps and liquidity management, enabling users to interact with multiple blockchain networks without intermediaries.
Symbiosis Protocol Features Available via the API The Symbiosis API provides access to supported cross-chain and on-chain operations: 1. Swaps across 50+ supported chains, including Ethereum, Tron, Solana, Bitcoin, and other networks. * **Cross-chain swaps:** Swap supported tokens across supported blockchain networks. * **On-chain swaps:** Swap supported token pairs on a supported network. 2. **Interchain communication** Transfer tokens to third-party protocols. 3. **Cross-chain zapping** Zap supported tokens into a Symbiosis-managed liquidity pool. 4. **Bridging** Mint or burn protocol tokens used for transfers between supported chains and the Symbiosis Host Chain. This feature is mainly used for tokens that support Symbiosis cross-chain swap infrastructure. It is not a general-purpose bridge for any token to any chain. For more details, see [Symbiosis sTokens and Supported Chains](/main-concepts/wrapped-tokens). If a custom token needs to be bridged, it requires additional review and setup on the Symbiosis side. This is handled separately from the standard API integration flow. 5. **Cross-chain operation status tracking** Retrieve transaction status updates. **Note:** “Supported tokens” and “supported token pairs” refer to tokens that can be exchanged through available Symbiosis routes and supported liquidity sources.
## Checklist Before Going to Production (Mainnet) {% hint style="danger" %} **Warning:** If any of these checks fail, you put the assets of your users at risk. Therefore, you must not go to Mainnet with real assets and real users. This could result in the loss of your users' assets. 1. **Approval of ERC20 Tokens:** Always approve users' ERC20 tokens for only one contract — the `metaRouterGateway` — on each blockchain. Verify the contract addresses for all supported blockchains in [this configuration](https://github.com/symbiosis-finance/js-sdk/blob/main/src/crosschain/config/mainnet.ts). 2. **Contract Existence and Address Validation**: Ensure that the contracts used in your integration are deployed on the respective blockchains, and that their addresses on each blockchain match those listed in [this configuration](https://github.com/symbiosis-finance/js-sdk/blob/main/src/crosschain/config/mainnet.ts). 3. **Handling of Calldata:** Do not modify, reuse, or cache calldata retrieved from Symbiosis SDKs or API methods. 4. **Testing:** After deployment to Mainnet, conduct at least one cross-chain operation to ensure proper functionality. **Reminder:** Perform this checklist during the initial deployment and after every software update. {% endhint %} ## Swap Workflow Using the Symbiosis API {% hint style="info" %} `partnerId` is a custom identifier string used to associate swaps or other operations with a specific partner integration within the Symbiosis Protocol. The value is defined by the integrator — they can choose any string. It is recommended to use a fixed and consistent value across all operations performed under one integration, so that all related transactions can be tracked and attributed correctly. {% endhint %} #### V1 or V2 Endpoint Set * **V2 endpoint set:** Extended cross-chain swap endpoints with support for any-to-any routing and Bitcoin swap routes. Recommended for integrations. * **V1 endpoint set:** Original cross-chain swap endpoints. Planned for gradual deprecation. #### A General Workflow for Performing a Swap Using the Symbiosis API 1. Get a list of supported blockchain networks using `/v1/chains` 2. Check swap limits (allowed swap amounts) using `/v1/swap-limits` 3. Get the calldata (payload) 1. **For BTC -> Any**, use `/v2/quote` to receive a quote and `/v2/swap` to obtain a BTC deposit address and a fresh quote. 2. **For Any -> Any (except BTC -> Any)**, use `/v2/quote` 4. If the source token is not a native gas token (for example, an ERC-20 token on an EVM chain), approve the smart contract to spend the user's tokens.\ **Important:** Always approve users' ERC20 tokens for only one contract — the `metaRouterGateway` — on each blockchain. Verify the contract addresses for all supported blockchains in [this configuration](https://github.com/symbiosis-finance/js-sdk/blob/main/src/crosschain/config/mainnet.ts). 5. Sign and send transaction to trigger a cross-chain swap\ Since network conditions constantly change, calldata must be regenerated periodically (e.g., every 30 seconds) to ensure it remains valid before execution. 1. **For BTC -> Any**, send the quoted amount to the BTC address generated in Step 3.a. This will triggers the cross-chain swap. 2. **For Any -> Any (except BTC -> Any)**, sign the calldata obtained in Step 3.b using the wallet, then submit the transaction to the source blockchain. 6. Monitor the progress of the swap using `/v2/tx/{chainID}/{txHash}` \ This endpoint provides real-time status updates for cross-chain operations. **Swap workflow:** * **Any to Any:** [Symbiosis: Cross-Chain Swaps](/main-concepts/symbiosis-cross-chain-swaps) * **BTC to Any:** [Symbiosis: To/From BTC](/main-concepts/symbiosis-cross-chain-swaps/symbiosis-to-from-btc) #### Handling Transactions & Approvals Smart contract approvals, as well as transaction signing and submission, are performed through the user's wallet (for example, MetaMask, WalletConnect, or Coinbase Wallet) via wallet APIs. These actions are not handled directly by the Symbiosis API and must be initiated by the application through wallet interactions. #### Checking API Health & Swap Time An application can perform health checks periodically or before each swap using `/health-check`. The frequency depends on the app's load and expected behavior. To get an approximate swap duration, use the swap time estimation endpoint `/v1/swap-durations`. The estimated swap time is based on historical data and a real swap time may vary due to changing network conditions. #### Examples * **Symbiosis WebApp**\ The [Symbiosis WebApp](https://app.symbiosis.finance/swap) uses the Symbiosis API for interacting with the Symbiosis Protocol and serves as a reference for supported protocol functionalities. * **Swagger**\ The [Swagger documentation](https://api.symbiosis.finance/crosschain/docs/) of the Symbiosis API provides examples for every endpoint. Simply scroll to the endpoint of interest, input the required data, or use preset values, and execute the example. ## Swagger API Documentation The Symbiosis API documentation, powered by Swagger, provides an interactive way to explore and test all endpoints: * [Mainnet Documentation: ](https://api.symbiosis.finance/crosschain/docs/)Access the Swagger interface for the Mainnet environment. {% hint style="info" %} **Note on Testnet:** While a Testnet environment exists for testing purposes, functionality verified on Testnet does not guarantee the same behavior on Mainnet. We strongly recommend testing directly on Mainnet using low-cost networks and small token amounts. {% endhint %} ## Supported Blockchains and Tokens #### Supported Blockchains Chain-specific parameters (chain IDs, etc.) can be found in the following configuration: * [Mainnet Configuration](https://github.com/symbiosis-finance/js-sdk/blob/main/src/crosschain/config/mainnet.ts) You can also retrieve the list of currently supported blockchains using the [`/v1/chains`](https://api.symbiosis.finance/crosschain/docs/#/Chains/get_v1_chains) endpoint. #### Supported Tokens Using the Symbiosis API, you can operate any token that exists and can be exchanged in DEXs within the blockchains supported by the Symbiosis Protocol. There are no predefined restrictions on supported tokens, and you may define your own list of tokens if needed. To retrieve the list of token used in Symbiosis, call the [`/v2/tokens`](https://api.symbiosis.finance/crosschain/docs/#/v2/get_v2_tokens) endpoint. ## Token Address Format in Payload Except for gas tokens and BTC, token addresses in the payload are expected in EVM-style `0x...` format. For EVM networks, this is the regular token contract address. For non-EVM networks, such as TON, TRON, and Solana, the token identifier is also represented in an EVM-style `0x...` format. The conversion depends on the network: * **TON:** the native TON token address is represented as a `0x...` identifier derived from its HEX form and reduced to the standard EVM address length. \ Example: USDT on TON:\ ![](/files/arNnmFE4Kb0ZQhKKidva) * **TRON:** the address is converted to and from its HEX representation directly. This mapping is reversible. * **Solana:** Solana token addresses cannot be deterministically converted to EVM-style addresses. Symbiosis uses predefined internal mappings for Solana token identifiers:\ 0x000…0001 → Solana token A,\ 0x000…0002 → Solana token B, etc.\ ![](/files/oT5ckpYrtQZlh6HBOpk3)\ **To get the list:** ``` curl -X 'GET' \ 'https://api.symbiosis.finance/crosschain/v2/tokens' \ -H 'accept: application/json' ``` ### Attributes for TON and Solana For TON and Solana tokens, the payload must also include the original native token address in the `attributes` field. In this case, the `address` field still contains the `0x...` API identifier, while the `attributes` field contains the native token address. Example for an EVM token: ``` { "tokenAmountIn": { "chainId": 1, "address": "0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48", "amount": "1000000000", "decimals": 6, "symbol": "USDC" } } ``` Example for a TON token: ``` { "tokenAmountIn": { "chainId": 85918, "address": "0x9328ED75956C38a25f59028B146Fecd3621Dfe", "amount": "1000000000", "attributes": { "ton": "EQCxE6mUtQJKFngfaROTKOt11ZbDiX1kCixRv7Nw2Id_sDS" }, "decimals": 6, "symbol": "USDT" } } ``` If the output token requires a native-address attribute, the same rule applies to `tokenOut`. ### Checking the Payload Format Integrators can always check the expected payload format for any supported network and token directly in the Symbiosis WebApp:
To do this: 1. Open . 2. Select the same source and destination networks and tokens. 3. Enter an amount. 4. Open the browser developer console. 5. Go to the **Network** tab. 6. Find the `quote` request. 7. Check the **Payload** section. ## Fees The **Symbiosis Protocol** facilitates on-chain swaps and cross-chain operations across a wide range of supported blockchain networks. During these operations, the protocol collects several types of fees. Partners may optionally apply **additional fees** on top of the standard Symbiosis fees if needed. #### Cross-chain Operations For cross-chain operations, Symbiosis provides dedicated fee collector contracts designed for partners to charge and collect custom fees in addition to the standard protocol fees: * **General Fee Collector:** deployed on the **Symbiosis chain** (the protocol host chain) — used for all cross-chain operations **except** those to and from the Bitcoin network. * **BTC Fee Collectors:** deployed on the **BNB Chain, Ethereum, Rootstock, and Citrea** — used for operations **to and from the Bitcoin network**. For details on how to collect additional fees using these contracts, please refer to [Partner Fee Collectors](/developer-tools/symbiosis-api/partner-fee-collectors) #### On-Chain Swaps For on-chain swaps, Symbiosis uses a separate **fee collector contract** deployed on each supported blockchain. The protocol does **not** provide a built-in mechanism for partners to collect additional fees for these operations. If you need to charge additional fees for on-chain swaps, you must deploy and manage your own **fee collector contract** independently. # Partner Fee Collectors Configure and collect custom partner fees for Symbiosis cross-chain operations ## Overview Symbiosis automatically charges protocol-level cross-chain fees and deducts gas fees for intermediate chains during cross-chain operations. The fee withholding logic is described in [Symbiosis & Fees](/main-concepts/symbiosis-and-fees) To support partner integrations, Symbiosis also provides **dedicated fee collector contracts**. These contracts allow partners to charge and collect custom partner fees in addition to standard Symbiosis protocol fees. Partner fee collection is available through two types of fee collectors: * **General Fee Collector:** used for all cross-chain operations except operations to and from the Bitcoin network. The contract is deployed on the **Symbiosis chain** (the protocol host chain). * **BTC Fee Collectors:** used for operations to and from the Bitcoin network. The contracts are deployed on **Ethereum, BNB chain, Rootstock, and Citrea.** ## How partner fee collection works The general flow is: 1. The partner contacts Symbiosis to enable custom fee collection. 2. Symbiosis configures the partner fee recipient address, fee model, and fee value. 3. The partner includes the configured `partnerAddress` in the `SwapRequestSchema` when calling the Symbiosis API. 4. Symbiosis applies the configured partner fee during the cross-chain operation. 5. The partner checks and claims accumulated fees through the Partner dashboard or manually through the fee collector contracts. If `partnerAddress` is not included in the swap request, no custom partner fee is collected for that operation. ## Collector types Symbiosis uses different fee collector contracts depending on the route type: * Use the General Fee Collector for all non-BTC cross-chain operations. * Use BTC Fee Collectors for operations to or from the Bitcoin network. ## General Fee Collector The General Fee Collector is used for all cross-chain operations except operations to and from the Bitcoin network. The contract is deployed on the Symbiosis chain, which is the protocol host chain. #### Fee Token Fees collected through the General Fee Collector are accumulated in sTokens, such as sUSDC, sUSDT, sWETH, and other supported synthetic assets. Symbiosis uses sTokens to facilitate cross-chain operations. Each sToken is a 1:1 pegged representation of an asset on its corresponding native chain and can be unwrapped back to that chain. For more information, see: [Symbiosis sTokens and Supported Chains](/main-concepts/wrapped-tokens) #### Fee Configuration The General Fee Collector is administered by the Symbiosis team. To enable custom partner fee collection, partners must contact Symbiosis to configure: * **Fee recipient address (**`partnerAddress`**)** — the address authorized to withdraw collected fees from the contract. * **Fee model** — percentage-based, fixed amount, or a combination of both, * **Fee value** — the actual percentage and/or fixed amount to be charged. #### Collecting Fees To apply the configured partner fee during cross-chain operations, the fee recipient address must be included as `partnerAddress` in `SwapRequestSchema` when calling the Symbiosis API. If `partnerAddress` is omitted or empty, no custom partner fee is collected for that operation.\ \ ![](/files/F6cCyRW8HllFLf6lgiW5) ## BTC Fee Collectors BTC Fee Collectors are used for cross-chain operations to and from the Bitcoin network. Unlike the General Fee Collector, BTC Fee Collectors are deployed on several EVM-compatible networks that support BTC-related routing. BTC Fee Collectors are deployed on Ethereum, BNB chain, Rootstock, and Citrea. #### Fee Token Fees collected through BTC Fee Collectors are accumulated in syBTC. syBTC is a 1:1 BTC-pegged token that can be exchanged on EVM-compatible networks or unwrapped back to native Bitcoin. #### Fee Configuration BTC Fee Collector contracts are administered by the Symbiosis team. To enable custom partner fee collection for BTC routes, partners must contact Symbiosis to configure: * **Fee recipient address (**`partnerAddress`**)** — the address eligible to withdraw collected fees from the contract. * **Fee model** — percentage-based, fixed amount, or a combination of both, * **Fee value** — the actual percentage and/or fixed amount to be charged. #### Collecting Fees To apply the configured partner fee during swaps to or from BTC, the fee recipient address must be included as `partnerAddress` in `SwapRequestSchema` when calling the Symbiosis API. If `partnerAddress` is omitted or empty, no custom partner fee is collected for that operation.\ \ ![](/files/b6C30k5FKDt0uxA8n5wz) ## Checking and Claiming Fees Partners can check and claim collected fees in two ways: * through the Partner dashboard * manually through the fee collector contracts ### Partner Dashboard
To check and claim fees through the Partner dashboard: 1. Go to 2. Connect the wallet address that is used to collect fees. 3. Claim fees for each available token. 4. Burn sTokens through the Mint/Burn page: 5. Exchange or burn syBTC token to BTC on at the Swap page: ### **Manual method** Partners can also interact with the fee collector contracts manually. #### Fee Management Methods To interact with the fee collector contracts the following methods can be used: * **`collectedFees()`** – Returns the total fees collected. * **`claimFee()`** – Withdraws accumulated fees to the configured payout address. #### Fee Collector Contracts **General Fee Collector** General fee collector on the Symbiosis chain: [address](https://symbiosis.calderaexplorer.xyz/address/0x783EE304C54d4658f59EAefb73b32D37ee466e23) **Important:** Fees collected through the General Fee Collector are accumulated in approximately 120 synthetic assets, or sTokens, on the Symbiosis chain. Partners may need to call the withdrawal method for each token type with accumulated fees. After withdrawal, sTokens need to be bridged or unwrapped to their respective native networks if the partner wants to receive the native assets. **BTC Fee Collectors** BTC fee collector addresses: * Ethereum: [address](https://etherscan.io/address/0xb4291b5f2ed122d306afef72a2b0127613ab1eef#readProxyContract) * BNB chain: [address](https://bscscan.com/address/0xc6a2c8d42086b13a577e1c300663451ae405b767#readProxyContract) * Rootstock: [address](https://explorer.rootstock.io/address/0xbba322c98601b707cffb98092010e0b95d538bb7) * Citrea: [address](https://explorer.mainnet.citrea.xyz/address/0xca506793A420E901BbCa8066be5661E3C52c84c2) # Slippage Tolerance Distribution in Cross-Chain Swaps Generally, a cross-chain swap consists of **three transactions** executed on the **source**, **host**, and **destination** chains. There can be on-chain swaps within a cross-chain swap: * **(A) Source chain** — An on-chain swap is **optional** and performed if the source token differs from the transit token used on the source chain. * **(B) Host chain** — An on-chain swap is **always performed** to exchange synthetic tokens issued for the source and destination chains. * **(C) Destination chain** — An on-chain swap is **optional** and performed if the destination token differs from the transit token used on the destination chain. **Example** Consider a swap: ETH (Ethereum) → BNB (BNB Chain)\ This cross-chain swap includes three on-chain swaps: * **(A) Ethereum:** ETH → USDC * **(B) Symbiosis Chain:** sUSDC (issued for Ethereum) → sUSDC (issued for BNB Chain) * **(C) BNB Chain:** USDC → BNB ## Slippage Tolerance Value The Symbiosis API accepts slippage tolerance values ranging from 0.2% to 10%. The specified slippage tolerance value applies to the entire cross-chain swap. The following describes how this value is divided between chains. Let the specified slippage tolerance be **Y**. **Slippage Tolerance Allocation Summary** |

A: ✗ B: ✓ C: ✗

Swap example:
USDC (Ethereum) -> USDC (BNB)

|
  • B (host): 0.2%
  • Remaining slippage ignored
| | ------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | |

A: ✓ B: ✓ C: ✗

Swap example:
ETH (Ethereum) -> USDC (BNB)

|

if Y/2 > 0.2%

  • B (host): 0.2
  • A (source): Y − 0.2

Else

  • B (host): Y/2
  • A (source): Y/2
| |

A: ✗ B: ✓ C: ✓

Swap example:
USDC (Ethereum) -> BNB (BNB)

|

if Y/2 > 0.2%

  • B (host): 0.2%
  • C (destination): Y - 0.2

Else

  • B (host): Y/2
  • C (destination): Y/2
| |

A: ✓ B: ✓ C: ✓

Swap example:
ETH (Ethereum) -> BNB (BNB)

|

if Y/3 > 0.2%

  • B (host): 0.2%
  • A (source): (Y - 0.2) / 2
  • C (destination): (Y - 0.2) / 2

else

  • B (host): Y / 3
  • A (source): Y / 3
  • C (destination): Y / 3
| **Note:** * A maximum of 0.2 % is reserved for the host-chain on-chain swap (B). **Example:** ETH (Ethereum) -> BNB (BNB), Y = 1.5% * **A (source):** 0.65% * **B (host):** 0.2% * **C (destination):** 0.65% ### Auto Slippage Mode {% hint style="info" %} This feature is currently under development. Detailed parameters and calculation logic will be documented after release. {% endhint %} If the slippage tolerance value is not specified for a cross-chain swap, Symbiosis will apply an auto slippage mode. In this mode, the slippage tolerance is determined dynamically based on the current on-chain market conditions and liquidity depth for each leg of the swap.
# Symbiosis JS SDK ## SDK Status Symbiosis previously supported two integration options: **JS SDK** and **API**. The SDK is no longer the recommended integration method. Existing integrations that still use the SDK should migrate to the Symbiosis API. ## Related Links * [Symbiosis API](/developer-tools/symbiosis-api) # Mitigating Transit Token Outcomes in Cross-Chain Swaps Symbiosis introduces a Depository contract and a Solver service to improve execution and reduce cases where a cross-chain swap completes with a transit token\* instead of the user’s chosen asset. > *\* A transit token is a token that keeps the same value across chains and is used as a medium for cross-chain execution (e.g., stablecoins, wrapped ETH, wrapped BTC).* ## The problem During cross-chain swaps, users may receive a transit token if one of the on-chain sub-swaps cannot be executed. This primarily happens when: 1. Market prices on DEXs change and the quoted swap constraints become invalid. 2. The calldata generated by a DEX aggregator is not executable (which is only discovered at execution time). #### Where transit tokens may be returned * **Any → any** (except BTC → any): on the destination chain * **BTC → any**: on BNB or on the destination chain **Example 1: USDT (Tron) → AVAX (Avalanche)** The swap spans three chains: 1. USDT.Tron → 2. (sUSDT issued for Tron → sUSDC issued for Avalanche) on Symbiosis → 3. (USDC → AVAX) on Avalanche Transit token outcome can happen on the destination chain (Step 3). **Example 2: BTC (Bitcoin) → ETH (Arbitrum)** The swap spans four chains: 1. BTC.Bitcoin → 2. (syBTC → USDC) on BNB → 3. (sUSDC issued for BNB → sUSDC issued for Arbitrum) on Symbiosis → 4. (USDC → ETH) on Arbitrum Since Bitcoin transactions have long confirmation times, swaps originating from BTC are particularly prone to transit-token outcomes on: * BNB Chain (Step 2) * Destination chain (Step 4) #### Impact The probability of receiving a transit token is low (below 1%), but with 10,000+ swaps this results in \~100 cases – meaning \~100 users receiving a token they did not intend to receive. ## The solution Instead of executing one static plan end-to-end, the payload for a cross-chain swap is now split into parts: * The parts that always succeed run as before. * The parts that may fail on-chain (those that can result in transit token outcomes) are treated as execution constraints and handled separately **by Solvers in combination with Depository contracts**. **(1) Depository + Solver simplified workflow diagram: USDT.Tron -> AVAX.Avalanche**
**(2) Depository + Solver simplified workflow diagram: BTC.Bitcoin -> ETH.Arbitrum**
### Depository contracts Before interacting with third-party DEX(s) that may fail, tokens are locked in a Depository contract on the relevant chain. For each lock, the Depository stores execution conditions under which the lock can be released. All parameters are derived from the initial payload of the cross-chain swap. **Lock Release Conditions** Depository locks are released under one of the following conditions: * **Immediate Release:** The Depository releases locked tokens without delay if the resulting token amount ≥ optimistic required amount. * **Delayed Release:** The lock is released later if the output amount falls within the dynamically expanding acceptable range, but not below the minimum acceptable amount. The minimum threshold remains constant; the acceptable upper boundary deteriorates over time until the minimum is reached. * **Fallback Release:** If it becomes impossible to perform the exchange at the minimum amount even after an extended period of time: * **BTC-origin swaps (BNB stage):** syBTC is unwrapped to BTC and returned to the Bitcoin network * **Destination-chain final swaps:** the transit token is released to the user on the destination chain (assets are not returned to the source chain to avoid double cross-chain fees and user loss) ### Solvers A Solver is an off-chain component that monitors lock events and attempts to complete the on-chain swap under the defined constraints. It computes the best available on-chain route that satisfies the defined conditions and performs the necessary transactions. The Solver can make multiple attempts to complete the swap, significantly improving the probability of successful execution. ## Effects The solution was initially introduced to eliminate cases where wrapped BTC (syBTC) could be returned to the user on BNB Chain instead of the intended destination asset. Over several months in production, all BTC-origin swaps completed successfully without returning syBTC to the user. Following the successful rollout, the Depository contracts were deployed on Arbitrum and Avalanche as well. On both networks, the mechanism operated as expected. The current plan is to extend the Depository + Solver solution to all networks supported by the protocol. ## Additional Information Refer to the following sources for more detailed information: * Any -> any: [Symbiosis: Cross-Chain Swaps](/main-concepts/symbiosis-cross-chain-swaps) * BTC -> any: [Symbiosis: To/From BTC](/main-concepts/symbiosis-cross-chain-swaps/symbiosis-to-from-btc) # Symbiosis v1 vs. v2 The differences between Symbiosis protocol v1 and Symbiosis protocol v2. {% hint style="info" %} Symbiosis protocol v2 is up and running. It inherits the main concepts and the logic of cross-chain operations of Symbiosis protocol v1, and due to its organization, it provides much better capital efficiency and can be easily extended to new blockchains. The Symbiosis Protocol v1 peacefully reached its end of life and we shut it down. {% endhint %} This document covers the similarities and differences between Symbiosis protocol v1 and its direct successor, Symbiosis protocol v2. In a nutshell, * Symbiosis protocol v2 inherits the main concepts and the logic of cross-chain operations from Vv1. * The difference lies in the liquidity pools used to perform cross-chain operations via the Symbiosis protocol. Let’s take one step deeper. The Symbiosis protocol (v1 and v2) works with a particular stablecoin on each supported blockchain to perform cross-chain operations. For instance, it’s USDC on Ethereum and BUSD on BNB. Such a stablecoin has its wrapped representation (sToken) on another blockchain with a 1:1 ratio to its locked original. For example, it is USDC on Ethereum, and its wrapped representation is sUSDC on another blockchain. ## Symbiosis Protocol v1 The Symbiosis protocol V1 has one Nerve-like liquidity pool *{stablecoin, sToken}* for each blockchain pair that supports direct cross-chain operations. Such a liquidity pool is located on the blockchain with the lowest gas fee (in the USD equivalent) of the pair and contains: * The stablecoin selected for that blockchain, and * Its wrapped representation on another blockchain (sToken). For instance, for the Ethereum — BNB chain pair, the liquidity pool *{sUSDC, BUSD}* is on BNB to minimize transaction fees (Scheme 1).

Scheme 1. Ethereum — BNB liquidity pool {sUSDC, BUSD}.

The Symbiosis protocol v1 owns and supports the net of such AMM to perform cross-chain operations (Scheme 2).

Scheme 2. Nerve-like liquidity pools with {stablecoin <> sToken} pairs in the Symbiosis Protocol v1.

If there is no liquidity pool for a blockchain pair, there are no **direct** cross-chain swaps for that pair. So, for instance, you cannot directly swap a token on Telos for a token on Avalanche. ## Symbiosis Protocol v2 The main difference between Symbiosis Protocol v2 and v1 is that the liquidity pools for cross-chain operations are now consolidated on the Symbiosis Host Chain (Scheme 3).

Scheme 3. Symbiosis protocol v2: Octopool.

An Octopool AMM contains tokens of the same face value and allows for the following: * New tokens can be added to the existing pool. * Single-sided liquidity provision and withdrawal. * Any token can be swapped for any other token within the pool (there are no token-pair constraints). This configuration uses liquidity more efficiently than v1. {% hint style="info" %} Looking for security audits? It's here: [Security Audits](/main-concepts/security-audits) {% endhint %} ### Cross-chain operations via v2 In general, Symbiosis Protocol v2 inherits the logic of v1 for cross-chain operations. Let's examine how cross-chain operations work with v2 by considering three cases: 1. The source and destination blockchains of a cross-chain operation are not the Symbiosis Host Chain (Scheme 4), 2. The destination blockchain of a cross-chain operation is the Symbiosis Host Chain (Scheme 5), 3. The source blockchain of a cross-chain operation is the Symbiosis Host Chain (Scheme 6). **Case 1** The source and destination blockchains of a cross-chain operation are not the Symbiosis Host Chain. As an example, let's see how a cross-chain swap MATIC (Polygon) for UNI (Ethereum) goes with Symbiosis v2 (Scheme 4).

Scheme 4: A cross-chain swap MATICs for UNIs via Symbiosis protocol v2

**Case 2** The destination blockchain of a cross-chain operation is the Symbiosis Host Chain. For example, let's examine how a cross-chain swap of MATICs on Polygon for some tokens on the Symbiosis Host Chain is processed through Symbiosis v2 (Scheme 5).

Scheme 5: A cross-chain swap via Symbiosis protocol v2.

**Case 3** The source blockchain of a cross-chain operation is the Symbiosis Host Chain. For example, let's examine how a cross-chain swap of tokens on the Symbiosis Host Chain for UNIs on Ethereum is processed through Symbiosis v2 (Scheme 6).

Scheme 6: A cross-chain swap via Symbiosis protocol v2.

{% hint style="info" %} **Important:** As you can see, the Symbiosis Protocol uses a number of liquidity pools to perform cross-chain operations. However, only Octopools belong to the Symbiosis protocol. {% endhint %} Cases 3 and 4 are exactly how cross-chain operations occurred in Symbiosis Protocol v1, with one difference: Symbiosis Protocol v1 used classic, nerve-like liquidity pools. # Symbiosis on Testnet Testnets are used to simulate the mainnet environment for blockchain applications, providing developers with a secure place to test their decentralized apps. * The Symbiosis Testnet is available at Please be aware that testnets often don't work stably. This includes slow transaction processing and network downtime. If you encounter a problem while working on testnets (for example, you cannot send a transaction or your operation gets stuck), please review the most common problems and their solutions below. ## My swap not coming through Testnet can be very slow. In this case, transactions take longer to be processed. **Solution:** Change settings for transactions on testnets. {% hint style="warning" %} Important: Please do not do this on Mainet! It may result in loss of assets for you. {% endhint %} To change settings for operations on Testnet: 1. Go to [Symbiosis WebApp on testnet](https://testnet.symbiosis.finance/swap?chainIn=Goerli\&tokenIn=ETH). 2. Click the cogwheel: [![](https://downloads.intercomcdn.com/i/o/737618794/68aa9b7b462aaa9cb4c73b19/image.png)](https://downloads.intercomcdn.com/i/o/737618794/68aa9b7b462aaa9cb4c73b19/image.png)
3. Set higher values for slippage tolerance and trade deadline and save the changes: [![](https://downloads.intercomcdn.com/i/o/737620406/128f3d89b360d4b9a40a6b14/image.png)](https://downloads.intercomcdn.com/i/o/737620406/128f3d89b360d4b9a40a6b14/image.png) 4. Continue performing operations on Testnet. ## Swap amount is too high or too low There are limits on swap size on testnet. This is done to prevent the liquidity pools on testnet from becoming unbalanced too quickly. **Solution:** The swap amount should be between $10 and $10,000 in USD equivalent. ## Price impact is too high If a liquidity pool is in disbalance state you may get a message: price impact is too high. In this case you cannot swap tokens you've selected.\ \ **Solution:** Try to specify a smaller amount or try another token pair. ## Network Error or No swaps for this networks’ pair You may get *Network Error* or *No swaps for this networks’ pair*, while using Symbiosis WebApp: ![](/files/LFyry9C2XMLoreKkFXSs) **Cause:** This type of error occurs when Symbiosis WebApp cannot get a timely response from the blockchains to calculate the swap. **Solution:** In most cases, this error is sporadic and if you reload the page or try to perform the swap later, the problem disappears. ## Txns fail to be sent after approval. Turns red at the first stage You may not be able to send a transaction after it has been approved in your wallet. **Cause:** RPC stopped responding due to high load. **Solution:** Try to send a transaction later. ## My transaction got stuck, no way to revert it Some transactions may get stuck. **Solution:** C'mon, it's Testnet! If this happens, just send another one. {% hint style="info" %} If you still have questions, please contact our [live support](https://discord.com/invite/jkf4QPHa5E) on Discord. {% endhint %} # 000