Solana Vault Design
Solana is a high-performance blockchain that can handle thousands of transactions per second. The Chainflip Vault secures the native asset as well as the supported SPL tokens. It is uniquely designed in a way that the Chainflip Validator Network always keeps control over the funds secured in the Vault.
Features of the Solana Vault Design
- Access funds using Schnorr Signatures as generated by our FROST protocol.
- Deterministically generate and manage an arbitrary number of Deposit Channel Addresses (program derived addresses) that hold funds that only the Vault can access.
- Reusal of deposit channels to reduce rent costs.
- Batching capabilities to reduce costs.
- Ability to perform a “key rotation” from one Authority Set to the next, whilst maintaining access to older deposit channels.
- Cross-Chain Messaging (CCM) capabilities
Accessing Vault funds using FROST Protocol Schnorr Signatures
Solana natively supports FROST Protocol Schnorr Signatures as part of the ed25519 signature verification specifications. Transactions signed by the State Chain validators will be accepted by the Solana network.
Basic architecture
The Solana Vault is comprised of two main components: the State Chain's aggregate key, which controls an address in Solana, and the Vault program.
The State Chain's aggregate key holds the native SOL asset and is the signer for all transactions. The State Chain's aggregate key is rotated periodically and the funds are transferred to a new address controlled by the new aggregate key.
The Vault program is responsible for managing the deposit channels, fetching the assets from the deposit channels, and transferring the assets to the destination address. The Vault program is also responsible for the key rotation process. The Vault program holds all supported SPL-tokens (USDC). However, only the current aggregate key is able to access the funds.
Generation and management of Deposit Channel Addresses
The Chainflip protocol opens deposit channel addresses for every swap. To do that it precomputes a program derived address (PDA) from the Vault program. That address is deterministic- When the user makes a deposit to that address, the deposit is witnessed and the assets are fetched to either the aggregate key (for native assets) or the Vault program (for SPL-tokens).
In order to reduce rent costs, and therefore the fees for the users, Deposit Channels are reused for successive swaps. When a channel opened for one user expires, it becomes available for a future user.
Batching capabilities to drastically reduce costs
Solana natively supports batching of instructions into a single transaction. Since some transfers have the potential of reverting only fetches are batched into the same instruction. This reduces the costs for the protocol and therefore for users. However, regardless of batching, Solana's transaction costs are generally very low, which means that not batching transfers has pretty much no impact on the user's costs.
Solana Vault Rotations
The Vault program stores the current aggregate key on-chain in order to correctly gatekeep the access to funds. When a new key is generated a key rotation transaction is crafted and signed by the current validators. That transaction updates the current stored on-chain aggregate key and transfers the native funds to the new address.
After that, payloads signed with the previous aggregate key will no longer be valid. Also, given that all deposit channels are derived from the Vault program and not the aggregate key, we still have access to the already opened Deposit channels and no extra steps are required.
Cross-Chain Messaging (CCM) capabilities
Besides regular swaps, Chainflip supports Cross-Chain Messaging Swaps for Solana. The Vault program executes these swaps by atomically transferring the assets and calling the user's program logic on the destination chain along with the user's specified message. These swaps are not batched with any other actions.