Agent documentation index: llms.txt. Markdown versions of documentation pages are available by appending .md to the page URL.
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.

When the recipient is a Flare Smart Account personal account and the XRPL memo carries a custom instruction (0xFE or 0xFF), the executor instead calls executeDirectMintingWithData (for hash-commitment memos) or executeDirectMinting (for inline memos) to mint FXRP and dispatch the user operation atomically. If that call reverts, no FXRP is minted, and the underlying XRP remains at the Core Vault until recovered — see Failure Handling. See Finalizing on Flare for when to use each entry point.

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. See Direct Minting Troubleshooting for prevention steps.
  • 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):

  1. 8-byte prefix: 0x4642505266410018 (DIRECT_MINTING)
  2. 4-byte zero padding: 00000000
  3. 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 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.

Finalizing on Flare​

After the XRPL payment confirms, an executor finalizes the mint by calling one of two AssetManager entry points with an FDC XRPPayment proof.

executeDirectMinting​

The standard finalization path for direct minting. It mints FAssets to the recipient encoded in the XRPL destination tag or memo — no prior collateral reservation is required.

function executeDirectMinting(IXRPPayment.Proof calldata _payment)
    external payable;

Use this function for:

  • Plain direct mints to an EOA or contract address (32-byte or 48-byte memo, or destination tag).
  • Smart-account flows where the full PackedUserOperation is carried inline in the XRPL memo (0xFF memo field custom instruction).

On success, the executor receives the executor fee, and the contract emits the DirectMintingExecuted event. See the full reference in executeDirectMinting.

executeDirectMintingWithData​

Used when the XRPL memo commits to a user operation by hash only (0xFE custom instruction). The executor supplies the ABI-encoded PackedUserOperation in the _data parameter alongside the proof.

function executeDirectMintingWithData(
    IXRPPayment.Proof calldata _payment,
    bytes calldata _data
)
    external payable;

See executeDirectMintingWithData and Failure Handling.

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

To inspect the live limiter and pre-flight a mint against the current windows, use the Check Direct Minting Limits guide along with getDirectMintingHourlyLimiterState, getDirectMintingDailyLimiterState, and getDirectMintingsUnblockUntilTimestamp.

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.

Large minting delay​

A direct mint is large when its underlying amount is strictly greater than directMintingLargeMintingThresholdUBA. On Flare mainnet, that threshold is currently 4M XRP with a 2 hour fixed delay (directMintingLargeMintingDelaySeconds).

Large-mint delay is independent of the hourly and daily windows. Even with full window headroom, a 5M XRP payment is delayed — it does not revert, and the underlying XRP stays at the Core Vault until an executor successfully finalizes the mint.

When an executor first calls executeDirectMinting for a large mint:

  1. The contract emits LargeDirectMintingDelayed with executionAllowedAt = block.timestamp + directMintingLargeMintingDelaySeconds.
  2. No FXRP is minted yet.
  3. After executionAllowedAt, the executor calls executeDirectMinting again with the same FDC proof.
  4. The contract emits DirectMintingExecuted and FXRP is credited to the recipient.

If hourly or daily limits also apply, the contract uses whichever rule pushes executionAllowedAt furthest into the future. See the Check Direct Minting Limits guide for off-chain pre-flight logic.

Delayed minting flow​

Delayed mintings emit DirectMintingDelayed or LargeDirectMintingDelayed instead of DirectMintingExecuted, with an executionAllowedAt timestamp.

Governance can temporarily bypass the hourly and daily limiter via unblockDirectMintingsUntil to drain a backlog after manual review. That bypass does not skip the large-mint delay — amounts above the threshold are still held for directMintingLargeMintingDelaySeconds.

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

Integrators should use a helper such as waitForDirectMintingOutcome (provided in flare-viem-starter) that:

  1. Watches for DirectMintingDelayed and logs executionAllowedAt when rate limits bind.
  2. Keeps polling until DirectMintingExecuted confirms FXRP was minted.
Important

Do not treat DirectMintingDelayed event as a failure or send a second XRPL payment for the same mint. For delay retry steps and cap failures, see Direct Minting Troubleshooting — Delays.

Video Tutorial​

What's next

To continue your FAssets development journey, you can: