Links
🔥

Symbiosis Mint-Burn Process

Symbiosis core smart contracts: Portal/Synthesis contracts and mint/burn processes.

Minting and Burning Intro

Symbiosis core smart contracts are open source and available at https://github.com/symbiosis-finance/core-contracts​
For security audits of Symbiosis core smart contract, please refer to the Security Audits document.
The Symbiosis protocol mints and burns sTokens during cross-chain operations conducted via the Symbiosis protocol. The Portal and Synthesis contracts are the main smart contract of the mint-burnt process:
  • Whenever Portal locks a number of tokent, Synthesis mints the same number of sTokens (Scheme 1),
  • Whenever Synthesis burns a number of sTokens, Portal on the corresponding blockchain releases the same number of tokens (Scheme 2).
Where the sTokens are the representation of tokens from another blockchain. More about the sToken concept can be found in the Wrapped Tokens and sTokens document.
The Symbiosis protocol works with a chosen stablecoin* on every supported blockchain; for example, it's USDC on Ethereum and BUSD on BNB Chain. The sToken for USDC is sUSDC, and the sToken for BUSD is sBUSD.
*The Symbiosis protocol works with a chosen stablecoin on every supported blockchain with one exception: SIS token on Ethereum. Check the section below SIS on BNB.
Schemes 1 and 2 show real cases using Ethereum and BNB Chain.
Scheme 1. The minting routine of Symbiosis protocol V2.
Scheme 2. The burning routine of Symbiosis protocol V2.
Steps 1-7 shown in Scheme 1 and 2 are a part of each cross-chain operation. Please refer to the Metarouter V3 document to see the entire picture.
About relayers. The Symbiosis relayers network is a P2P network with built-in crypto-economic incentivization mechanisms. The relayers network is an off-chain part of the Symbiosis protocol. The main purpose of the network is a fast, accurate, and secure transfer of information about cross-chain operations conducted via the Symbiosis protocol. Please refer to Symbiosis Relayer Network for more information.

SIS on BNB

SIS is the token of the Symbiosis protocol. Token holders can bridge their SIS tokens from Ethereum to the BNB chain via the Symbiosis protocol: Schemes 3, 4 below.
Scheme 3. Bridging SIS tokens to the BNB chain.
Scheme 4. Burning SIS BNB to get SIS tokens on Ethereum.

No Double Spending

Any cross-chain operation in Symbiosis protocol V2 consists of two or three transactions.
If S-chain isn't the source or destination blockchain of a cross-chain operation, we will have three transactions:
  1. 1.
    The first transaction (signed and sent by a user) is on the source blockchain,
  2. 2.
    The second transaction (signed and sent by relayers) is on S-chain, and
  3. 3.
    The third transaction (signed and sent by relayers) is on the destination blockchain.
If S-chain is the source or destination blockchain of a cross-chain operation, we will have two transactions:
  1. 1.
    The first transaction (signed and sent by a user) is on the source blockchain, and
  2. 2.
    The second transaction (signed and sent by relayers) is on S-chain.
or
  1. 1.
    The first transaction (signed and sent by a user) is on S-chain, and
  2. 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.
Let's consider an sToken minting operation as an example. Synthesis mints tokens and records the operation within the same transaction. If the transaction is completed and the tokens get minted, then there is a record of the operation, and the contract will not issue tokens a second time for the transaction with the same ID. If the transaction gets failed, no sTokens will be minted, and no information about the operation will be recorded.

Emergencies

Since every cross-chain operation is a sequence of transactions that should 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 DEXes 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.
It is not possible to accomplish a stuck cross-chain operation. A stuck cross-chain operation can be reverted.
Let's consider a cross-chain swap: ETH on Ethereum for MATIC on Polygon, as an example. This operation consists of 3 transactions. Each transaction consists of several steps:
  1. 1.
    TXN1 on Ethereum: Swap ETH for USDC, lock the USDC, and create an Oracle;
  2. 2.
    TXN2 on S-chain (BOBA BNB): mint sUSDC Ethereum, swap the sUSDC Ethereum for sUSDC Polygon, burn the sUSDC Polygon, and create an Oracle;
  3. 3.
    TXN3 on Polygon: release USDC, swap the USDC for MATIC, and send the MATIC to the user's address on Polygon.
Case 1: TXN1 -> TXN2 -> TXN3
The transaction (TXN1) on the source blockchain (Ethereum) was successfully processed. Then something went wrong. In this case, the user should send a transaction with reverting instructions to the source blockchain: Ethereum in this example. When the reverting transaction gets processed, the user receives USDC on Ethereum.
Case 2: TXN1 -> TXN2 -> TXN3
The transaction (TXN1) on the source blockchain (Ethereum) and the transaction on S-chain were successfully processed. Then something went wrong. In this case, the user should send a transaction with reverting instructions to Polygon. When the reverting transaction gets processed, the user receives USDC on Ethereum.
Important points:
  1. 1.
    The first transaction that is signed and sent by the user to the source blockchain contains all instructions that should be conducted on all blockchains during this cross-chain operation. In addition, these instructions include the address on the source blockchain that should be used to send tokens in case of reverting. Neither instructions nor this address can be changed once the initial transaction is signed.
  2. 2.
    Reverting is also a cross-chain operation, so it also may get stuck. No worries. If a reverting transaction gets failed, the user should send another reverting transaction.
  3. 3.
    When a reverting operation is accomplished, the user receives stablecoins on the blockchain that is the source one for the initial cross-chain operation. It will be of the stablecoin type that is used in the Symbiosis protocol on that blockchain (USDC on Ethereum in our example).
​