Egress: Sending Assets out of Chainflip
- 1.Sending $FLIP funds from the StakeManager contract when a Validator or other State Chain account holder wishes to withdraw $FLIP;
- 2.Sending assets to a liquidity provider that is withdrawing their collateral, or;
- 3.Sending the output of a swap to a user's Payout Address.
As with ingress, the process for egress differs slightly from case to case, but shares a common process: TSS (Threshold Signature Scheme) Signing.
When an event on the State Chain occurs that signals to the Authority Set that a signature is needed, the Validators begin a ceremony. Wherever possible, outputs will be batched together to save on gas fees and to minimise the number of signing ceremonies required to send users their required funds.
TSS signing in Chainflip is conducted using the FROST multisig scheme, which relies on Schnorr signatures for fast and scalable multi-party-computation, allowing for a large set of signers. FROST allows Chainflip to secure all Vaults using the same Authority Set of 150 Validators, offering substantial benefits in terms of economic security and a simpler Vault management logic compared to other Cross-Chain Liquidity Networks.
In the original Chainflip paper, another threshold signing scheme called GG20 was envisaged to be utilised on the basis that some blockchains do not support Schnorr signatures and would thus be incompatible with the FROST scheme. Fortunately, since Bitcoin’s taproot upgrade, the vast majority of blockchains are now FROST compatible. We do not anticipate the need to support GG20 in the future on the basis that the remaining chains that are FROST incompatible are not popular enough to warrant integration. GG20 scales significantly worse than FROST and would mean a subset of the Authority Set would have to be nominated to secure the GG20 based vaults.
When a Validator wishes to unstake or extract some of their rewards, or other users with a State Chain account wish to take out the $FLIP locked on the State Chain to use on the Ethereum network, the user needs approval from the Authority Set.
- 1.The user submits an extrinsic to the State Chain requesting a withdrawal, which contains the balance of tokens they wish to withdraw and the Ethereum address they wish to be paid out to.
- 2.Upon the inclusion of the request in the next block, the Authority Set checks that the request is valid, and if so proceeds to commence a Signing Ceremony. The result of the Signing Ceremony is a Withdrawal Certificate, which is a valid signature from the aggregate key posted to the State Chain. The signed data includes the balance that can be withdrawn and the payout address.
- 3.The user takes their withdrawal certificate and passes it into a function in the StakeManager contract on Ethereum. This function will check the validity of the certificate by verifying the signature and certificate expiry, and if successful will start a 2 day timer (explained below) that the user must wait for until they can finally claim their $FLIP.
- 4.After the delay window has passed, the user can call a final claim function on the StakeManager contract. The contract will send $FLIP tokens to the account holder. If this claim function is not called after a defined period of time, the withdrawal certificate is no longer valid and will not be accepted by the smart contract. Instead, the user will have to repeat this process.
- 5.After the $FLIP has been withdrawn from the contract, the Authority Set witnesses the egress transaction and records it as settled in the Accounting Layer.
The delay mechanism is installed to catch scenarios where falsely produced withdrawal certificates (such as in the unlikely event of a supermajority attack or software exploit) can not be used to claim arbitrary amounts of $FLIP. Additional governance mechanisms exist to prevent and mitigate the severity of attacks and exploits. For more details, see governance and security measures.
Not only is the ability to withdraw liquidity essential, but it is expected to be fairly frequent in the JIT AMM. Liquidity Providers will often have to rebalance their asset float across the markets which they operate on to maintain a balanced and effective market making strategy.
- 1.The user submits an extrinsic to the State Chain which closes or reduces their liquidity position, leaving their collateral in a “free” state where it can be withdrawn.
- 2.The user submits a second extrinsic to the state chain which signals the network to send the specified amount of assets to their refund address, which would have been specified when the account was created. Refund addresses can also be updated without creating a new account. This instruction becomes a Pending Egress Transaction, and is passed to the Settlement Layer to be settled.
- 3.The Authority Set commences a Signing Ceremony to create a valid transaction to send funds from the relevant Vault to the user, deducting the gas free required from the balance owed to the user. The signed transaction is broadcast to the relevant external chain by a nominated validator, and the user receives their funds less the gas fee.
- 4.The Authority Set witnesses the egress transaction and records the transaction as settled in the accounting layer.
Finally, paying out users in the asset of their choice completes the functionality needed for the Chainflip protocol and represents the most common expected egress transaction.
- 1.Once a swap has been automatically executed on the State Chain, the assets to be paid out to the user are listed as a Pending Egress Transaction.
- 2.Using the Payout address specified in the User’s Swap Intent, and bundling the Pending Egress Transaction with others into a single batch transaction, the Authority Set conducts a Signing Ceremony to produce a valid transaction for that chain.
- 3.The signed transaction is broadcast to the relevant external chain by a nominated Validator, and the user receives their funds less their share of the gas fee.
- 4.The Authority Set witnesses the egress transaction and records the transaction as settled in the accounting layer.