Core Protocol
Sometimes called a “Cross-Chain Liquidity Network,” the core of the Chainflip idea is to use MPC (Multi-Party-Computation), and in particular TSS (Threshold Signature Schemes) to create aggregate keys held by a permissionless network of 150 Validators. These Validators control simple smart contracts/wallets called Vaults, on multiple blockchains simultaneously, giving rise to a fully decentralised Settlement Layer. This is paired with an Accounting Layer, which uses the Substrate based State Chain to track balances, process events, and execute instructions.
Although actual implementation itself does not function with a perfect separation of the accounting and Settlement Layers, breaking down the system into two layers is a helpful way to conceptualise its structure.
Although the assets are held in native wallets on chains such as Ethereum, Bitcoin, and so on, all of the trading and account keeping occurs on the State Chain. This means that swap execution and AMM design can be heavily customised for the specific use-case of cross-chain value transfer.
In practice, the Accounting Layer exists on the State Chain, which is an “intermediate” blockchain running the Aura Proof of Stake consensus system as provided by Substrate, a blockchain framework developed by Parity and the Web3 Foundation. Adding additional events and extrinsics to the base functionality of Substrate enables the accounting functionality of Chainflip.
At a high-level, the Chainflip Just In Time (JIT) AMM is based on the Uniswap v3 AMM design. However, unlike Uniswap v3, the JIT AMM is not represented as a series of smart contracts on a single blockchain environment. Rather, the JIT AMM is virtual. This means that funds are not held directly in on-chain pools, but rather the AMM is part of the Accounting Layer. The Accounting Layer tracks incoming funds into the vaults using information fed from the Settlement Layer, and determines what should be sent from them. This works in a similar fashion to how centralised cryptocurrency exchanges store all of the deposits in a unified wallet system, with the balances of individual users tracked in a connected but logically separated accounting and trading system.
The use of a separate Accounting Layer dramatically simplifies the work needed to support individual chains, as rather than needing to write swapping logic in a range of smart contract and scripting languages on external blockchains, the swapping logic is entirely contained within the Chainflip State Chain environment, meaning all of the abstractions needed to support a given chain can be managed entirely within the Settlement Layer, and are much simpler in comparison.
The two systems, although logically separated, are controlled by the same set of Validators on the Chainflip network.
A Validator, in the context of Chainflip, is a server operating a Chainflip State Chain node, as well as additional ‘sidecar’ functionality through the Chainflip Engine (CFE), an off-chain processing module. Validators are covered in more detail here, but for the purposes of introduction, at a high level:
- Up to 150 Validators can participate in the protocol’s Authority Set based on their stake and jointly operate both layers.
- All Validator slots are entirely permissionless, where any Validator operator with sufficient $FLIP to outbid others can become a member of the Authority Set by winning slots during regular auctions.
- Each individual validator has its own set of private-keys which it uses to participate in the consensus of the State Chain, as well as to generate secrets for the purposes of MPC.
Validators in the Authority Set perform the following functions:
- The Accounting Layer (State Chain)
- Maintain and update the State Chain through Aura proof of stake consensus.
- Come to consensus on incoming deposits and register them on the chain (Witnessing).
- Come to consensus on proposed transactions to sign/broadcast.
- The Settlement Layer (Chainflip Engine)
- Participate in TSS Keygen ceremonies to create Vaults.
- Participate in TSS Signing ceremonies to move funds for the protocol.
- Monitoring and Parsing incoming transactions to vaults on external chains to be Witnessed.
With this two-layer abstraction laid out, let’s use it to understand more components and how they come together to solve the cross-chain swapping problem.
Fundamental to any native asset swap flow is for there to be a pool of liquid assets somewhere. With no source of on-chain liquidity, there would be nothing to swap. At the ground floor of any credible native cross-chain swap protocol, a general solution to flexible liquidity storage must be engineered. In this section, we’ll pull apart what a Vault is and where it fits into the wider protocol.
“A fundamental limitation of other interoperability protocol designs is that they lack the ability to secure native funds on host blockchains. So called ‘messaging’ or ‘interoperability’ protocols offer insufficient functionality to carry out large scale cross-chain trading. These protocols only enable 1 to 1 swaps, which limit their utility to users. This type of protocol design cannot fulfil the functionality ultimately necessary to render a centralised exchange offering obsolete, and in turn might explain why they have achieved limited adoption.”
A vault is a method of storing funds on a given blockchain that is controlled by the Chainflip protocol. This could come in a few forms, with different blockchains offering different features and limitations, but broadly there are two categories of vault which are used to store funds to be used in the AMM:
- Vault Contract: A smart contract (EVM or non-EVM) which holds a pool of assets on a given chain. The vault smart contract can send funds with the approval of an aggregate key held in the KeyManager contract. The aggregate key is controlled by the Authority Set in a 100 of 150 threshold signature scheme (FROST) handled off-chain. When the Authority Set is changing, the old Authority Set approves a transaction which changes the aggregate key from the outgoing Authority Set to the new aggregate key, controlled by the new Authority Set in the KeyManager contract.
- Native Wallet Vaults: A native wallet or set of wallets controlled by the Authority Set in a 100 of 150 threshold signature scheme and is handled off chain. As with the vault contract above, the native wallet vault still relies on the FROST threshold signature scheme to function. The details of the native wallets vary from blockchain to blockchain, but rely on native multisig schemes offered as features on each blockchain. Funds are held in each Native Wallet Vault until a new Authority Set is determined, after which a Vault Rotation occurs. The new Authority Set will create its own Native Wallet Vault, and the outgoing Authority Set will sweep funds from its own Wallet Vault into the new one over the expiry period. This means that there will be multiple ‘active’ vaults during a vault rotation, until all outgoing vaults have expired.
Although not used for liquidity pools, there is also a third protocol controlled vault-like contract that fills a special function called the:
- Stake Manager Contract: The Stake Manager Contract is a smart contract (initially just on the Ethereum network) which holds $FLIP funds as collateral for accounts on the State-Chain. Like the Vault Contract & Native Wallet Vaults, signature verification is delegated to the KeyManager contract, which verifies an aggregate signature produced by the current Authority Set. Unlike the Vault Contract, users directly interact with this contract, but can only claim$FLIP from this contract with a valid signature from the aggregate key - or in other words, with the off-chain approval of a transaction by the Authority Set.
In all of these cases, a new Authority Set must perform all of the necessary key-generation ceremonies for all deployed vaults before authority over the State Chain consensus, vault contract, and stake manager contract are handed over, and before any funds are swept from old Native Wallet Vaults into the new.
No matter the underlying implementation of each vault, the end result is that there is an account on each supported blockchain under the control of the Chainflip protocol. This forms a functional, decentralised, and generalised Settlement Layer on which liquidity pools and staking functionality can be virtually constructed using assets held in these vaults.