BRC-514: MAP State Resolution over a 1Sat Chain

[rohenaz]

This pull request:

Proposes a new standard by creating a new markdown file in the appropriate directory and requests discussion and assignment of a BRC number.

Drafted by Fable 5 in an advisory capacity, at the owner's direction.

Companion document: BRC-514 Companion
The fold traced across a worked example, the four nested orderings, CLEAR's backward reach, and the deployed-versus-specified ledger with file-level evidence.

What it specifies

How a MAP key's value is resolved across a record's revisions. MAP has no ownership model and its only context mechanism (SELECT <txid>) addresses a transaction. BRC-160 declines the question twice — "full MAP encoding: specified separately", and "latest vs origin … is an application concern".

Implementations have resolved it the same way for years: merge each revision in chain order, last write wins. It was written down nowhere, so "the value in effect at the tip" had no normative definition, and BRC-515 had to carry an interim rule it could not conform to.

The document defines:

• Revision order — chain order origin → tip, then script order within an output, then ::: order, then push order. Repeated key in one SET: last pair wins.
• An ordered-set state model — every key holds an ordered set; SET gives a single member, ADD appends with byte-equality dedup.
• How each of MAP's six commands folds, including CLEAR's per-transaction voiding, which is the only command not expressible as an operation on accumulated state.
• Resolution at a point, and history — so a consumer can ask what a record looked like at any revision, not only now.

Authorization is out of scope, deliberately

Ownership and permissioning belong to whatever system owns the asset. This document resolves state given a set of authorized writes; it does not decide which writes are authorized. Two rules only: fold nothing unauthorized, and document your model. 1Sat spend authority and AIP/Sigma identity signatures are named as available models, and a system using neither is free to define its own.

The 1Sat chain is described as the canonical sequencing substrate, because that is what supplies the ordering — a revision is the chain-link output's own MAP data and nothing else in the transaction. Other substrates must supply their own total order.

Deployed versus new

§8 separates the two, verified against 1sat-stack/pkg/ordfs. Deployed: the chain-order last-write-wins merge, link-output-only revisions, seq-addressed history, piped-segment ordering, and the partial-SET rule. Folds SET alone — map.go matches MapCmdSet and nothing else. The other five commands' fold, the ordered-set model and ::: ordering are specified here for the first time. Deployed practice is incomplete rather than divergent.

Numbering

514, below 515 because 515 depends on it and the corpus convention is that every numbered cross-reference points to an earlier document.

Open questions for review

1. ADD dedup versus duplicates. The draft models keys as ordered sets, warranted by MAP's own JS Set analogy. A plain list with duplicates is closer to "append" but makes DELETE ambiguous — remove one occurrence or all?
2. Bare REMOVE/DELETE in-chain. BRC-503 says both are "used with SELECT"; the draft makes SELECT optional inside a chain, where the revision's own record is the obvious context. Defensible, but an extension of 503's letter.
3. SELECT target breadth. 514 allows SELECT to name any earlier revision; BRC-515 binds writers to the spent tip's txid. Compatible — 515 writers are 514-conforming — but a reviewer should confirm what a 515 indexer does with a SELECT naming the origin.
4. Whether SET-only resolvers get a named conformance subset, since that is what is deployed today.

Follow-ups this surfaced

• BRC-515 has been corrected in PR #3: its CLEAR gloss said the command erases a record's entire state, where MAP voids only the named transaction's writes. Its interim resolution paragraph is now a citation to this document.
• opldotdev/MAP README defects: the DELETE example omits <key> (BRC-503 has it right), and SELECT's command list reads "SET | REMOVE | ADD | REMOVE". Worth a small PR.