Step 1 – Generate Your Pre-Deploy & Deploy Files
Fill in the fields:
- Ticker name
- Receiving address
- Supply and Mint limit
- Self-mint: choose true or false
- Decimals (e.g., 0, 2, 8)
Click Generate to create your predeploy.json and deploy.json.
Step 2 – Inscribe the Pre-Deploy
Step 3 – Link the Deploy with Parent-Child
- Go back to Unisat Inscribe (Files).
- Upload your
deploy.json.
- Select Parent-Child option.
- Enter the Inscription ID of your confirmed
predeploy.json.
- Make sure the receiving address matches the same wallet that submitted the predeploy.
Step 4 – Success
Once confirmed, you’ve successfully deployed your BRC-2.0 token. 🎉
Notes
- BRC-2.0 requires a parent-child inscription flow to add anti-snipe verification.
- This guide uses Unisat Wallet, which makes the process straightforward.
- Advanced users can also use an Ord node, but it’s more complex and costly.
- The Froggys tool is open-source; the code is available on GitHub.
Self-Mint Rules
- If
self_mint is set to true, only the wallet that deployed the token can mint it.
- If it’s left blank or set to anything else, it defaults to
false, meaning anyone can mint.
Snipe Protection (Pre-Deploy)
- To stop others from guessing or front-running your ticker, BRC-2.0 uses a pre-deploy step.
- Pre-deploy hides your ticker by publishing a hash (ticker + salt + your wallet’s pkScript).
- Later, when you deploy, you reveal the ticker and salt — the system checks if the hash matches.
- This ensures only the wallet that did the pre-deploy can complete the deploy.
Parent-Child Inscriptions
- The deploy inscription must be a child of your pre-deploy inscription.
- This links them together and proves ownership.
- Deploys must wait 3 blocks after the pre-deploy, so the network can confirm everything.
👉 For the full technical details, see the official spec: 6-byte namespace proposal
