BRC-164

Output Identity Tags for BRC-100 Wallets

Apps that hold onto a specific piece of wallet money often need to find that exact one again later, after the app restarts or when it's time to spend it, but there was no agreed-on way to label a single stored item so it could be looked up directly instead of scanning through everything. This gives apps a simple, predictable label to stamp on an item so it can be found again with an ordinary lookup.

David Case11 Aug 2026changed 13 Aug 20263 min read

Reference for an AI

Everything an assistant needs to answer questions about BRC-164 accurately, including what it depends on.

Why: Apps holding a specific wallet output needed a reliable, queryable way to find and target that exact row again later without new wallet features.
What: BRC-164 is a tagging convention for BRC-100 wallets that uses an id:<key> output tag as a stable, queryable handle for one held output.
How: A wallet or tool writes an id:<key> tag onto an output the same way it writes any other BRC-100 tag, then later calls listOutputs with that exact tag to find or spend that row again.

What this lets you do

Stamp a stable id:<key> tag on any held output when it's created
Query listOutputs with a full id:<key> tag to fetch one specific row
Reuse the returned key later to target that same output for a spend
Keep id: keys separate from token id, origin, or ownership tags
Reload app state after a restart by looking up outputs by their stamped key

Written by claude-sonnet-5 from the specification text. Where the two differ, the original is correct.

The specification

Read the original

Abstract

This specification defines a tag convention for BRC-100: an output tag prefix id: that carries a stable list key for a held output. Callers use it with ordinary listOutputs tag filters. It does not change the BRC-100 request or response shape, and it does not require special wallet storage behavior beyond normal tags.

Motivation

Basket profiles and applications often need a stable handle for one wallet output — reload after restart, target a spend, correlate UI to storage — without scanning every row.

Stamping that handle as a normal, queryable tag under a short prefix makes listOutputs the lookup API, without new BRC-100 fields or pseudo-tag peel paths.

Specification

Tag form

This specification uses tags of the form:

id:<key>

The prefix is exactly id: (lowercase, ASCII).
<key> is a non-empty string chosen by the writer that stamps the tag (wallet or tool).
Because reference BRC-100 clients commonly trim and lowercase tags before store and match, writers SHOULD use a case-insensitive alphabet for <key> (e.g. lowercase hex or decimal digits), and readers MUST treat tag equality as case-insensitive.

Tags beginning with id: are used for this output list-key role.

Meaning

id:<key> identifies a held output row for list and spend targeting inside that wallet storage.
It is not a global asset id, token id, origin, outpoint, remittance field, or proof of ownership.
Encoding of <key> is defined by the writer (e.g. decimal storage primary key, UUID). Only that writer must round-trip it.
Uniqueness: <key> SHOULD be unique among that wallet’s held outputs (or a documented narrower scope such as per basket).
Stability: for a given held row, id: SHOULD remain stable for the life of that row (including unproven / unmined outputs if they are listable).

Behavior

id: is an ordinary BRC-100 output tag. No special listOutputs semantics, peel, inject, or foreign-tag overwrite is required of generic wallet storage.

Conforming tools and wallets that adopt this profile SHOULD:

Stamp id:<key> on the output when the row is created or first taken into custody (same path as any other tag).
Query with a full id:<key> tag via ordinary tags / tagQueryMode.
Treat id: as their own list key vocabulary — not as token id, origin, or on-chain identity. Basket profiles that need those notions use their own tags (e.g. bsv21:<tokenId>, origin:…).

Applications MAY read id:<key> from listOutputs (with includeTags) and reuse it in later filters or app state.

Out of scope

Changing BRC-100 method schemas or WalletWire encodings
Basket names, token economics, or provenance proofs
Requiring a particular key generation algorithm (UUID, counter, storage PK encoding, …)
Mandating peel/inject or other non-tag storage paths in reference wallets

Security considerations

Not authentication — Knowing id:<key> only helps address a row inside a wallet that already authorized listOutputs / spend for that basket.
Authority — The tag is only as trustworthy as the storage that stamped it. Counterparty remittance is not a substitute for the holding wallet’s (or tool’s) own stamp.
Case folding — Assume tags are lowercased in storage; do not put case-sensitive secrets in <key>.
Ambiguity — id: is short and may appear in other informal tag sets. Writers that need a stricter namespace MAY document a longer key form; this BRC does not reserve exclusivity of the two-letter prefix beyond the list-key meaning above for adopters.

References

BRC-100 — Unified Open BSV Wallet-to-Application Interface
BRC-37 — Basket and Custom Instructions Extension for Bitcoin Outpoints
BRC-46 — Wallet Transaction Output Tracking (Output Baskets)
BRC-153 — Action Reference Labels for BRC-100 Wallets
BRC-147 — 1Sat Ordinals Basket Profile

Was this helpful?