# Virtual Mint ## Overview radFi Virtual Mint is a feature designed to solve the problem of capital leaving the onchain bitcoin ecosystem during token mints. The current token minting experience exports millions of dollars in BTC from the community to miners as transaction fees. The Virtual Mint feature solves this problem. It mirrors the exact user experience of etching and minting tokens on mainnet, however, the minting takes place off chain in a backend server that operates a virtual mempool. Users participate in mints just as they would on mainnet, but instead of spamming the network and burning sats on fees, we utilize the committed BTC for a liquidity pool on the radFi AMM and make it available for trading. This solves the problem of liquidity exportation while still maintaining key benefits of a free and open mint. Our three goals are: * Liquid Markets * Retain liquidity within the Bitcoin ecosystem while ensuring that liquidity is readily available to trade for new tokens * Transparency and Equal Access * Enable sustainable token launches via fair and open minting, creating a better distribution of tokens across holders through our time-based auctions * Reward the Community * Reward token creators and initial minters who don’t sell by sharing trading fees earned from the locked liquidity position ## Etching When a user wants to etch a rune and start a mint, the following occurs: 1. Some parameters are selected by the user, and some are fixed default values controlled by radFi 1. Fixed parameters 1. Percent allocation to liquidity pool = 20% 2. Premine percentage = 100% 3. Decimals = 2 4. Token supply = 1,000,000,000 5. Number of tokens per mint transaction = 10,000 2. Flexible parameters 1. Display Ticker 1. This section is used by the radFi frontend and is not included onchain. This could be considered a "nickname", or shorter version of the rune's ticker 1. ![](https://lh7-rt.googleusercontent.com/docsz/AD_4nXc6MpDYxjBCp2ambdj1FJfifeTluGbNIgdrv6ZGxd9jyQCMbJPPrthiZuZnoHwreP2Ael0YAjqVxie_bGFQwZNEjPPwDVZmHP1nWVlztyiHrpm7RyXJ551fSNTOQ5I1PwlvzHtH?key=D9wZk4k5SLqFOBRNE6SGOA) 2. Rune Ticker 3. Token Image 4. Symbol 1. (e.g. 😂) 5. Description 6. Socials (optional) 1. Twitter 2. Telegram 3. Website 2. The user submits the etch transaction and the 100% premine is directed to radFi-controlled wallets 3. The virtual minting process begins ## Minting & Virtual Mempool radFi operates a virtual mempool to process all virtual mints. It is a single, global virtual mempool for all virtual mints occurring on the platform; each individual mint does **not** have its own mempool. radFi integrates a Bitcoin API requesting Bitcoin blocks and their timestamps. When a Bitcoin block is mined on mainnet, radFi also mines a virtual block. When a user wants to participate in a mint, they transfer the amount of BTC they want to spend along with data that includes the rune they want to mint, how many mints, and the amount of BTC. The server then adds the transaction data to the virtual mempool. The BTC spent is deducted from the user’s Spendable Balance on their radFi Trading Wallet, just as it would be for a swap. Once a Bitcoin block is mined on mainnet, we mine a virtual block mimicking the same rules as Bitcoin mainnet: * The maximum number of mint requests per block is 4,000 * The 4,000 requests with the highest bids are included in the block * Only messages broadcast prior to the timestamp of the Bitcoin block are eligible * Any messages not included in the latest block stay in the virtual mempool When the minting period has ended (either from time or from minting out), radFi takes the following steps: 1. All remaining mint requests for that rune are dropped from the virtual mempool 2. Check if the total fees committed by users exceeds the *minLiq* parameter 1. If it does not exceed *minLiq*, BTC paid by users is refunded and made available to be claimed back by the users to their trading wallet and the process ends 3. Calculate refund amounts and make available for users to claim 1. Refund amount = btcSpent - btcConfirmed 2. Users pay the fee for the refund claim tx 4. Calculate amount of tokens owed to each user and initiate batch transfers to distribute 1. If the time limit (5 days) and *minLiq* (0.08 BTC) are met, but the token does not mint-out (less than 800M tokens are minted), the remaining unminted tokens are distributed pro-rata based on amount minted to those that participated in the mint 5. Pair the committed BTC with the remaining tokens (200M) and supply as liquidity in a new radFi pool ## Diamond Hands Diamond Hands is a unique feature that adds game theory mechanics to the radFi launchpad. At the end of a mint, tokens are distributed to users. All unsold, untransferred tokens are automatically put into Diamond Hands status and will start receiving their share of rewards from the locked LP, **so long as the user minted at least 1M tokens.** Once sold or transferred, those tokens can never regain Diamond Hands status. This creates an interesting scenario where the users that hold the longest can end up getting a growing portion of ongoing trading fees. Your share of the Diamond Hands allocation continues to grow as other users sell or transfer their tokens. **Walkthrough Example** A new token is launched through radFi’s virtual mint with a total supply of 1,000,000,000 tokens. After the mint ends, 20% is allocated to the AMM liquidity pool. The remaining 800,000,000 tokens are distributed to participants. Participant allocations: * Alice minted 1M tokens * Bob minted 2M tokens * Carol minted 3M tokens * All other tokens are held by users that minted less than 1M tokens (the minimum requirement for Diamond Hands status) **Status breakdown**: 6M tokens are in Diamond Hands status receiving 33.33% of trading fees * Alice has 1M tokens with Diamond Hands status * Bob has 2M tokens with Diamond Hands status * Carol has 3M tokens with Diamond Hands status After launching: * Alice sells 200k tokens, then buys back 300k tokens * \*Note\* - buying tokens off the secondary market does not increase your Diamond Hands allocation * Bob sells 500k tokens * Carol holds all her tokens without selling or transferring **Status breakdown:** 4.5M tokens are in Diamond Hands status receiving 33.33% of trading fees * Alice: still holds 1.1M tokens, but **none are eligible for diamond hands** because she is below the 1M tokens held since mint requirement * Bob: 1.5M tokens retain Diamond Hands status * Carol: 3M tokens retain Diamond Hands status ## Parameters **Token Supply** * 1,000,000,000 for all tokens etched on our platform **Mints per block** * 4,000 mints maximum will be accepted into a virtual block, and a virtual block is mined every time a Bitcoin block is mined **Virtual Block Inclusion Rules** * The 4,000 mints with the highest bids will be included each block. In the case of a tie, timestamp is used. **Minimum price per token** * The minimum price per token you can submit during the minting process is 0.01 sats **Tokens per mint** * Each submitted mint is for 10,000 tokens **Mints per transaction** * A transaction can be submitted for 1 mint minimum and 1,000 mints maximum **Minimum Liquidity for a Launched Token** * For a token to launch, it must reach a minimum of 0.08 BTC committed **Launched pool parameters** * When a token is launched, the BTC committed is paired with 20% of the token supply and supplied at a full range liquidity position. The fee tier of the pool is set to 1.00%. **Diamond Hands Required Holdings** * In order to be eligible for Diamond Hands Rewards, you must mint, hold, and not transfer at least 1,000,000 tokens **Revenue from Locked LP** * Token Deployer = 50.0% * Diamond Hands Holders = 50.0% --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.radfi.co/virtual-mint.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.