Redemption

Any holder of FAssets can redeem their FAssets for the underlying original asset. To do so, these holders, known as redeemers, send FAssets to the Asset Manager smart contract, and the redeemed amount is paid with the underlying asset from an agent's address.

Redemption Process

This is the summary of the redemption process:

1. The redeemer starts the redemption by issuing a request to the Asset Manager smart contract. The standard redeem method requires a whole number of lots, while redeemAmount and redeemWithTag allow redeeming any amount.

   The FAssets system chooses one or more redemption tickets from the front of the FIFO redemption queue. The number of chosen redemption tickets is capped to avoid high gas consumption. If the redemption amount requires too many tickets, only a partial redemption is done.

2. The system burns FAssets from the redeemer's account in the amount of the total of the selected redemption tickets. If the redeemer's account does not contain enough FAssets, the redemption fails immediately.

3. Each chosen ticket belongs to an agent. For every agent participating in the redemption, the system issues an event with the following redemption payment information:

   • Redeemer's underlying address.

     Agents can use the Flare Data Connector to ensure the validity of this address. Otherwise, malicious redeemers could provide an address that systematically blocks payments and exploits the redeeming process to their advantage.

   • Amount the agent must pay on the underlying chain, after the system fee and the agent fee.

   • A payment reference. This payment reference is different for each agent and each redemption.

   • The last underlying block and the last underlying timestamp to complete the payment.

4. Every agent pays the redeemer on the underlying chain and includes the payment reference in the memo field of the payment transaction.

   Agents can pay the redemption from their own address, which they control on the underlying chain. It does not need to be the same address where they receive minting payments.

5. After the payment is finalized, the agent uses the FDC to prove the payment and obtain a payment proof.

6. The agent (or, in Core Vault and specific flows, the executor) presents the payment proof to the FAssets system, which issues a redemption ticket.

   The executor role is responsible for ensuring that the system can finalize redemptions even if the agent is unresponsive or if the flow is managed by a central entity (such as the Core Vault executor).

   The redemption ticket is required to:

   • Prove the payment has occurred.
   • Trigger burning of the FAssets.
   • Release the corresponding agent's vault collateral and pool collateral.
   • Ensure the system tracks the underlying chain balances correctly.

   After the collateral is released, it can either back the minting of more FAssets or be withdrawn.

Redeem Any Amount

The standard redeem method requires whole lots. The redeemAmount method allows redeeming any amount of FAssets, which is useful for redeeming yields or partial amounts that don not align with lot boundaries.

No redemption through redeemAmount or redeemWithTag can be smaller than minimumRedeemAmountUBA to prevent uneconomical micro-redemptions. If the requested amount requires too many redemption tickets, only a partial redemption is performed and the remaining amount is returned in a RedemptionAmountIncomplete event.

Redeem with Tag

The redeemWithTag method allows the redeemer to request an XRP destination tag on the redemption payment. This is useful when redeeming directly to an exchange address that requires a destination tag. Like redeemAmount, it also supports redeeming any amount, not just whole lots.

The destination tag must fit in a 32-bit integer. This is an XRP-only feature, gated by the redeemWithTagSupported flag. Confirming a redemption with a tag requires the confirmXRPRedemptionPayment method, which uses a dedicated FDC proof type that supports destination tags. If the agent fails to pay, the redeemer calls xrpRedemptionPaymentDefault to trigger the default process.

Fees

A redemption request charges two fees, one after the other, plus an optional executor fee. Both rates are in BIPS (10,000 BIPS = 100%) and each one is rounded down. Live rates are in the operational parameters.

Fee	Charged in	When it applies	Who receives it
System fee	FAssets minted to the fee receiver; taken out of the redeemed amount	A receiver is set, and the request is not a transfer to the core vault	systemRedemptionFeeReceiver, the address set by governance
Agent fee	Underlying asset, deducted from the payout	Every redemption request except a transfer to the core vault	The agent. A share is then minted as FAssets into that agent's collateral pool
Executor fee	FLR	Only when the redeemer names an executor	The executor, for calling redemption default if the agent does not pay

Redemption fee

On a redemption of amount (x), the redeemer is paid this much underlying:

$$x \cdot \left(1 - \frac{\text{systemRedemptionFeeBIPS}}{10000}\right) \cdot \left(1 - \frac{\text{redemptionFeeBIPS}}{10000}\right)$$

The redeemer calls redeem, redeemAmount, or redeemWithTag. Inside that call the Asset Manager creates one request per agent and applies the fees below. A transfer to the core vault creates a request too, and skips both fees.

System fee

Taken first, in RedemptionRequests.createRedemptionRequest.

systemRedemptionFeeBIPS is subtracted from the redeemed amount. The backing for that slice is released, and the same amount of FAssets is minted to systemRedemptionFeeReceiver. SystemRedemptionFeePaid records the mint. The redeemed FAssets, including this slice, are burned from the redeemer, so the receiver's new tokens are the system fee.

