🔥
Mint-Burn Process | Symbiosis
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.
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.
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.
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
Any cross-chain swap consists of two transactions:
- 1.One transaction (signed and sent by a user) is on the source blockchain and
- 2.Another transaction (signed and sent by relayers) is on the destination blockchain.
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.
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 source cross-chain operation (the stuck one).
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 source 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.
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.
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.