Mint-Burn Process | Symbiosis - Symbiosis Documentation

Learn more about the mint-burn process in Symbiosis Finance. There you will find information about the wrapping of the original ERC20 token, unsynthesizing, and more.

Contracts to Mint and Burn
Scheme 1, below, shows the main smart contracts on Blockchain 1 and Blockchain 2 for cross-chain swaps: 
To lock/unlock users' assets on Blockchain 1, and
To mint/burn sTokens on Blockchain 2 (sToken is a representation of Blockchain 1' asset on Blockchain 2). Please refer to Wrapped Tokens and sTokens | Symbiosis for more information on sTokens.
Looking for SDKs and API? Please check out our documentation for software developers Symbiosis Developer Tools 
The smart contracts are deployed and tuned by Symbiosis administrators while adding a blockchain to the Symbiosis protocol.
Scheme 1. Main smart contracts to lock/unlock users' assets on Blockchain 1, and to mint/burn sTokens on Blockchain 2.
BridgeV2 contracts issue events when called by Portal and Synthesis contracts. The relayers listen to the events, reach a consensus for each event, sign a transaction and send it to an appropriate blockchain. Please refer to  Blockchain Bridge Contracts | Symbiosis for more information on how the BridgeV2 contract works.
Portal and Synthesis contracts proceed users' calls to mint and burn sTokens. The functional scope of these two contracts is in the User's functionality section below in this document.
Scheme 2, below, shows the setup of smart contracts on Blockchain 1 and Blockchain 2 to lock/unlock assets and mint/burn sTokens on both blockchains.
Scheme 2. Smart contracts to lock/unlock users’ assets and mint/burn sTokens on Blockchain 1 and Blockchain 2.
User's Functionality
Minting
If a user has assets on Blockchain 1 and would like to get a wrapped representation of the assets (sTokens) on Blockchain 2, then, depending on the user's situation on Blockchain 1, the following cases are possible:
1.The user's asset on Blockchain 1 is an ERC20 token, and the user has native cryptocurrency to pay gas fees. In this case, the user allows spending a number of tokens to the Portal contract address by signing a transaction. Once the transaction gets executed, the user calls Portal on Blockchain 1 to mint sTokens on Blockchain 2.
2.The user's asset on Blockchain 1 is the native cryptocurrency. In this case, the user calls Portal on Blockchain 1 to mint sTokens on Blockchain 2.  
3.The user's asset on Blockchain 1 is an ERC20 token, and the user has no native cryptocurrency to pay gas fees. In this case, the user allows spending a number of tokens to the Portal contract address by signing a transaction and handles this transaction to another user who has native cryptocurrency on Blockchain 1 and is willing to help. Then, the second user calls Portal on Blockchain 1 to mint sTokens for the first user on Blockchain 2.
Scheme 3 shows what happens when a user requests minting sTokens (one algorithm for all three cases).
Scheme 3. Minting algorithm.
Scheme 3 explanation 
Blockchain 1: Transaction 1 (TXN1) is the user's call to mint sTokens. Steps 2-5 are done within Transaction 1. As soon as this transaction is executed, the user's assets get locked in Portal.
Blockchain 2: The relayers see the event issued by BridgeV2 on Blockchain 1, reach a consensus on this event, sign a transaction (TXN2), and send the transaction to Blockchain 2.
Steps 7-9 are done within Transaction2 (TXN2) on Blockchain 2. As soon as the transaction is executed, the user gets sTokens on Blockchain 2.
Burning
If a user has sTokens on Blockchain 2 and would like to get assets on Blockchain 1, then the user burns the sTokens by calling Synthesis on Blockchain 2.
Scheme 4 shows what happens when a user requests to burn sTokens.
Scheme 4. Burning algorithm.
Scheme 4 explanation 
Blockchain 1: Transaction 1 (TXN1) is the user's call to burn sTokens. Steps 2-5 are done within Transaction 1. As soon as this transaction is executed, sTokens get burnt on Blockchain 2.
Blockchain 2: The relayers see the event issued by BridgeV2 on Blockchain 2, reach a consensus on this event, sign a transaction (TXN2), and send the transaction to Blockchain 1.
Steps 7-9 are done within Transaction2 (TXN2) on Blockchain 1. As soon as the transaction is executed, assets are deposited to the user's address on Blockchain 1
Emergencies
Any cross-chain swap consists of two transactions:
1.One transaction (signed and sent by a user) is on the origin blockchain and
2.Another transaction (signed and sent by relayers) is on the destination blockchain.
An emergency means that the transaction on the origin blockchain has been processed, but there is no transaction on the destination blockchain, or that transaction is failed. 
The Symbiosis protocol does not support the completion of stuck cross-chain swaps  The Symbiosys protocol supports the revert of stuck cross-chain swaps. 
There are two important things to pay attention to
1.Reverting transaction should be sent to the blockchain where the user has not received assets.
2.Once the reverting has been accomplished, the user receives stablecoins that may differ from the exchanging token of the origin cross-chain swap.
Let's consider a couple of examples:
1.A cross-chain swap UNI (Ethereum) -> CAKE (BSC) got stuck. The route for such a cross-chain swap may look like: UNI-> USDC | sUSDC-> BUSD-> CAKE 
To revert it, the reverting transaction should be sent to BSC and the user gets USDC on Ethereum.
2.A cross-chain swap CAKE (BSC) -> UNI (Ethereum) got stuck. The route for such a cross-chain swap may look like: CAKE-> WBNB-> BUSD-> sUSDC | USDC-> WETH-> UNI 
To revert it, the reverting transaction should be sent to Ethereum and the user gets sUSDC on BSC.
A cross-chain swap transaction signed by a user and sent to the origin blockchain contains, among other data, an address on the destination blockchain from which a reverting transaction must be sent in case of emergency. If the sender’s address differs, the reverting request will not be fulfilled.
Two emergency cases are possible:
Case 1: User's assets got locked in Portal on Blockchain 1, but no sTokens are minted on Blockchain 2.
Case 2: A user has burnt sTokens on Blockchain 2, but does not receive anything on Blockchain 1.
Case 1
User's assets got locked in Portal on Blockchain 1, but no sTokens are minted on Blockchain 2. To revert minting sTokens on Blockchain 2 the user calls Synthesis to revert the minging and to get back the assets on Blockchain 1.
Scheme 5 shows what happens when the user requests to revert changes.
Scheme 5. Revert minting algorithm.
Scheme 5 explanation 
1.Synthesis checks:
No sTokens were minted,
No revert request with the same ID has been placed. 
Then steps 2-5 are done within Transaction1 (TXN1) on Blockchain 2.
2.Steps 7-9 are done within Transaction2 (TXN2) on Blockchain 1.
Case 2
A user has burnt sTokens on Blockchain 2, but does not receive anything on Blockchain 1. To revert burning on Blockchain 2 the user calls Portal on Blockchain 1.
Scheme 6 shows what happens when the user requests to revert changes.
Scheme 6. Revert burning algorithm.
Scheme 6 explanation
1.Portal checks:
A request to mint tokens has been sent,
No request to revert burning has been received. 
Then steps 2-5 are done within Transaction1 (TXN1) on Blockchain 1.
2.Steps 7-9 are done within Transaction2 (TXN2) on Blockchain 2.

Cross-chain liquidity engine - Previous

Liquidity Pools | Symbiosis

Next - Cross-chain liquidity engine

Blockchain Bridge Contracts | Symbiosis

Last modified 18d ago

Copy link

On this page

Contracts to Mint and Burn

User's Functionality

Minting

Burning

Emergencies

Case 1

Case 2