Beersy

Brandon Cryderman / HandCash

Beered by 0 people

21 standards · 5 topics

Also credited as Brandon Cryderman

What Brandon writes about

Wallet

6
  • 154

    Pluggable Backup Services for BRC-140 Share Vaults

    If you want a backup copy of a wallet's secret key material held outside the wallet, there has never been a common way for different storage providers to speak the same language. Without it, a wallet app would have to hand-roll a custom recovery API for every provider, and users would end up trusting a single company with their entire recovery path. This makes it possible to spread recovery pieces across independent services that all understand the same request and response shapes.

    2026
  • 208

    Vault Sub-Accounts

    Someone running a wallet app for several separate purposes, a personal account, a shop, a brand, normally ends up juggling a different seed phrase or backup for each one, which is tedious to secure and easy to lose track of. This describes a way for one single backed-up secret to safely produce as many separate, unlinkable accounts as needed, each behaving like its own independent wallet, and for all of them to be found again from that one secret alone.

    2026
  • 213

    Native UTXO-Chain Coins in a BRC-100 WalletDraft (proposed number, not a BSVA assignment)

    Wallets that show balances for chains other than BSV, like Litecoin or Dogecoin, usually have to trust a custodian holding wrapped tokens or an indexer reporting balances and confirmations, putting a third party between the user and their money. This makes it possible for a wallet to hold and spend coins on another chain directly, verifying everything itself from raw transaction bytes and its own copy of that chain's block headers.

    2026
  • 214

    Wallet Asset ProfilesDraft (proposed number, not a BSVA assignment)

    A wallet can hold many different kinds of value, like Bitcoin, other coins, collectable items, and tokens, but there has been no shared rule for keeping them separate when an app asks to see or spend them. Without that, an app given permission to spend a small amount of Bitcoin could end up able to grab an item or token it was never meant to touch, and apps have no clean way to ask a wallet what kinds of value it even holds before trying.

    2026
  • 249

    Vault Account Holding Across DevicesDraft (proposed number, not a BSVA assignment)

    A wallet backup can be restored on more than one phone or laptop, but if two devices both treat the same account as theirs to spend from, they can each build a payment from coins the other has already spent, and the blockchain will only accept one of them. Before this, the only fix was asking a server before every payment, which is slow and breaks when offline. This makes it possible to keep a vault's accounts spread across several trusted devices safely, without that per-payment check.

    2026
  • 250

    Device Login and RecoveryDraft (proposed number, not a BSVA assignment)

    Signing in to a self-custodial wallet on a new phone is normally stuck between two bad options: either some server holds enough of your secret to log you in (so it can also be hacked or coerced into logging someone else in), or you have to manually copy a long recovery phrase between devices every time. This makes it hard to offer a simple "sign in with your email" experience without quietly giving a company the power to open your wallet.

    2026

Payments

1
  • 256

    Cross-Chain Atomic Swaps Between WalletsOpen

    Moving coins between two different blockchains usually means trusting an exchange or bridge to hold your funds while the swap happens, and that middleman can freeze, lose, or steal them. This describes a way for two wallets to trade coins across chains directly, so that either the trade completes for both sides or each party simply gets its own coins back, with nobody ever holding the other's funds and neither side needing to be online at the same moment.

    2026

Tokens