Governance sets the rate and the receiver on RedeemExtendedSettingsFacet (setSystemRedemptionFeeBIPS, setSystemRedemptionFeeReceiver). Read the rate with systemRedemptionFeeBIPS and the receiver with systemRedemptionFeeReceiver. The charged rate is the stored rate when the receiver is nonzero, and 0 when the receiver is the zero address. effectiveSystemRedemptionFeeBIPS returns that charged rate on networks where the getter is deployed. The fee is also skipped on a transfer to the core vault.

Agent fee

Taken next, on what remains after the system fee. The global redemptionFeeBIPS is the same for every agent and is stored on the request as underlyingFeeUBA. The agent pays underlyingValueUBA - underlyingFeeUBA on the underlying chain and keeps the difference. On RedemptionRequested, valueUBA is the amount after the system fee, and feeUBA is this agent fee.

That agent fee is split again when the payment is confirmed, in RedemptionConfirmationsFacet._mintPoolFee:

• The agent's own redemptionPoolFeeShareBIPS of the fee is minted as new FAssets into that agent's collateral pool (fAssetFeeDeposited). RedemptionPoolFeeMinted records it.
• The rest stays with the agent as underlying that was never paid out.

The pool share is copied from the agent onto the request when the request is created. It is charged when the agent (or, after the confirmation window, anyone) proves the underlying payment. Each agent sets its own share. The default agent settings list the starting value.

Executor Fee

An optional executor fee can be paid to compensate an executor who triggers a redemption default if the agent fails to pay on the underlying chain. This spares the redeemer from having to perform extra operations to complete the redemption process.

The executor fee is paid in FLR, and the amount is agreed upon off-chain between the redeemer and the executor. This fee is only applicable when an executor is involved in the redemption process.

Redemption-Payment Failure

Agents have a limited time to pay the redeemer on the underlying chain. The last block and the last timestamp on the underlying chain define the amount of time. If the payment is not made in time, the redeemer has to prove payment non-existence to be compensated. After the redeemer presents the payment non-existence proof, he is paid with the agent's collateral plus a redemption default premium. The premium is intended to encourage the agent to complete redemptions by paying with the underlying asset instead of collateral.

If a payment fails and the failed transaction is recorded on the underlying chain, the agent must submit proof of the failed payment. In this way, the gas costs of the failed transaction can be accounted for by the FAssets system. If the transaction was not recorded, then no gas was spent, and reporting is not necessary.

If the agent does not report the failed payment in time, anyone (including the executor) can report the failed payment and receive a reward from the agent's vault.

info

When payment fails because of the redeemer, the agent can obtain proof of the failed payment from the Flare Data Connector and present it to the FAssets system. The agent's obligation is then fulfilled, and he can keep both the collateral and the underlying.

Two different proofs can be used:

• Proof of invalid address, due to a wrong syntax or checksum, for example.

• Proof of blocked payment: Even if the address is valid, the payment can still be blocked for various reasons.

  One important example is an XRPL redeemer who has enabled asfRequireDest on their account and then used a simple redeem request (redeem or redeemAmount) instead of redeemWithTag. Incoming payments then require a destination tag, but a simple redeem request does not include one, so the XRPL rejects the agent's payment.

  The agent must still try to pay, and if the payment is blocked, the agent can request this proof from the Flare Data Connector and present it to the FAssets system.

During step 4 above, if any agent does not pay on the underlying chain, the redeemer completes the following procedure separately for each nonpaying agent:

1. The redeemer obtains a proof of payment non-existence from the Flare Data Connector.
2. The redeemer presents the payment non-existence proofs to the FAssets system, which triggers a redemption failure.
3. The redeemer is paid with collateral, according to the current price plus a premium.
4. FAssets are overcollateralized, so, even after paying the redeemer with a premium, a remainder is released. This remainder is derived from the system-wide collateral ratio settings specified by governance.
5. The underlying assets backing the redeemed FAssets are marked as free and can be withdrawn by the agent later.

Redemption Time Extension

When many redemption requests target the same agent in rapid succession, the system automatically extends the agent's payment deadline. Each new redemption request adds time to the deadline, which then gradually decays back to the baseline as the volume of requests decreases. This mechanism prevents agents from being overwhelmed by a burst of redemptions and failing to pay in time through no fault of their own.

Edge Cases

Unresponsive redeemer

After a redemption nonpayment, the redeemer might not report the failure for some reason. In this case, the agent or the executor can present a payment non-existence proof, and the redeemer receives collateral plus a premium. After this operation, the underlying backing collateral and the remaining local collateral are released.

Unresponsive agent

After a successful payment, the agent might not present the payment proof (redemption ticket).

Because the agent has already paid, the redeemer is not affected. However, the system still requires the payment proof to track the agent's balance on the underlying chain correctly. After enough time for the agent to present the proof has elapsed, anyone, including the executor, can show the payment proof and receive collateral from the agent's vault as a reward.

Expired proof

Proofs provided by the Flare Data Connector can be created for 14 days and remain valid indefinitely once created. If neither the redeemer, the agent, nor the executor presents proof of payment or evidence of non-payment within the 14-day window, the regular redemption process cannot continue, and the agent's collateral could be locked indefinitely.

