# Direct Minting > Understand how direct 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/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](/fassets/minting#minting-process) of standard minting. This feature is currently available only for XRP. ## 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` on the Flare side to finalize the mint. The executor is paid a fee upon successful completion. ## Fees[​](#fees "Direct link to 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[​](#identifying-minting-parameters "Direct link to Identifying Minting Parameters") There are two ways to specify the minting recipient and executor in a direct 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 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`](/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. ## Rate Limits[​](#rate-limits "Direct link to Rate Limits") Direct 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 Direct Minting Limits guide](/fassets/developer-guides/fassets-direct-minting-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. 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`. ## Video Tutorial[​](#video-tutorial "Direct link to Video Tutorial") What's next To continue your FAssets development journey, you can: - Read the protocol details in [Direct Minting](/fassets/direct-minting). - Mint without a reserved tag using [memo-based direct minting](/fassets/developer-guides/fassets-direct-minting). - Check current limits and fees in [Operational Parameters](/fassets/operational-parameters).