Beersy

Open Protocol Labs

Beered by 0 people

5 standards · 1 topic

Tokens

5
  • 159

    1Sat Ordinals — Single-Satoshi Tokens and Origin Tracking

    A single satoshi, the smallest unit of bitcoin, can be moved around like any other coin, but there was no agreed way to treat one specific satoshi as a unique, trackable item that keeps its identity as it passes from wallet to wallet. Without that, you cannot build things like collectibles or one-of-a-kind tokens directly on bitcoin transactions, because every coin looks fungible and interchangeable. This gives that single satoshi a permanent name and a way to prove where it has been, so it can act like a non-fungible token.

    David Case2026
  • 160

    1Sat Ordinals — Inscription Envelopes

    A tiny on-chain token can prove it is unique and traceable, but on its own it carries no real content, it cannot hold a picture, a document, or app data. Developers needed a standard way to attach that content directly to the token so wallets and apps can find and display it without inventing their own format.

    David Case2026
  • 161

    BSV-21 Fungible Tokens (JSON / Legacy)

    Issuing a token that behaves like money on Bitcoin used to mean either racing to grab a unique ticker name or building a custom system for tracking who owns how much. There was no simple, shared way to say "this transaction output holds 500 units of token X" that wallets and marketplaces could all read the same way, and no clean way to let an issuer keep minting more supply later without breaking that shared format.

    David Case2026
  • 162

    BSV-21 Fungible Tokens (Binary)

    Fungible tokens on Bitcoin SV have needed either a global ticker (which causes naming collisions) or a JSON inscription that scripts can't easily read or build. Without a way to encode token identity and balance directly in script, wallets and covenants can't compose token logic with ordinary spend conditions like multisig or P2PKH. This makes it possible to carry a token balance in a UTXO using plain script pushes, so contracts can check and build token outputs without parsing any inscription format.

    David Case2026
  • 176

    BSV-21 — Validity Proofs

    Someone hands you a token payment, maybe several outputs from one transaction, and you need to be sure it's genuinely the token it claims to be, for the right amount, without querying a central index you have to trust. Because these tokens can be split and merged from many parent transactions, the history behind a single payment can branch in ways a simple chain of receipts can't capture. Without a defined way to package and check that branching history, a receiver either trusts a claim blindly or has no practical way to verify it offline.

    David Case2026

Search Beersy

Search standards by number, title, author or topic