Proof-of-Indexing Hash-to-Mint Tokens
Distributing a new token fairly means finding work worth doing rather than work that only burns electricity. This ties minting to proof that real indexing work was performed.
9 standards
Issuance and minting
Where a token comes from: who is allowed to create it, what the first output looks like, and how a holder can later prove that the thing they hold descends from that creation.
Also searched as mint, deploy, issue, hash-to-mint, supply.
Filed under
9 standards, spread across 4 of the 12 topics.
Start with
BRC-227
Frictionless On-Chain Onboarding via Pre-Funded Claimable Tokens
Giving someone their first on-chain item requires them to have a wallet and coins, which they do not yet have. This lets a publisher fund it in advance so the recipient becomes the owner by clicking a link.
Filed under Applications
Standards about this
Issuance and minting is the main subject of these 2.
117 227 Frictionless On-Chain Onboarding via Pre-Funded Claimable Tokens
Giving someone their first on-chain item requires them to have a wallet and coins, which they do not yet have. This lets a publisher fund it in advance so the recipient becomes the owner by clicking a link.
Standards that touch it
These are about something else, and deal with issuance and minting on the way.
92 Mandala Token Protocol (Withdrawn)Withdrawn by the author.
Token schemes tend to accumulate rules until they are hard to implement twice the same way. This keeps issuing, transferring, recovering and redeeming a token as small as it can reasonably be.
161 BSV-21 Fungible Tokens (JSON / Legacy)
Issuing a fungible token, like a points balance or stablecoin unit, on Bitcoin used to mean inventing your own tracking scheme or relying on a global name registry that anyone could squat or collide with. There was no agreed way to say "this balance belongs to this token, forever" without a central ledger, and no standard way for an issuer to mint more supply later without rewriting the rules each time. This standard fixes the token's identity to the transaction output that created it and lets ordinary wallet transactions carry and mint balances.
162 1Color
Different fungible token systems on Bitcoin SV have each invented their own way of writing an amount and a token identifier onto a transaction output, so wallets and contracts have had to support multiple incompatible formats just to move the same kind of balance. That means extra parsing code, extra bugs, and scripts that cannot easily inspect a token output the way they can a plain payment. A shared, script-readable layout means any wallet or contract can check and build these outputs the same way, every time.
209 1Color Minimal Resource Profile
Some apps want a wallet to track and move a named digital item, like a ticket or a badge, without the wallet pretending to guarantee how many exist, who issued them, or whether one is the "real" one. Before this, a wallet either had to apply full token rules it didn't need, or drop structure entirely and lose any way to recognize the item at all. This gives apps a lightweight way to say "sign this thing and identify it" without any false promises about scarcity or ownership history.
247 Identity-Key Issuer AttestationDraft (proposed number, not a BSVA assignment)
Anyone could mint a digital asset on Bitcoin and slap a name on it, but a person holding that asset later had no reliable way to know who actually made it or whether a signature claim was real or copy-pasted from somewhere else. Without a fixed, checkable link between an asset and its creator, buyers were trusting unverifiable labels, and marketplaces had no consistent way to show provenance. This makes it possible to prove, cryptographically and tied to the exact transaction, which wallet identity issued a given asset.
253 Issuer-Permissioned Tokens (IPT): Countersigned Tokens and ItemsOpen
Some digital assets, like stablecoins, tickets or handles, only have value because an issuer stands behind them and can refuse a bad transfer or freeze a bad actor. Before this, that kind of control lived outside the transaction itself, in some separate system a wallet had to check, which made it unclear whether a payment was really final or could still be reversed later.
255 Bitcoin Native Tokens (BNT): Compact FormatOpen
Some token designs on Bitcoin require a recipient to check every past transfer back to the very first issuance of the token before trusting a payment, and each of those historical records repeats a long identifying code plus a full public key for every step. That repetition makes the proof a recipient has to check grow large and expensive with every hop, and makes combining several received amounts pull in even more history. A smaller way to write the same kind of token lets wallets and recipients do that same trustless checking with far less data moving around.
Usually read alongside
Concepts that keep appearing on the same standards as this one.
Was this helpful?