In this case, the agent can still recover the collateral by buying it back with native tokens:

1. Request the proof from the time when the payment should have happened. The Flare Data Connector's answer will indicate that payment proofs are no longer available for that time.
2. Provide the amount of FLR collateral equivalent to the price of the underlying assets that should have been paid.
3. Present the proof.

Because a successful payment cannot be proven, the FAssets system burns the amount of collateral in native tokens provided by the agent. After the burn is complete, the rest of the agent's collateral is released, both from the vault and the collateral pool.

warning

Note that this procedure should be used only in rare cases because providing timely payment or nonpayment proofs is always more advantageous for agents.

Redemption Tickets and the Redemption Queue

For every minting operation, a redemption ticket is created. This ticket references the minted amount and the agent that is backing the minting.

The redemption tickets are ordered in a queue that determines the next agent to be redeemed against according to the first in, first out method (FIFO). In other words, the first redemption ticket created will be the first redemption ticket processed. The FIFO queue impartially ensures that all agents have the opportunity to fulfill the duties of their role.

The following example shows how the redemption queue works.

Redemption queue example.

1. Alice mints 10 FXRP with Agent 1.

2. Bob mints 20 FXRP with Agent 2.

3. Charlie mints 5 FXRP with Agent 1.

   After Alice, Bob, and Charlie have minted their FAssets, the redemption queue according to the FIFO method is:

   1. Agent 1 with 10 FXRP.
   2. Agent 2 with 20 FXRP.
   3. Agent 1 with 5 FXRP.

4. Dana redeems 25 FXRP. To redeem 25 FXRP:

   1. Agent 1 pays 10 FXRP.
   2. Agent 2 pays 15 FXRP.

   Now, the redemption queue according to the FIFO method is:

   1. Agent 2 with 5 FXRP.
   2. Agent 1 with 5 FXRP.

Payment Reference

The system generates a unique payment reference for each agent participating in a redemption. The agent must include the payment reference in a memo field when the underlying payment transaction is made.

The payment reference ensures the payment transaction cannot be used by another entity that might claim to have made the payment on the underlying chain. Additionally, if the payment time expires before payment is done, the redeemer can prove that no payment with that reference was made.

Lots

Every redemption through the standard redeem method must be made in a positive integer of lots. Lots serve the following purposes:

• They prevent underlying transaction fees from exceeding minting or redemption fees.
• They restrict large numbers of very small redemption tickets from being submitted, which would increase gas costs.

Therefore, the amount of tokens in a lot (the lot size) varies for each underlying chain. For example, on the XRPL chain, a lot can be as small as 10 XRP because transaction fees are low. On the other hand, on the Bitcoin chain, lots might need to be as big as 0.25 BTC or more because transactions are far more expensive.

Over time, the lot size can be updated to reflect price fluctuations of the underlying asset. Only a governance call can update the lot size, and it can be updated only by a limited amount per day.

Methods such as redeemAmount and redeemWithTag allow redeeming amounts that are not whole lots; see Redeem Any Amount.

Dust

Some processes generate a fractional number of lots:

• On minting, part of the minting fee may be minted as the FAsset fee to the collateral pool. This value is usually less than 1 lot.
• When the lot size is changed, redemptions close only a positive integer of lots of each redemption ticket, which leaves the remainder unredeemed.

These amounts, known as dust, cannot be redeemed through the standard redeem method because it requires a positive integer of lots.

In such cases, the generated dust is not included in any redemption ticket. Instead, each agent's dust is accumulated until the dust amounts to a whole lot. When that happens, another redemption ticket is automatically created.

Therefore, the dust can be recovered or destroyed in the following ways:

• If the dust exceeds 1 lot during minting, the part that is a whole multiple of a lot is automatically added to the created redemption ticket.

• If an agent does not mint any FAssets for a while but the lot size changes and several redemptions occur, enough dust might accumulate to more than 1 lot.

  In this case, the part that is a whole multiple of a lot can be converted to a redemption ticket by request. To prevent an inactive agent making FAssets less fungible, this request can be made by any address.

• Self-closing can work with fractional lots, so it can be used to remove dust.

• Liquidation can work with fractional lots too, so it can also be used to remove dust.

Self-redemption

Agents can also act as users and redeem FAssets from their own vaults. This process is called self-redemption or self-closing, and it is simplified because payment on the underlying chain is not required.

As shown in the following process, agents can self-redeem for any reason, including to prevent liquidations, as it reduces the amount of FAssets the agent is backing.

1. An agent sends FAssets to their account.
2. FAssets are burned.
3. The collateral that was backing those assets is released.
4. The underlying collateral is released and can be withdrawn from the underlying address later.

The self-redeemed amount is not limited to a positive integer of lots and can be less than one lot, which makes self-closing ideal for redeeming an agent's dust.

What's next

Learn more about the different components and processes involved in FAssets - collateral, minting, liquidations, and Core Vault.

For developer resources, explore our FXRP address, minting, and redemption guides to get started with FAssets integration.