Add Support for Two New FDC Types
Flare Foundation Proposals to the Infrastructure Provider Management Group (MG) to add two new FDC types to both Flare mainnet and the Songbird canary-net, specifically aimed to improve the FAsset system and upgrade to FAssets v1.3
Background:
With the acceptance of FIP.12 / STP.09, which outline the process for adding new attestation types in section 2.1.1, we ask the MG to review the proposal, comment, and subsequently vote on each
Proposed New FDC Types (XRP only):
XRPPayment
XRPPaymentNonexistence
Motivation:
The new FDC types will enable additional functionality for FAssets, specifically FXRP. The upgrades include minting FXRP directly with the Core Vault, reducing minting processing times, eliminating the need for two transactions to mint, and increasing bridging capability. More information about these FAsset system updates can be found in section 4.2 of the recently published Flare Improvement Proposal FIP.16
Ruleset Defining New FDC Types:
The new FDC types specified above are XRPL-native versions of the older generic Payment and ReferencedPaymentNonexistence, which relied on a standard payment reference abstraction, and instead expose XRPL-specific fields directly. The new XRPL-specific attestation types use the same general structure for the request, response, and proof as the generic versions. The key difference is in the requestBody and responseBody schemas, as follows:
- XRPPayment vs generic Payment
request body:
-
The requestBody for the generic payment attestation types included inUtxo and utxo fields (which would default to 0 for non-UTXO chains), which are no longer used in the new types.
-
A proofOwner field is added, which is an address authorized to use the proof, where applicable.
response body:
The XRPPayment request type removes the standardPaymentReference and oneToOne fields of the response body of the generic Payment attestation types, and instead relies on XRPL-native payment metadata:
-
Presence of the MemoData field of a transaction is included as a bool hasMemoData in the response body.
-
Raw bytes of the first memo’s MemoData field (if present) in the transaction are included in the firstMemoData field in the response body.
-
A new bool hasDestinationTag is used to track if the transaction has a destinationTag.
-
For transactions having a destinationTag, this is included in the destinationTag field of the response body.
Additionally, sourceAddressesRoot is also removed and a direct sourceAddress field is added.
- XRPPaymentNonexistence vs generic ReferencedPaymentNonexistence
The aim of the ReferencedPaymentNonexistence requests is to prove that within a search window, no payment matching the requested criteria occurred before the window overflowed. The XRPL-specific request uses native XRPL criteria, such as memoData and tags for performing the search.
request body:
-
The generic ReferencedPaymentNonexistence request searches the blockchain using a requested chain-agnostic normalized payment reference (stored in the standardPaymentReference field), and the root of the Merkle tree of the source addresses (sourceAddressesRoot field).
-
The XRPL-specific request relies instead on MemoData and destinationTag fields of XRPL transactions. As for the XRPPayment request, these are stored in the new fields: checkFirstMemoData, firstMemoDataHash, checkDestinationTag, and destinationTag. Additionally, the constraints based on source address sets (i.e. sourceAddressesRoot) are removed entirely.
The response bodies for the two attestation types are the same.
Software Requirements:
The technical lift for Entities to add support for the two new FDC types will require updates to existing XRP indexer/verifiers. Additional migration documentation will be provided in the coming days.
Links to Code Repositories:
https://github.com/flare-foundation/verifier-indexer-api/releases/tag/v1.5.0-rc.0
https://github.com/flare-foundation/verifier-xrp-indexer/releases/tag/v1.1.0-rc.0
https://github.com/flare-foundation/multi-chain-client/releases/tag/v4.5.0-rc.2
Base Fees for New FDC Types:
20 FLR (Flare), 20 SGB (Songbird)
Process:
-
An official request posted in an open forum (Discourse) for MG members to voice their support or raise any concerns.
-
The Flare Foundation will then initiate transactions from the polling contracts on both Flare and Songbird for MG members to cast on-chain votes either for or against adding the two new FDC types.
-
Voting is acceptance-based and requires at least 66% participation amongst all eligible MG members and more than 50% of the votes cast in favor of the proposals to meet quorum.
-
If quorum is met, the Flare Foundation will move forward with the addition of the two new FDC types on Flare and Songbird respectively.
