Small red and white spheres form a bolt shape

A deep dive into Core Vault design

Flare Updates

Mar 24, 2025

Introduction: FAssets v1 and Beyond

FAssets is Flare’s trustless bridging protocol, allowing users to bring assets from non-smart contract networks onto Flare and thus take advantage of its existing DeFi ecosystem. Minted copies of these assets, backed by a variety of collateral, are known as FAssets. The FAssets v1 protocol launched on Songbird, Flare’s canary network, in December 2024, with users now able to obtain minted XRP in the form of FXRP. In this blog post, we introduce the first update to the system, FAssets v1.1.

In this iteration, a Core Vault is deployed, which stores additional funds supporting the FAsset protocol. This vault increases asset liquidity, minting rate, and agent profitability across the FAsset system. It is secured by a combination of escrow accounts that time-lock vault funds and a multi-sig of trusted entities, thus providing FAssets with a decentralized reserve that holds funds to back the system. Significantly, this is only a new source of liquidity and does not alter the fundamental nature of FAssets: users and holders of FAsset v1 tokens do not need to take action to transition to the FAsset v1.1 version, and will be able to access the Core Vault automatically.

The introduction of a Core Vault improves both the user experience and the agent experience. However, this is only the first stage of improvements to the FAssets deployment: as part of Flare’s adoption of Trusted Execution Environments (TEEs), Flare is developing a TEE operated wallet protocol to manage issuing transactions from other chains on Flare. FAssets v2 will leverage this protocol to smooth out the minting and redeeming processes of FAssets, circumventing the need for the Core Vault design of v1.1 by leveraging the security properties of TEEs. Once again, this improvement will not place the burden of updates on FAsset users: previously owned FAssets will remain valid, and dedicated FAsset smart contracts will simplify the user experience. Additionally, the TEE based design will enable the extension of FAssets beyond XRP, such as to BTC and DOGE.

The FAssets Protocol

Recall that the underlying infrastructure of FAssets v1 is primarily operated by a collection of agents, whitelisted entities who provide collateral and enable users to mint and redeem FAssets. Agents have addresses on supported chains, on which they hold the underlying asset that mirrors the corresponding FAsset, as well as collateral pools of native tokens on Flare to provide redundancy. Users can transfer assets to agents on the original chain to initiate a minting transaction for the FAsset. This enables any Flare user to mint FAssets: simply transfer funds to an agent account on the supported chain and in turn receive the FAsset on Flare. Additional collateral is sourced from dedicated collateral providers, who provide native FLR tokens to collateral pools hosted by the agents to cover any shortfall, in return for which they receive a share of the agents’ minting fees. More information on FAssets v1 can be found on our website.

FAssets v1 has demonstrated its ability to securely bring assets onto Songbird, with the introduction on Flare to follow. However, v1.1 makes improvements to the system, particularly to the available liquidity: minting capacity and agent profitability have both been bottlenecked by the amount of available collateral, both in FLR and the native asset. Additionally, changing asset prices has caused some agents challenges when trying to maintain the required collateral. To this end, an additional source of stability would be beneficial, easing the burden on agents and thus freeing up liquidity across the system.

The Core Vault: A central hub for liquidity.

The primary new feature of the v1.1 iteration of FAssets is the introduction of the Core Vault, a vault address on XRP that agents can withdraw and deposit their underlying assets with. The function of the Core Vault is to facilitate agents in freeing up liquidity. Once an agent has transferred assets to the Core Vault, corresponding FLR collateral on Flare from the agent’s collateral pool can be released, either to mint further FAssets or to allow the agent to modify the usage of their collateral. Conversely, agents can withdraw XRP from the Core Vault in exchange for putting down more collateral.

Functionally, the Core Vault is a multi-sig address on the XRP ledger whose signers are authorized, identifiable entities cooperating with the Flare Foundation. Since the address will be used to provide additional liquidity to the system, the operators of the multi-sig must be trustworthy, as they are required to handle the funds honestly. To this end, the Core Vault will typically only emit a certain amount of XRP each day, to ensure its signers cannot maliciously drain the vault. Commands will be issued to the Core Vault via a smart contract on Flare, relayed off-chain, and signed and executed by the owners of the multi-sig. To maximize operational security, the Core Vault’s signers are not expected to automate its processes: rather, they manually sign off on transactions in response to human-readable instructions from a dedicated smart contract on Flare.

The Core Vault address is responsible for assisting two FAsset participants. For agents, the Core Vault sends and receives payment transactions, sending them XRP in return for locking collateral on Flare or allowing them to unlock collateral on Flare by transferring XRP to the vault. For users, the Core Vault is in place to handle direct redemption requests, in which users present and burn their own FXRP directly, receiving XRP in return from the vault. Direct redemptions from the Core Vault are slower than agent redemptions, taking a day or more, and must exceed some minimum quantity, expected to be in the hundreds of thousands of dollars of value. Additionally, these are only available to white listed users who have been approved by a KYC check. However, it circumvents the need to find agents with sufficient liquidity, and thus supports users wishing to move large investments but who are not too concerned by latency.

