# Minting

> Understand how minting works in FAssets.

> For the complete documentation index, see [llms.txt](/llms.txt). Markdown versions of documentation pages are available by appending `.md` to the page URL.

Source: https://dev.flare.network/fassets/minting

Minting FAssets is the process of wrapping underlying tokens from connected blockchains into FAssets to be used on the Flare blockchain. For XRP, users mint by creating a single payment on the XRP Ledger to the [Core Vault](/fassets/core-vault), then an executor finalizes the mint on Flare. This feature is currently available only for XRP.

## Minting Resources[​](#minting-resources "Direct link to Minting Resources")

### Minting dApps[​](#minting-dapps "Direct link to Minting dApps")

You can mint FAssets on either of the following dApps:

-   [https://fasset.oracle-daemon.com/flare](https://fasset.oracle-daemon.com/flare)
-   [https://fassets.au.cc](https://fassets.au.cc)

### Supported Wallets[​](#supported-wallets "Direct link to Supported Wallets")

Wallet

![Flare](/img/ui/flare-icon.light.svg)![Flare](/img/ui/flare-icon.dark.svg)

![XRPL](/img/ui/xrp-icon.light.svg)![XRPL](/img/ui/xrp-icon.dark.svg)

Notes

[Bifrost](https://bifrostwallet.com/)

✅

✅

Supports both networks. [Tutorial](https://www.youtube.com/watch?v=1lETSE9YlXQ)

[Ledger](https://www.ledger.com/)

✅

✅

Hardware wallet supporting both networks. [Tutorial](https://youtu.be/WkdWZJJBem0)

[Luminite](https://luminite.app/)

✅

✅

Integrated FAssets support with DeFi utilities

[OxenFlow](https://oxenflow.io/)

✅

✅

Available via iOS app

[MetaMask](https://metamask.io/)

✅

EVM wallet for Flare transactions

[Rabby](https://rabby.io/)

✅

EVM wallet for Flare transactions

EVM Wallets with [WalletConnect](https://walletconnect.com/)

✅

Any EVM-compatible wallet supporting WalletConnect

[Xaman](https://xaman.app/)

✅

XRPL wallet only. [Tutorial](https://youtu.be/-3TPLIszPUc)

info

To complete the minting process, you may need:

-   A **Flare-compatible wallet** (e.g., MetaMask, Bifrost, Luminite) for receiving FXRP and interacting with FAssets smart contracts.
-   An **XRPL-compatible wallet** (e.g., Xaman, Bifrost, Luminite) to send XRP to the [Core Vault](/fassets/core-vault) with the correct memo or destination tag.

Wallets that support both networks (Bifrost, Ledger, Luminite, OxenFlow) provide the most seamless experience.

## How It Works[​](#how-it-works "Direct link to How It Works")

The minter creates a payment transaction on the underlying chain (XRPL) to the [Core Vault](/fassets/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`](/fassets/reference/IAssetManager#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](/smart-accounts/overview) personal account and the XRPL memo carries a custom instruction (`0xFE` or `0xFF`), the executor instead calls [`executeDirectMintingWithData`](/fassets/reference/IAssetManager#executedirectmintingwithdata) (for hash-commitment memos) or [`executeDirectMinting`](/fassets/reference/IAssetManager#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](/smart-accounts/custom-instruction#failure-handling). See [Finalizing on Flare](#finalizing-on-flare) for when to use each entry point.

## Fees[​](#fees "Direct link to Fees")

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 [Minting Troubleshooting](/fassets/troubleshooting/minting-troubleshooting#irreversible-failures) 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[​](#identifying-minting-parameters "Direct link to Identifying Minting Parameters")

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

### Destination Tag[​](#destination-tag "Direct link to 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[​](#memo-field "Direct link to 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[​](#minting-tag-manager "Direct link to Minting Tag Manager")

The `MintingTagManager` contract on Flare manages the reservation and ownership of XRPL destination tags for 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`](/fassets/reference/IMintingTagManager#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[​](#executor-restrictions "Direct link to Executor Restrictions")

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

1.  **Tag-based:** The tag manager's [`setAllowedExecutor`](/fassets/reference/IMintingTagManager#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[​](#finalizing-on-flare "Direct link to 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`](/fdc/attestation-types/xrp-payment) proof.

### `executeDirectMinting`[​](#executedirectminting "Direct link to executedirectminting")

The standard finalization path for minting. It mints FAssets to the recipient encoded in the XRPL destination tag or memo.

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

Use this function for:

-   Plain 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](/smart-accounts/memo-field-custom-instruction)).

On success, the executor receives the executor fee, and the contract emits the [`DirectMintingExecuted`](/fassets/reference/IAssetManagerEvents#directmintingexecuted) event. See the full reference in [`executeDirectMinting`](/fassets/reference/IAssetManager#executedirectminting).

### `executeDirectMintingWithData`[​](#executedirectmintingwithdata "Direct link to executedirectmintingwithdata")

Used when the XRPL memo commits to a user operation by hash only ([`0xFE` custom instruction](/smart-accounts/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`](/fassets/reference/IAssetManager#executedirectmintingwithdata) and [Failure Handling](/smart-accounts/custom-instruction#failure-handling).

## Rate Limits[​](#rate-limits "Direct link to Rate Limits")

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

Limit

Description

[`directMintingHourlyLimitUBA`](/fassets/reference/IAssetManager#getdirectmintinghourlylimituba)

Hourly minting cap

[`directMintingDailyLimitUBA`](/fassets/reference/IAssetManager#getdirectmintingdailylimituba)

Daily minting cap

[`directMintingLargeMintingThresholdUBA`](/fassets/reference/IAssetManager#getdirectmintinglargemintingthresholduba)

Threshold above which a minting is considered "large"

[`directMintingLargeMintingDelaySeconds`](/fassets/reference/IAssetManager#getdirectmintinglargemintingdelayseconds)

Automatic delay for large mintings

To inspect the live limiter and pre-flight a mint against the current windows, use the [Check Minting Limits guide](/fassets/developer-guides/fassets-mint-limits) along with [`getDirectMintingHourlyLimiterState`](/fassets/reference/IAssetManager#getdirectmintinghourlylimiterstate), [`getDirectMintingDailyLimiterState`](/fassets/reference/IAssetManager#getdirectmintingdailylimiterstate), and [`getDirectMintingsUnblockUntilTimestamp`](/fassets/reference/IAssetManager#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[​](#large-minting-delay "Direct link to Large minting delay")

A mint is **large** when its underlying amount is **strictly greater than** [`directMintingLargeMintingThresholdUBA`](/fassets/reference/IAssetManager#getdirectmintinglargemintingthresholduba). On Flare mainnet, that threshold is currently **4M XRP** with a **2 hour** fixed delay ([`directMintingLargeMintingDelaySeconds`](/fassets/reference/IAssetManager#getdirectmintinglargemintingdelayseconds)).

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](/fassets/core-vault) until an executor successfully finalizes the mint.

When an executor first calls [`executeDirectMinting`](/fassets/reference/IAssetManager#executedirectminting) for a large mint:

1.  The contract emits [`LargeDirectMintingDelayed`](/fassets/reference/IAssetManagerEvents#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`](/fassets/reference/IAssetManagerEvents#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 Minting Limits guide](/fassets/developer-guides/fassets-mint-limits) for off-chain pre-flight logic.

### Delayed minting flow[​](#delayed-minting-flow "Direct link to Delayed minting flow")

Delayed mintings emit [`DirectMintingDelayed`](/fassets/reference/IAssetManagerEvents#directmintingdelayed) or [`LargeDirectMintingDelayed`](/fassets/reference/IAssetManagerEvents#largedirectmintingdelayed) instead of `DirectMintingExecuted`, with an `executionAllowedAt` timestamp.

Governance can temporarily bypass the **hourly and daily** limiter via [`unblockDirectMintingsUntil`](/fassets/reference/IAssetManager#getdirectmintingsunblockuntiltimestamp) 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](https://github.com/flare-foundation/flare-viem-starter)) that:

1.  Watches for [`DirectMintingDelayed`](/fassets/reference/IAssetManagerEvents#directmintingdelayed) and logs `executionAllowedAt` when rate limits bind.
2.  Keeps polling until [`DirectMintingExecuted`](/fassets/reference/IAssetManagerEvents#directmintingexecuted) confirms FXRP was minted.

Important

Do not treat [`DirectMintingDelayed`](/fassets/reference/IAssetManagerEvents#directmintingdelayed) event as a failure or send a second XRPL payment for the same mint. For delay retry steps and cap failures, see [Minting Troubleshooting — Delays](/fassets/troubleshooting/minting-troubleshooting#delays).

## Video Tutorial[​](#video-tutorial "Direct link to Video Tutorial")

What's next

To continue your FAssets development journey, you can:

-   Mint without a reserved tag using [memo-based minting](/fassets/developer-guides/fassets-mint).
-   Check current limits and fees in [Operational Parameters](/fassets/operational-parameters).
-   Troubleshoot common minting failures in [Minting Troubleshooting](/fassets/troubleshooting/minting-troubleshooting).
-   Learn about [redemptions](/fassets/redemption), [collateral](/fassets/collateral), and [Core Vault](/fassets/core-vault).