10
  • 147

    1Sat Ordinals Basket Profile for BRC-46 / BRC-100

    Wallets and applications both need to agree on where collectible items live and how they are described. This reserves the group name and pins down what may go in it and how it is labelled.

    2026
  • 150

    1Sat Provenance Remittance for Basket `1sat`

    Proving an item is the genuine one, and not a copy of it, means tracing it back to where it began. This packages that trail so it can be checked without asking any service for help.

    2026
  • 156

    Latched 1Sat Provenance for Basket 1sat (Withdrawn)Withdrawn by the author. Do not implement.

    Sometimes a standards document gets written, then the people behind it change plans and stop building what it described. If nothing marks that document as dead, other developers can still find it, assume it works, and build against something that was never finished or safe to use. This document exists to stop that from happening by pointing everyone to the real, working approach instead.

    2026
  • 163

    BSV-21 Basket Profile for BRC-46 / BRC-100

    Fungible tokens on BSV live as special one-satoshi outputs, but nothing told wallets where to keep them, how to tell them apart from ordinary payment coins or collectibles, or what information to pass along when sending them to another wallet. Without agreement, one wallet's token transfer could arrive at another wallet looking like junk, with no amount, symbol, or icon attached, and apps could not reliably list a user's token balances. This standard gives wallets a shared box and labeling convention so tokens move between them cleanly.

    2026
  • 165

    P1Sat Permission Scheme for Basket `1sat`

    Apps that want to show or move collectable items (like NFTs) in a wallet face a bad choice: either dump everything into one basket where any app that gets access sees the user's whole collection, or invent a separate storage bucket for every collection, creator, or app. There was also no clean way to ask a wallet "let me spend this one specific item" without accidentally granting access to spend anything in the collectables basket. This leaves users exposing more than intended, or developers building fragile one-off storage schemes.

    David Case2026
  • 251

    Bitcoin Native Tokens (BNT): Definition and Wallet DutiesOpen

    A wallet balance just shows a number. It does not tell you whether the asset behind that number can be frozen, blocked, or reversed by someone other than the person holding it. Developers end up guessing, or reading custom code, to find out whether a token truly belongs to its holder or is secretly on a leash held by its issuer. This gives a clear, checkable way to tell those two kinds of token apart just by looking at the script.

    2026
  • 252

    Short Proofs for Bitcoin Native TokensOpen

    Proving that a token transfer is legitimate normally means checking its entire history back to the moment the token was created, and that history gets longer every time the token changes hands. For a token that has traded thousands of times, a wallet would have to download and verify thousands of past transactions just to accept one payment. This makes long-lived, actively traded tokens slow and expensive to receive, no matter how simple the actual transfer is.

    2026
  • 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.

    2026
  • 254

    Market Offers and Direct Swaps for Wallet AssetsOpen

    Right now, if you want to let someone sell a digital item or token from their wallet without being online when it sells, you either trust a central listing service to enforce the price and fee, or you risk a buyer taking the item for free by reusing a badly-signed listing. This describes a way to make an offer that can only ever be completed by paying exactly what the seller asked, with no index holding any keys and no way to skip the agreed fee.

    2026
  • 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.

    2026

Overlay services

1
  • 257

    Proving Service for Bitcoin Native Tokens, 1Sat Ordinals and BSV-21Open

    A token can change hands hundreds of times, and each new holder is expected to check the token's full history back to its creation to be sure it is real. For a long-lived token that check gets slower and more expensive every time it trades, to the point where a wallet on a laptop simply cannot do it fast enough. This makes it possible to hand a newcomer a single small proof instead of the whole history, while still letting them verify it themselves rather than trust whoever gave it to them.

    2026

Peer to peer

3
  • 246

    Session Upgrade: BRC-33 Messages over WebRTPayDraft (proposed number, not a BSVA assignment)

    Two wallets that are both online right now still end up sending chat messages, item deliveries and coordination notices through a slow relay server meant for offline delivery, which adds delay for no reason. At the same time, two installs of the same account (like a phone and a laptop) have no good way to tell each other apart or talk directly. This fixes both by letting online wallets message each other straight over an existing direct connection instead.

    2026
  • 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.

    2026
  • 248

    Offline Issuer Identity PackagesDraft (proposed number, not a BSVA assignment)

    When a wallet shows you who issued an item, all it usually has is a public key, a string of letters nobody recognizes. Getting a real name and picture for that key has meant trusting a web link that can rot or change, or calling out to a server every time you want to show it, which fails the moment that server is down or lying. This makes it possible to show a trustworthy name and image for an issuer using only data the wallet already has, with no live lookup required.

    2026

Search Beersy

Search standards by number, title, author or topic