Skip to main content

Direct Minting

Direct minting allows users to mint FAssets by creating a single transaction on the underlying chain, bypassing the multi-step collateral reservation process of standard minting. This feature is currently available only for XRP.

How It Works​

The minter creates a payment transaction on the underlying chain (XRPL) to the Core Vault address, not to an individual agent's address. The transaction identifies the minting parameters (recipient and executor) through either a destination tag or a memo field.

An executor then calls executeDirectMinting on the Flare side to finalize the mint. The executor is paid a fee upon successful completion.

Fees​

Direct minting charges two fees, both deducted from the underlying payment amount:

  • Minting fee: A percentage of the received amount (in BIPS), with a minimum floor. This fee is paid to a governance-configured fee receiver. If the payment is smaller than the minimum minting fee, no FAssets are minted and the entire payment goes to the fee receiver.
  • Executor fee: A flat fee in the underlying asset, paid to the executor who finalizes the minting. The minting fee takes priority: if the payment only covers the minting fee, the executor receives nothing.

Identifying Minting Parameters​

There are two ways to specify the minting recipient and executor in a direct minting payment.

Destination Tag​

XRPL transactions natively support a destination tag, a 32-bit integer. The MintingTagManager contract on Flare acts as a registry that maps these destination tags to Flare-side parameters: the minting recipient and the preferred executor.

The tag on the XRPL side and the tag registered in MintingTagManager on Flare are the same tag. The Flare contract gives the XRPL tag its meaning in the FAsset system. This path is convenient for repeated use, such as an exchange or service that regularly mints.

Memo Field​

Instead of a tag, the minter can encode the minting parameters directly in the memo field on the XRPL payment. There are two supported formats:

32-byte memo (recipient only):

A standard direct minting payment reference that encodes only the 20-byte recipient address. Anyone can execute, as no executor is specified.

48-byte memo (recipient and executor):

  1. 8-byte prefix: 0x4642505266410021 (DIRECT_MINTING_EX)
  2. 20-byte recipient address
  3. 20-byte executor address

If the executor address is the zero address, anyone can execute.

No reservation is needed for either format, but the memo must be constructed for each payment.

Minting Tag Manager​

The MintingTagManager contract on Flare manages the reservation and ownership of XRPL destination tags for direct minting.

  • Users reserve destination tags by paying a reservation fee in native currency (FLR/SGB). The fee exists because the XRPL destination tag space is limited to 32-bit integers, and without a cost, someone could squat on all available tags.
  • Tags are assigned sequentially. The user always receives the next available tag.
  • The contract implements the ERC-721 (NFT) interface, so reserved tags can be transferred or resold.
  • Tag owners can set a minting recipient with setMintingRecipient and a preferred executor with setAllowedExecutor. Executor changes are not immediate: the new executor becomes active after a 10-minute cooldown to protect in-flight FDC proofs.
  • On initial reservation and tag transfer, the recipient resets to the new owner and the executor resets to the zero address.

Executor Restrictions​

Executors can be restricted in three ways depending on the minting method:

  1. Tag-based: The tag manager's setAllowedExecutor method defines the allowed executor. If set to the zero address, anyone can execute.
  2. Memo-based: The 48-byte memo format encodes the executor address directly. The 32-byte memo format does not specify an executor, so anyone can execute. If the executor address in the 48-byte format is the zero address, anyone can also execute.
  3. Smart account: The smart account manager may restrict the executor. The asset manager passes every request through.

If the preferred executor does not act within othersCanExecuteAfterSeconds, anyone can execute the minting.

Rate Limits​

Direct minting has multiple rate-limiting safeguards to protect against compromises, such as FDC exploits.

LimitDescription
directMintingHourlyLimitUBAHourly minting cap
directMintingDailyLimitUBADaily minting cap
directMintingLargeMintingThresholdUBAThreshold above which a minting is considered "large"
directMintingLargeMintingDelaySecondsAutomatic delay for large mintings

Rate limits throttle rather than reject. When limits are hit, further mintings are delayed proportionally to the accumulated backlog. Large mintings above the threshold are delayed independently by a fixed duration.

Delayed mintings emit the DirectMintingDelayed event instead of DirectMintingExecuted, with an executionAllowedAt timestamp. Governance can unblock delayed mintings via unblockDirectMintingsUntil, but only for past timestamps and after manual review.

If a preferred executor's minting is delayed, their exclusive execution window restarts from executionAllowedAt.

What's next

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