Securing the Core Vault: Limiting access to funds

As mentioned above, redemptions from the Core Vault are slower than direct ones. This is because it is not always live, as signing is not automated. Instead, there are specific signing times around once per day. At these times, three types of transactions are released. The first two are to support users and agents as described above: payment transactions are issued to agents who have locked appropriate collateral on Flare, and direct redemption transactions are handled. These transactions enable the functionality of the core vault, providing users and agents with liquidity.

The third type of transaction is in place to secure the vault’s funds. This transaction is an escrow transaction, where funds are suspended in escrow accounts for use at a later date. By escrowing funds, the “current account” of the vault is never large enough to present a major security risk. How does this work? At the end of each day, if the amount of XRP remaining in the vault (after paying out users and agents) is too large, the funds are moved in batches into escrow accounts. Each escrow account holds a batch of XRP, and each day precisely one escrow expires, returning its XRP to the Core Vault. These funds, along with agent deposits, are what are used to pay out users and agents that day.

By locking excess funds in escrow accounts, a security breach of the Core Vault or its signers has only limited impact: only one escrow's worth of XRP is available each day, with the rest time-locked and thus inaccessible. In case of unprecedented demand for the Core Vault’s services and in case of security incidents, funds held in escrow can also be released to a safe custodian address, who are trusted to distribute the funds appropriately. This release can only be triggered by the Flare Foundation, subject to appropriate security controls.

A Day in the Life of the Core Vault

To better understand how the Core Vault holds its funds, let's examine a day in the life of its operation. The Core Vault has two parameters: a minimum reserve level M and a lot size L. The minimum reserve level M determines the amount that will be kept in the vault each day: it is in place to ensure that the vault can handle a day’s worth of withdrawals, with the lot size L determining the amount of XRP held in each escrow account. At the start of the day, the vault has a quantity S of XRP funds leftover from the previous day. Additionally, there are a collection of escrow accounts each containing a batch of L XRP tokens, with expiry scheduled so that exactly one releases its batch of XRP to the vault each day. Then, a day of operations occurs like so:

Over the course of the day, the agents deposit some amount of funds F_deposit of XRP in the vault. Similarly, users request a withdrawal amount W_user and agents request a payment amount W_agent. Thus, the total amount of funds to be withdrawn at the signing time for the day is W_total = W_user + W_agent.
The controlling smart contract on Flare issues an instruction containing the addresses and quantities of XRP to be issued for withdrawals that day. These instructions are picked up by the operators of the vault.
One of the escrows expires, returning an amount L of XRP to the Core Vault. The total funds available to the Core Vault to distribute is now F_total = L + S +F_deposit, which is also the maximum amount reached each day.
At the signing time for the day, users and agents are paid out according to the instructions from the smart contract. If the total funds are not sufficient to cover the withdrawals then any withdrawals not honoured are pushed to the next day. Otherwise, all withdrawal requests are responded to, and the remaining funds are F_remain = F_total - W_total.
Finally, the vault begins the escrow process to ensure that the remaining funds are locked. Excess funds are locked in batches of size L until it is no longer possible to do so without going below the minimum threshold M of XRP in the Core Vault. For example, if Fremain = M + 3L, three escrow accounts are made and M funds remain leftover, but if Fremain = M + 2.5L, then two escrow accounts are made and the leftover for the next day is S = M + 0.5L. As usual, escrow accounts are time-locked so that only one batch of XRP returns to the Core Vault each day.

Since these operations are only executed around once a day, withdrawals directly from the Core Vault essentially have lower priority than direct agent operations. This, alongside the one day cadence of escrow release contribute to the security of the vault: the most amount of XRP that can be transferred out of the Core Vault in a single day is F_total, thus restricting the effects of a security breach. If a security breach is detected, remaining funds locked in escrow will not be returned to the vault. The operators of the multi-sig are expected to validate that the transactions ordered from the hosting contract on Flare are in accordance with the pre-defined specification of the Core Vault’s duties, to ensure there is no breach on that end either.

Looking Ahead: FAssets v2 and TEEs

In summary, FAssets v1.1 introduces the Core Vault to increase liquidity of FAssets: agents can transfer funds to and from the Core Vault, freeing up liquidity to either withdraw from the system or create additional FAssets. This improves the agent experience in terms of both fluidity and profitability. Similarly, approved users can perform certain redemption transactions directly from the Core Vault, circumventing the need to find a redeeming agent. It is secured through a combination of a multi-sig and the XRP Ledger’s native escrow accounts, so that the vault’s funds are not vulnerable to attack. Additionally, the Flare Foundation will continually monitor its operation, with the power to initiate an Alert Mode if unexpected behaviour is detected, locking down all signing from the Core Vault until an appropriate response is determined.