Derived Collectibles

Abstract

This document specifies scores: inscribed, immutable rules from which a collectible's appearance is derived rather than stored, so that the same object is a different object at a different block height and in different hands.

Derivation is the chain's own primitive and this document adds nothing to it. A public key is derived from a private key, an address from a public key, a transaction identifier from a transaction, a root from a set of leaves, a block from a search. Every one of those is cheap forward and infeasible backward, and every one is verified the same way: not by inspecting a record but by recomputing the derivation and comparing. A work under this document is verified in exactly that manner. Its state is not asserted by anybody; it is recomputed from the score, the height, and the work's own lineage, and two parties who disagree recompute until they find where they diverged.

Two families of input are defined. The clock is the chain read as a metronome: height and the intervals it divides into. The record is the chain read as an accretion: the mint, every transfer since, who held it, for how long, how often it moved, and what its holders chose to add. A score maps both onto layers, palettes and positions.

The document's governing claim is that derivation yields approximation and never proof. The chain settles the past probabilistically, an indexer witnesses rather than establishes, a date inferred from a height is an estimate, and a price is mostly invisible. Section 3 makes that a discipline rather than a disclaimer: every derived quantity carries a stated confidence class, a client renders the class alongside the value, and a work may render its own uncertainty, so that a freshly transferred piece is visibly not yet settled and resolves as its transfer buries.

No new token, transfer, or custody mechanics are introduced. Objects are held and moved by the 1Sat Ordinals stack as profiled in BRC-147, their lineage is followed per BRC-150 and BRC-156, and where a holder is named rather than keyed it is a BRC-169 handle. Score and mark type identifiers are derived from strings printed in section 2.7, in the registry-free manner of BRC-169 section 4.5, because there is no allocator and there is not going to be one.

Introduction

Bitcoin is a metronome and a katamari.

A metronome is the small device a musician sets going before they play, and all it does is emit a bare, countable pulse that everybody in the room hears at the same instant.

The metronome is the block. Roughly every ten minutes a beat lands, every listener hears the same one, and the beats are numbered. That numbering is the only clock on which two strangers who share nothing else already agree, which is what makes it worth building a temporal artwork on: an object that changes on height changes at the same moment for everybody, without a server telling them so. The count is exact. The tempo is not, and section 4.1 is careful about the difference, because almost every mistake available in this design is made by treating a beat as ten minutes.

A katamari is the ball you push around in Katamari Damacy (Namco, 2004), a game built on one mechanic: everything the ball touches sticks to it and nothing ever comes off, so it begins the size of a marble, then picks up coins, then cats, then cars, then houses, and every one of them is still visibly stuck to it at the end.

The katamari is what the chain does with what it touches. It rolls in one direction only, whatever it passes adheres, and nothing is ever set back down, so an object living on the chain does not simply have a history filed away somewhere else: it carries that history stuck to its own surface, and anybody can measure how much of it has accumulated. A file copied between two computers arrives identical and unaccompanied. A collectible transferred between two keys arrives with the transfer recorded, the previous holder still named, the interval it sat unmoved still countable, and the whole of that available to a stranger's client without asking either party. The record is not metadata attached to the object. It is the object's shape.

Both are derivations, and derivation is the only primitive underneath either of them.

Bitcoin has two one-way functions and everything else is those two applied over and over. Scalar multiplication on secp256k1 turns a private key into a public one; SHA-256 turns bytes into a digest. Both are cheap in one direction and infeasible in the other, which is what makes them useful for agreement between parties who do not trust each other: a value that anybody can recompute and nobody can invert needs no authority to vouch for it. Custody is a derivation you cannot reverse. An address is a derivation of a derivation. Proof of work is derivation by search, which is why a block cannot be computed and can only be looked for. And verification, throughout, is re-derivation: Simplified Payment Verification does not consult a record of inclusion, it recomputes a merkle root from a path and compares, and BRC-168's selective disclosure recomputes a commitment from a value and a salt and walks to a root that was published before the conversation began. The idiom is always recompute and compare.

This document applies that idiom to a collectible, which has so far been exempt from it. A stored image on a chain is a foreign object: an assertion parked inside a system in which every other value is recomputable. A derived collectible is native. Its state is a computation any stranger can repeat, in any decade, from the score and the chain.

The second thing derivation gives is more interesting and less often said. Derivation is lossy, and it does not stop at the picture. There are four derivations here, not three: chain facts derive state, state derives a render, and a render derives a reading, which happens in a person and is nobody's to specify. Each stage loses something and none can be inverted. You cannot recover a score from a picture any more than you can recover a private key from an address, and you cannot recover from a reading what the work was. That is what Sol LeWitt meant by the instructions being the work and the drawing being a version of it; what Eno meant by a system rather than a recording; and what Longplayer demonstrates the hard way, having been rebuilt more than once in a quarter of a century because a performance is always an approximation of a score and the machinery of performance rots faster than the score does.

So the honest description of what a work under this document offers is not certainty about an artwork. It is a derivation anybody can repeat, an error term stated rather than hidden, and a reading that remains the viewer's own. We approximate the work. We do not arrive at it. Section 3 is where that stops being a sentiment and becomes a requirement.

Motivation

A collectible today is a picture and a receipt. The picture is bytes that do not change, and the receipt is a chain of transfers nobody renders. The interesting half is thrown away.

Four properties are available on a chain and are not being used.

A shared clock with no clockkeeper. Anything scheduled off wall-clock time needs somebody's clock, and a work that phones a server to ask what time it is has made the server a party to the artwork. Height is a fact both the artist and the collector can look up, and it is monotonic, public, and free. It is also the only such fact: this document uses it in preference to timestamps everywhere the choice arises, and section 4.1 says why the alternative is worse than it looks.

A provenance that can be read by the work itself. Every collectible already carries a complete, public, tamper-evident record of everywhere it has been, and in every deployed system that record is a table on a marketplace page. Nothing renders it. A work that reads its own record can make holding legible: a piece that visibly wears, accumulates, ages, or quiets according to what was actually done with it, where "actually done with it" is recomputable by whoever is looking rather than asserted by whoever is selling. This is the half of the design that most changes what a collectible is, and it is the half with the sharpest failure mode, because some provenance facts cost real money to produce and others cost a transaction fee. Section 6.2 separates them and is blunt about which is worth building on.

Coordination by derivation rather than by registry. This corpus already runs on the pattern. BRC-42 and BRC-43 derive keys from protocol and key identifiers rather than from a directory; BRC-169 section 4.5 derives its certificate type identifiers from printed strings, because BRC-52 defines the type as opaque bytes and no BRC defines an authority over them; BRC-145 derives a typed content anchor with the type inside the digest, explicitly so that anybody can introduce a type without asking; BRC-87 establishes no registry at all and leaves naming to agreement. A derived collectible belongs to that family and section 2.7 joins it rather than inventing an allocator.

Rules are smaller than renders, and they survive better. A hundred-year artwork cannot be a video file, because nothing will decode it. It can be a page of arithmetic and a handful of inscribed assets, if the arithmetic is specified tightly enough that a reimplementation is possible from the specification alone. That is not a claim that this document achieves longevity, and Limitation 9 refuses the claim explicitly. It is a claim about which of the two has a chance.

What this is not for

It is not a way to change what somebody bought. A score is fixed at mint and this document gives nobody a way to edit it afterwards, including its author. An evolving work is one whose rules were published before the collector agreed to them and whose state moves within those rules; a work whose rules can be rewritten by the artist is a subscription with a picture on it. Section 2.5 makes immutability structural rather than a promise, and section 9 requires a client to show a collector the whole schedule of what the work will do before they buy it.

It is not a mechanism for scarcity theatre. Nothing here mints, prices, ranks, or grades. A score may read the record and it may not score it, and no client may narrate it: sections 6.5 and 6.6 forbid a rating of a holder and forbid a caption interpreting one, because a leaderboard built out of provenance is a machine for manufacturing provenance and an adjective attached to it is a stranger's reading passed off as a chain fact.

It is not a substitute for storing the work. A score referencing assets that live on somebody's web server is a work that ends when the bill goes unpaid, and calling it on-chain because its rules are on-chain is the most common dishonesty available in this design. Section 5.4 requires the distinction to be disclosed per asset and refuses to pretend the two are equivalent.

It is not proof of anything. A rendering is not evidence, and section 3.4 says so as a requirement. What the chain supports is a recomputation; a picture is the far end of a one-way function and establishes nothing about what went into it.

Prior Art

Six bodies of work bear on this. The first supplies the epistemics, the next two the mechanism, the fourth the artistic argument, the fifth is the closest relative and the one this document is most often mistaken for, and the sixth is a warning nobody in this field has yet answered.

Probabilistic settlement. The original Bitcoin paper does not claim that a transaction becomes irreversible. It gives the probability that an attacker with a given share of hashpower catches up from a given depth, and that probability falls exponentially without ever reaching zero. Six confirmations is a bound on plausibility, not a proof of anything, and Simplified Payment Verification (BRC-9) is that bound made portable: a merkle path plus a chain of headers, re-derived by the verifier. Everything in section 3 of this document is an application of that stance to properties of an artwork, and the stance is worth naming as prior art rather than presented as caution, because it is the reason a chain can be relied on at all. A system that states its error term can be checked. One that claims certainty cannot.

The block schedule as a source of properties. Ordinals assign every satoshi a rarity from its position in the issuance schedule: the first satoshi of a block, of a difficulty adjustment period, of a halving epoch, and of the cycle where the two coincide. That is the construction of section 4.2, arrived at first and by a different route, and it establishes the useful half of the idea: a property derived from the schedule needs no oracle, no signature and no registry, because every client recomputes it and none can disagree. What it does not do is evolve. A satoshi's rarity is fixed at issuance, which is correct for a rarity and leaves the temporal case open.

On-chain composition and provenance on BSV. BRC-45 established the UTXO as the token, and the 1Sat Ordinals stack built the deployed collectible on top of it: BRC-147 profiles custody into a wallet basket, and BRC-150 and BRC-156 specify how a client follows one object's lineage back to its origin, which is the read section 6 depends on entirely. BRC-224 is the nearest structural neighbour: a composition expressed as a small manifest referencing independently owned components rather than as one opaque file, which is the same architectural bet this document makes about layers. BRC-226 demonstrates that terms can be made to travel with an object across transfers by consensus rather than by convention, and is the mechanism the companion reserved in section 10 would reach for. BRC-113 is cited for the shape of its verification, which is a single merkle proof against a genesis rather than a walk along a lineage, and which is the cheapest known answer to "is this the object it says it is". BRC-60 is the corpus's document on state advancing along a chain of events, which is what a work under this document is, and the difference is worth stating: there a transition happens because a party creates a transaction, while here the state moves with the chain whether anybody acts or not, so there is no event to index and nothing to miss.

Generative and instruction-based art. The claim that the rules are the artwork and the render is a performance of it is not this document's. Sol LeWitt's wall drawings were sets of instructions executed by other people, and the instructions were the work; the drawings were versions of it. Vera Molnar, Georg Nees and Manfred Mohr were parameterising composition in the 1960s, and Brian Eno's generative music, from Discreet Music through 77 Million Paintings, is a fifty-year argument that a piece can be a system rather than a recording. What all of them supply is the answer to the objection that a computed artwork is not a work, and they are the reason section 2.5 puts the score rather than any particular frame at the centre of the object. They also supply the fourth derivation: LeWitt's drafters produced different walls from one instruction, and nobody thought the instruction had been violated.

Chain-native dynamic collectibles. Four systems are close enough to be worth distinguishing carefully.

Art Blocks fixes a work's parameters from the minting transaction hash and never changes them, which is the strongest available guarantee about what a collector owns and deliberately gives up evolution. Async Art split a work into a master and separately owned layers, each holder able to change their own layer's state, and is the closest prior art to sections 5 and 7: it establishes that distributed control over a composition is workable and that the interesting question is what a holder may change rather than whether they may. Its difference from this document is where the change comes from. There, a layer moves because its owner chose; here, it moves because the chain did, and the owner's choice is confined to the bounded mark of section 7. EulerBeats derived audio from a seed and made the derivation the whole of the artwork, which is the precedent for the sound companion section 10 reserves rather than for anything specified here. Terraforms holds an evolving state entirely on chain and advances it on block progression, which is the closest thing to section 4 that has actually shipped.

The product category around all of these is where the honesty problem lives. "Dynamic NFT" in current usage most often means an image whose metadata a server rewrites, sometimes on an oracle's word, and there is no way for a holder to tell that from a derived collectible by looking. The difference is not aesthetic and it is not enforced by any of the systems above: it is whether the state is recomputable by a stranger from public facts, or asserted by a party who could assert something else tomorrow. Every requirement in sections 2 and 3 exists to make that difference legible, which is why this document specifies the derivation in more detail than the artwork.

Very long duration, and the thing nobody has solved. John Cage's Organ2/ASLSP has been playing in Halberstadt since 2001 on a 639-year schedule; Jem Finer's Longplayer has been running since 1999 on a thousand-year one; Katie Paterson's Future Library seals a manuscript a year until 2114. All three are the ambition of this document's century-scale properties, and all three have met the same wall, which the chain does not remove. Longplayer has been through several complete migrations of the machinery that performs it, because the hardware and software it was written for stopped existing on a timescale of a decade or two rather than a century. Read that as evidence for the fourth derivation rather than as a failure: a performance approximates a score, migration is the normal condition of a long work, and what survives is the thing that can be re-derived. Limitation 9 takes it as the governing constraint.

The accretion metaphor in the Introduction is borrowed from Katamari Damacy, cited there and in the References.

Specification

The key words MUST, MUST NOT, SHOULD, SHOULD NOT and MAY are to be interpreted as described in RFC 2119. They are used where interoperability or a collector's ability to recompute a claim actually breaks; the rest of this document describes a mechanism.

Throughout, "handle" and "resolve" have the meanings given in BRC-169 sections 2.1 and 5.7, and "lineage" means the chain of transfers established by BRC-150.

One word is reserved out of this document. Nothing here is a proof and nothing here proves anything, with the single exception of a merkle path, which proves inclusion. A client MUST NOT use "proof", "proven", "verified true", or a synonym about a state, a render, a provenance quantity, or a price. The available words are recomputed, re-derived, witnessed, estimated, and asserted, and section 3 assigns them.

1. Terminology

• Work: one collectible object, held as a 1Sat output per BRC-147 and identified by its origin, the outpoint at which it was minted.
• Score: the immutable rules from which a work's state is derived. Inscribed once, at mint, per section 2.5, and serialised per section 2.6 and typed per section 2.7.
• Derivation: a computation from stated inputs that any party can repeat and no party can invert. The document's only mechanism.
• Shared state: the values a score derives from chain facts alone, at a stated height. Identical for every client. Section 2.2.
• Local state: values derived from shared state plus the declared viewer inputs of section 2.3. Identical for every client given the same inputs.
• Reference rendering: a work's state with every viewer input at its neutral value, per section 2.3(4). The view works are compared and priced in.
• Presentation: how a state is drawn. Never an input to anything. Section 2.4.
• Reading: what a viewer takes from a render. The fourth derivation, per section 2.1, and outside this document's authority.
• Confidence class: how well a derived value is known, from the five of section 3.1.
• Clock inputs: the chain facts of section 4, derived from height.
• Record inputs: the chain facts of section 6, derived from the work's own lineage.
• Layer: one element of the composition, with a z-order and a rule selecting what occupies it. Section 5.
• Mark: a bounded, permanent addition made by a holder. Section 7.
• Evaluation height: the height at which a state is derived. Every state is stated with one, per section 2.8.
• Retrospective state: a state derived at a past height, per section 2.9. Labelled as such, and keyed on an owner key rather than on a handle.

2. Derivation

2.1 The four derivations

A work reaches a viewer through four derivations. Each is lossy, none is invertible, and this document has authority over the first two, an opinion about the third, and nothing to say about the fourth.

The line that matters most is not between the chain and the viewer. It is between reproducible and unrepeatable. A value derived from the chain can be recomputed by a stranger in a hundred years. A value derived from the chain and a stated timezone can be recomputed by a stranger in a hundred years who is told the timezone. A value derived from whatever a browser happened to report cannot be recomputed by anybody, including the viewer, tomorrow. Stages 1 and 2 are on one side of that line and stage 3 is on the other, which is the whole of the reason they are separated.

Stage 4 is in the table because leaving it out is how a specification comes to believe it has produced meaning. It has not. A render is where this document stops, and what a work is about is derived by a person from a picture, unrepeatably, and belongs to them. Two requirements follow from admitting it: section 3.4, which forbids treating a render as evidence, and section 6.6, which forbids a client from performing stage 4 on the viewer's behalf and presenting the result as a fact about the object.

2.2 Shared state is a pure function of chain facts

A score's shared state at height h MUST be derivable from, and only from:

1. the score itself, and any assets it commits to by digest;
2. the work's origin outpoint;
3. the evaluation height h, and the chain facts of section 4 derived from it;
4. the work's lineage up to h, and the record facts of section 6 derived from it.

Nothing else. Not a network fetch other than the ones needed to obtain 1 to 4, not an oracle, and not a random number that was not derived per section 8.2.

The property this buys is the one the whole document is for. Two clients at the same height agree; a client at a later height recomputes any earlier one; and a collector, a marketplace, a court and a stranger are all looking at the same object. A score whose every property is shared is the strongest form available under this document, and an author who does not need section 2.3 should not use it.

2.3 Local state, and the closed list of viewer inputs

A score MAY declare a property local, derived from shared state together with facts about the viewer. A beach at the collector's own sunset is a better thing to own than a beach at a height-derived sunset, and a work that can only ever be the same for everyone cannot do it. What makes it specifiable rather than merely permitted is that the inputs are enumerated and the result is still reproducible from stated values.

1. A score MUST enumerate every viewer input it reads, and each MUST be drawn from this closed list. A score MUST NOT read an input outside it, and a client MUST refuse to render a score that names one.

2. Locality is declared per property, not per work. A score MUST state, for each property it derives, whether it is shared or local, and a client MUST show a viewer which of the properties in front of them are which.

3. A local state is reproducible or it is not a state. Wherever a local state is displayed, exported, cached, or transmitted, it MUST carry the height and the value of every viewer input it consumed, per section 2.8. Two parties who disagree about a picture can then settle it by comparing inputs rather than by comparing hours.

4. Every work MUST also have a reference rendering: its state with utcOffset at 0, hemisphere at the value the score names as its default, and calendar at the first value the score enumerates. A client MUST be able to produce it, and MUST use it wherever works are compared, listed, priced, or disputed. The reference rendering is what a marketplace shows and what an appraisal argues about; the local one is what the owner looks at.

5. Local state MUST NOT feed back into shared state, MUST NOT be written on chain, and MUST NOT be used to derive any value another party is expected to recompute.

6. A score SHOULD keep its local properties to the ones that genuinely want a personal hour, and SHOULD NOT make a work's rarest or most valuable state local. A state only reachable in one timezone is a state most owners cannot reach and none can demonstrate they reached.

What this costs is worth stating where an author decides. Two collectors comparing local works see different pictures and cannot tell from looking whether the difference is the work or the hour, which is what rule 4 exists to answer. And the viewer inputs are less stable than they look: utcOffset is a function of the timezone database, which governments change and sometimes change retroactively, so the same work at the same height in the same room may render differently in two different years. That is Limitation 3, it is real, and it is the price of the effect rather than a defect in the mechanism.

2.4 Presentation reads the viewer and records nothing

Everything not covered by 2.2 or 2.3 is presentation: screen size, pixel density, available fonts, colour management, whether audio is permitted, whether the viewer has asked for reduced motion, the easing of an animation between two states. A client MAY vary all of it freely.

Presentation MUST NOT alter shared or local state, MUST NOT be recorded or transmitted as though it had, and MUST NOT be enumerated by a score. The line between 2.3 and 2.4 is that a score names its local inputs and reads them; it never names a font.

2.5 A score is fixed at mint

A score MUST be inscribed at or before the work's origin, and MUST be committed to by digest in the work's minting transaction. A client MUST verify that digest before rendering, and MUST refuse to render a work whose score does not match rather than rendering what it was served.

There is no amendment mechanism, no upgrade path, and no author key with standing to change anything. This is a refusal rather than an omission. A score is the entire description of what the buyer is acquiring, and every argument for letting an author revise it is an argument for the buyer having acquired something else. Where an author wants a new version, the instrument is a new work.

Two consequences follow and should be stated where an author will meet them. A bug in a score is permanent, and there is no patch, so a score should be published and rehearsed against real lineages before anything is minted under it. And a score that references an asset it does not commit to by digest has left a hole exactly the size of the amendment mechanism this section refuses, which is what section 5.4 is about.

2.6 The score object

A score is a JSON object. Everything a client needs in order to derive a state is in it, it is canonicalised before it is hashed, and the digest of that canonical form is what the minting transaction commits to.

A layer object:

An asset object is { "storage": "inscribed" | "external", "digest": <64 lowercase hex>, "location": <string> }, where location is required for external and optional for inscribed, and storage and digest are the labels section 5.4 requires.

Resolution is by band count, and this is the whole of the rule. For a value v and ascending bands, the index is the number of entries of bands that v meets or exceeds. So bands of length k selects among k + 1 entries, and a score whose variants, palettes or path is not exactly k + 1 long is malformed and MUST be refused. For repeat, the count is min(v / divisor, bound) in integer division. For absent, index 0 renders nothing.

Canonicalisation and the digest.

1. A score MUST contain only objects, arrays, strings and integers. Floating-point numbers, null and booleans MUST NOT appear, which keeps section 8.1's arithmetic rule true of the score itself and keeps canonicalisation to the part of RFC 8785 that two implementations cannot disagree about.
2. scoreDigest is SHA-256 over the RFC 8785 canonical form, encoded UTF-8.
3. The minting transaction MUST carry a BRC-48 PushDrop output whose pushed fields, in order, are the ASCII string derived-collectibles, the ASCII string 1, the 32-byte scoreDigest, and a location: either the outpoint of the inscription carrying the score bytes, or the ASCII string inline where the score is the work's own inscribed content.
4. A client MUST recompute scoreDigest from the bytes it fetched and MUST refuse to render on a mismatch, per section 2.5. This is the document's own thesis applied to its first step: the score is not trusted, it is re-derived and compared.

Version. A client meeting a version it does not implement MUST treat the work as unrenderable and say so, and MUST NOT render the subset of layers it recognises. Silently ignoring an unrecognised field produces a picture the author did not write, which is worse than no picture, and the same reasoning appears in BRC-146 section 2.1. The cost is that a version bump is a hard break, so a later revision wanting a gradual path should add optional fields within version 1.

Ceilings. These are limits on the score, not on the client, and they exist because a bound every client picks for itself is a bound two clients disagree about. A client that refused a work another client rendered would break the determinism of section 2.2 as surely as a floating-point derivation would.

A score exceeding any ceiling is malformed and MUST be refused rather than truncated. The values are claimed rather than derived from anything, in the manner of BRC-146 section 2.1's sixteen-entry cap, and they are chosen so that a marketplace page holding a hundred works does a bounded amount of work per work.

2.7 A score is typed by derivation, not by allocation

A score and a mark each carry a 32-byte type identifier, and both are derived from a printed string rather than assigned by anybody:

type = base64( SHA-256( ASCII derivation string ) )

1. Both values are normative. An implementation MUST use them and MUST NOT substitute a locally chosen constant.
2. The derivation strings carry no BRC number, and nothing else in this document carries one in a wire name either, so that a later revision does not leave the deployed vocabulary naming a superseded document.
3. The v1 suffix versions the type rather than the document. A revision changing the meaning of either object MUST mint a new type by changing the derivation string, so that objects issued under two revisions stay distinguishable and no client is ever obliged to guess which set of meanings applies.

This is BRC-169 section 4.5's construction and it is here for the same reason, which is worth stating plainly rather than treating as convention. There is no allocator of type identifiers, there is no committee that could become one, and waiting for an assignment is waiting for an event that cannot happen. A derived identifier needs no authority, is reproducible from this section alone by anybody with a hash function, and cannot be captured. It is also the smallest possible demonstration of the document's own thesis: where a value can be derived, deriving it is strictly better than being told it.

2.8 Every state is stated with a height, and with its inputs

A state MUST be accompanied by the height it was derived at, and by the value of every viewer input it consumed under section 2.3, wherever it is displayed, exported, cached, or transmitted. A state without them is not wrong, it is unfalsifiable: nobody can recompute it and nobody can say it has changed.

A cached state MUST be discarded when the tip advances past any height at which the score's own rules change a value, when any consumed viewer input changes, and on any lineage event for the work.

2.9 The work at an earlier height

Section 2.2 makes every past state recomputable, and that is worth more than a property: it is the one thing a derived collectible can do that a stored image cannot, which is to be looked at as it was. A client MAY offer such a view, and where it does:

1. A retrospective state MUST be derived at a stated height from the lineage as it stood at that height, and MUST carry that height per section 2.8. Marks made after it MUST NOT appear. This is the mistake the naive implementation makes, because marks are permanent and the obvious code renders all of them.
2. A retrospective view MUST be labelled as retrospective and MUST NOT be presented as the work's current state.
3. It MUST use the reference rendering of section 2.3(4) unless the viewer supplies viewer inputs explicitly. A past holder's utcOffset is not a chain fact and was never recorded, so a client that renders a past state in the present viewer's timezone has invented a picture nobody ever saw.
4. Confidence is not retrospective. A value that was probable when a past viewer saw it is settled now, and a client MUST render the class as it stands at the evaluation height rather than reconstructing the uncertainty of the time.

A tenure is the interval worth offering. The record gives the transfer heights, so the period during which any one key held the work is bounded and derivable, and "as it was while this key held it" is the natural request. A client offering it SHOULD offer the state at the start and at the end of the tenure, since a work that moved during a long holding did most of its moving there.

Ask it of a key, not of a handle. A BRC-169 handle is not a durable name for a party: section 2.1(4) of that document permits a handle to be released and reassigned, and its section 4.4 exists because the same handle can later resolve to a stranger. So the key in the lineage is settled and the binding from that key to a handle at that past height is not: a present resolution answers for the present, and nothing in a resolution response answers for a height years ago. A client MUST therefore key a retrospective view on the owner key, MAY label it with a handle, and MUST class that label witnessed per section 3.1. Where the handle's current binding differs from the one the client recorded, it MUST show that the name may have changed hands, exactly as BRC-169 section 4.4 requires before a value-moving action.

The honest summary is that a work can be shown as it was, and the person who held it can only be named as well as anybody can name a key. That is the fourth derivation arriving in the record: the object's history is recomputable, and who the owners were is a reading of it.

3. Confidence

Every value in this document is derived, and derived values are not equally well known. A quantity recomputed from a block buried a year deep, one recomputed from a transfer six blocks old, one an indexer reported without the client checking, a date inferred from a height, and a price nobody can see are five different epistemic objects, and a client that renders them alike has told its viewer that they are the same.

This section is the document's answer to its governing claim. Derivation yields approximation. The remedy is not to pretend otherwise but to carry the error term along with the value, in the manner of BRC-146 section 3.1's three-state verdict and BRC-169 section 6.2's insistence that an unsigned exchange rate is the sender's assertion rather than evidence.

3.1 The five classes

Every derived value MUST carry exactly one class.

settlementDepth is 100 blocks throughout this document. One constant with one value, named here so that sections 4.5 and 9.4 cannot drift apart from it, and claimed rather than derived: it is deep enough that a reorganisation of that size would be the network's problem rather than the artwork's.

Two rules make the classes real rather than decorative.

1. A derived value takes the weakest class of its inputs. A property computed from age (settled) and lastPrice (asserted) is asserted. There is no averaging and no majority: a chain of derivations is exactly as sound as the worst link in it, which is the same arithmetic BRC-169 section 8.4 applies to a delegation chain.
2. A client that cannot establish a class MUST use asserted, and MUST NOT omit the value silently. Not knowing how well you know something is a state worth showing.

3.2 Rendering the class

1. A client MUST make the class of every displayed value discoverable, and MUST distinguish asserted from every other class without requiring an interaction. The failure this prevents is a price-derived property sitting in the same visual language as an age-derived one.
2. A client MUST NOT render an estimated value in the units of an exact one. A height converted to a date is the case this arises in, and section 4.1 already forbids it.
3. A client MUST carry the class through export, transmission, and any interface built on top of a state, per section 2.8. A class stripped at the boundary is a class that existed only for the developer.
4. A client MUST NOT aggregate values of different classes into one figure without reporting the weakest, per 3.1(1).
5. A witnessed value SHOULD name what witnessed it, and SHOULD say when. This is BRC-169 section 4.2(3)'s rule about recording the time of a revocation check, arriving for a different fact.

3.3 A work may render its own confidence

A score MAY make confidence visible in the work itself, and this document recommends it.

The construction is one mechanism doing two jobs. A property derived from shallow data is probable, and a score MAY render a probable property unresolved: out of focus, undecided between two variants, thin in the mix, drawn without its final detail. As the data buries and the class advances to settled, the property resolves. A freshly transferred work is therefore visibly not yet settled, and settles over the following day.

1. Where a score does this, the unresolved and resolved forms MUST both be derived from the same state, so that resolution is a change of class and not a change of value. A property that would render differently once settled has a bug rather than a style.
2. A score MUST NOT make an unresolved state more desirable than a settled one. The reason is section 6.2's: anything a holder wants can be manufactured, and the way to manufacture an unsettled state is to keep transferring the work.
3. A client MUST NOT present an unresolved rendering as a defect, an error, or a load failure. It is the work saying what it currently knows.

What this buys is worth more than its cost. Probabilistic settlement is the single most misunderstood property of the chain the work lives on, and a collectible that goes soft on transfer and hardens over the next hundred blocks teaches it to everybody who owns one, without a word of explanation and without a warning nobody reads.

3.4 One way, and therefore not evidence

Each of the four derivations is one-way, and the consequence is a requirement rather than an observation.

1. A rendering MUST NOT be presented as evidence of a work's state, its provenance, its age, or its authenticity, and a client MUST NOT imply that it is. A picture is the far end of a one-way function: you cannot invert a render to recover a score, a record, or a height, exactly as you cannot invert an address to recover a key.
2. What can be relied on is the recomputation. A party asserting something about a work is asserting that a derivation from stated inputs yields a stated output, and the counterparty's remedy is to run it. A client SHOULD therefore be able to export the inputs of any state it displays, so that a recipient can re-derive rather than believe.
3. Where two parties derive different states, the disagreement MUST be resolvable by comparing inputs, in the order height, viewer inputs, lineage digest (section 8.3), score digest. This is why section 8.3 exists: two clients that agree on every input and differ in the output have an implementation bug, and two that differ on an input never had a disagreement about the work.

The aesthetic corollary is already in the document and is worth naming here, because it is the same property. A monotone construction, of the kind section 6.3 recommends, is a one-way function the viewer can see. Patina that deepens and never polishes out is not a decision about surfaces; it is irreversibility made visible, which is the honest rendering of handling, because handling is not reversible either.

4. The Clock

4.1 Height counts, and does not keep time

Height is exact, monotonic, and shared. The interval between heights is none of those things. The ten-minute target is a long-run average maintained by retargeting, individual intervals vary from seconds to hours, and the average itself has historically run slightly fast, so a count of blocks and a count of ten-minute periods diverge without bound.

The consequence is a rule and not a caution. Where a score expresses a duration, it MUST express it in blocks, and where a client presents a block quantity as a duration in days or years it MUST class it estimated per section 3.1 and MUST NOT present it as a date. A score that wants an event on a calendar date cannot have one; what it can have is an event at a height, and a client that renders "on 1 January 2050" from a height has invented a precision the chain does not carry.

This is the same choice BRC-146 section 2.4 makes for its notice period and for the same reason: two clients share a chain and do not share a clock.

4.2 The intervals height divides into

A score MAY read any of the following, each an integer function of h:

All division is integer division. The names are normative so that two scores mean the same thing by chainDay, and the units are deliberately named for the chain rather than the calendar: a chainDay is 144 blocks and a client MUST NOT label it as a day without qualification, for the reason section 4.1 gives.

A score MAY define its own intervals as multiples of a block. A score MUST NOT define one in seconds.

4.3 The wall clock, where it is unavoidable

Some properties are about the world rather than the chain, and a season is the obvious one. Two chain-derived timestamps exist and only one of them is usable.

A block's own nTime MUST NOT be used. It is chosen by the miner, is valid up to two hours ahead of network-adjusted time, and is not monotonic, so a score reading it can go backwards and can be pushed forwards by whoever found the block.

Median time past, the median of the preceding eleven blocks' timestamps, MUST be used instead where a score needs an approximate wall-clock. It is non-decreasing by consensus, it cannot be moved far by any single miner, and it lags real time by roughly an hour. A score reading it MUST NOT depend on a resolution finer than a day, a value derived from it is estimated per section 3.1, and a client MUST NOT render it as a clock time.

4.4 Seasons, and the refusal of an ephemeris

A score MAY derive a season from median time past by fixed UTC date boundaries stated in the score, and MUST NOT derive one astronomically.

The refusal is deliberate and worth the paragraph. An equinox is a function of the Earth's orbit, requires an ephemeris and a model of the difference between terrestrial and universal time, and two implementations of it will disagree in the minutes around a boundary, which is exactly where a work that changes on the boundary is being looked at. A specification is not entitled to an ephemeris. Fixed dates are wrong by a day or so against the astronomical event and identical in every implementation, which is the trade this document takes everywhere it appears: a stated approximation everybody shares beats an unstated precision nobody can reproduce.

A score MUST state which hemisphere its seasons are for, or declare the season local and read hemisphere per section 2.3. A work whose winter is January is a northern work, and a southern collector is entitled to know that rather than conclude the work is broken. Where the season is local, the reference rendering of section 2.3(4) uses the score's declared default hemisphere, so a listing still shows one agreed season.

4.5 Derivation by search, and what a miner can do about it

Not every derivation is a computation. A block cannot be computed, only looked for, and that difference decides which chain facts are safe to build a property on.

A score MAY derive unpredictable values from block hashes, which is derivation by search, subject to two rules.

1. A value derived from the hash of the block at height k MUST be classed probable until the tip is at least k + settlementDepth, and MUST NOT be treated as settled before that. Below that depth a reorganisation can change the hash and therefore the value. Section 3.3 is the recommended way to render the interval rather than hide it.
2. A score MUST NOT derive a value whose payoff to a miner exceeds the cost of discarding a solution, from a block that miner could be mining.

Rule 2 is the middle column of the table cashed out. Whoever performs a search sees the result before anybody else and may discard it and search again, so a trait revealed by the hash of the block confirming a mint is a trait that block's miner can grind for, and where the rare outcome is worth more than a block reward the grinding is rational rather than malicious. This cannot be checked mechanically and is stated so that an author does not learn it from a market. The safe constructions are the ordinary ones: derive from a hash fixed long before anybody knew what it would be worth, derive from the record rather than from entropy, or accept that the reveal is grindable and disclose it under section 9.

Where a score wants values unpredictable before mint and fixed forever after, the origin outpoint is the right source, and section 8.2 defines the derivation. Note where that moves the search: the minter chooses the transaction's inputs, so the minter can grind, which is cheaper than a miner's grind and usually less valuable. It MUST be disclosed under section 9.

5. Composition

5.1 Layers are ordered and the order is stated

A composition is an ordered list of layers, given back to front, so that the first entry is the furthest away and the last is nearest the viewer. Each layer names a slot in the picture and a rule selecting what occupies it.

The direction is stated because it is got wrong at once. A sky sits behind everything; a sun or a moon sits in front of the sky and behind every figure; a figure in the middle distance sits behind one in the foreground. An author listing celestial bodies as foreground has described a scene in which the moon occludes the people, which is a choice available to them and is almost never the one meant.

A worked example, back to front:

0  ground      the base scene, always present
1  horizon     substituted by season
2  celestial   sun or moon, positioned by dayPhase
3  weather     present or absent, derived per 8.2
4  distant     figures, count derived from the record per 6.1
5  near        figures, count derived from the record per 6.1
6  surface     patina, accumulated per 6.3
7  marks       holder marks, per section 7

5.2 What a layer rule may do

A layer's rule MUST resolve to exactly one of the following, and MUST resolve deterministically from state:

repeat MUST carry a bound in the score, and a client MUST refuse to render a work whose bound is absent. An unbounded count derived from a quantity that grows with the record is a work that eventually cannot be drawn, and the Security Considerations treat it as the denial-of-service surface it is.

Every enumerated set MUST be fixed in the score. A rule that can resolve to something not enumerated at mint is the amendment mechanism section 2.5 refuses.

5.3 Positions are integers on a grid

A place operation derives a position in integer units on a coordinate grid whose dimensions the score states. Interpolation, easing, and sub-unit motion are presentation and belong to the client.

The reason is section 8.1's: two implementations agreeing on integers will disagree on floating-point curves, and a work whose sun is at a slightly different height in two clients has failed the only test this document sets.

5.4 Where assets live, stated per asset

Every asset a score references MUST be committed to by digest, and MUST be labelled with one of:

A client MUST verify every asset it renders against its digest, MUST refuse to substitute an asset whose digest does not match, and MUST show a viewer which of its assets are external and how many.

The labelling is the whole of this section's contribution and it is not a technicality. A work described as living on the chain, whose sky is a URL, ends when that URL does, and the digest does not save it: a digest detects what is missing rather than supplying it. An author entitled to use external assets is not entitled to have them described as though they were inscribed, and a collector deciding what to pay is deciding partly on this.

6. The Record

This is the katamari half. Every quantity in this section is derived by following the work's lineage per BRC-150 and BRC-156, and every one of them is available to any client that can read the chain.

6.1 The provenance vector

At evaluation height h, a work's record yields:

The class column is normative and follows section 3.1(1): a property derived from any of these takes the weakest class among the ones it read. ecosystems is witnessed because resolving an owner key to a handle is somebody's answer rather than a recomputation,..

Every quantity is defined at mint, and none is a minimum over an empty set. A work with no transfers has one tenure, the one still running, so tenure, longestTenure and shortestTenure all equal age; hops is 0, hands and holders are 1, returns and marks are 0, and firstHolderHolds is true. Every work passes through that state, and a specification that leaves it open collects three answers.

hands and holders are different quantities and it is worth saying how. holders is the size of a set, so a work that goes from Alice to Bob and back to Alice has two holders. hands counts tenures, so the same work has passed through three hands. Where returns is 0 the two differ by exactly one and a score should read whichever it means; where returns is nonzero they diverge, and the mistake to avoid is reading holders for "how many times has this changed hands", which is hops.

A score MAY read any of these. A score MUST NOT read a fact about a holder that is not in this list, and in particular MUST NOT read a holder's other holdings, balance, or activity: those are facts about a person rather than about the work, and the Security Considerations are blunt about what a work that renders them becomes.

6.2 Tenure cannot be manufactured. Hops can be bought.

The quantities above are not equally trustworthy, and the confidence classes of section 3 do not capture the difference, because this one is about cost to fake rather than about how well known. A value can be settled and worthless.

hops, holders, returns and ecosystems are cheap. One person with two keys can transfer a work between them for a fee, as many times as they like, and produce any value of hops they want in an afternoon. Nothing detects it: the keys are unrelated as far as the chain is concerned, and a marketplace sale between two wallets one person controls is indistinguishable from a sale between strangers.

age, tenure, longestTenure and shortestTenure cannot be manufactured at all, because the only way to produce them is to wait. They are the provenance equivalent of BRC-146 section 4.5's lock: what makes them worth reading is not that they are hard to forge but that forging them costs exactly what having them costs, which is time nobody gets back.

valueMoved and lastPrice are worse than cheap, they are usually wrong, which is why section 6.1 classes them asserted. A transfer's satoshi value is visible only where the sale settled on chain in one transaction; a gift moves for a dust output, a bundle prices five works as one, and anything settled off chain shows nothing.

The recommendation this yields is short. Prefer the properties that cost time. A work that deepens with tenure rewards the collector who kept it; a work that brightens with hops rewards the collector who wash-traded it, and will be wash-traded.

6.3 Constructions

The ways a record can be made visible are the point of the section, and the following are offered as constructions rather than requirements. Each is a pure function of the vector above, or of the marks of section 7.

Two design notes carry across all of them. A construction that reads a cheap quantity should not be one whose output a holder wants more of, per 6.2. And a construction reading a monotone quantity produces a work that can only move one way, which is a strong artistic constraint and the honest one: handling is not reversible, and a work whose wear can be polished out is telling the viewer something untrue about what happened to it.

6.4 What a holder can and cannot do

There is one role in this document and no ladder. A work has a holder, the holder is whoever the lineage shows, and this section states what that is worth, because the rest of the document leaves it implicit and a reader will assume more of it than is there.

What the holder may do.

1. Mark the work, per section 7, within the score's vocabulary, mechanism, eligibility rule and remaining slots. This is the only way anybody adds anything to a work, and it is available to the holder alone because section 7.1(2) checks the signature against the key the lineage shows.
2. Merge or split, where the score defines it, per section 6.7, and only over works the holder controls at that height.
3. Transfer it, which is the token layer's business and not this document's.

What the holder may not do, and this is the longer list. A holder MUST NOT be able to change the score (section 2.5), remove or alter any mark including their own (section 7.1(4)), change the record, prevent the work being rendered by anybody, make the work or its record private, or stop a future holder marking it. A client offering any of these has invented an authority the mechanism does not contain.

Viewing is not a capability. Everyone derives the same work from the same public facts, holder and stranger alike, and a client that gates rendering on ownership has added a restriction this document does not have and cannot enforce. Ownership buys the right to add, never the right to see, and the asymmetry is deliberate: a record whose readership its subject controlled would be a claim rather than a record.

6.5 No scores about holders

A score MUST NOT derive, and a client MUST NOT display, a rating, ranking, grade, or comparison of a work's holders or of works against each other on the basis of their records.

This is a requirement for the reason BRC-168 section 7.8 gives about its own records, and it applies harder here because the quantities are public. A leaderboard of works by hops is an instruction to transfer; one by tenure is an instruction to sit on an object that would otherwise have moved, which is the same distortion wearing better clothes. The record is worth rendering as what happened. It stops being worth anything as a target.

6.6 The client does not narrate the record

A client MUST NOT caption, characterise, or interpret a work's record. No adjectives, no epithets, no summaries in the register of judgement: not "well loved", not "neglected", not "cherished", not "flipped", not "a survivor".

This is the fourth derivation of section 2.1, and the rule is that it is not the client's to perform. A record is a set of quantities with classes attached, and every reading of it is a person's inference from those quantities: forty transfers is enthusiasm or churn, a decade unmoved is devotion or a lost key, and a client cannot tell and neither can a specification. A caption resolves that ambiguity on the viewer's behalf and then presents the resolution in the same interface as the chain facts, where it acquires their authority and cannot be distinguished from them.

What a client MAY do is render the quantities, render their classes, render the constructions the score defines, and say what the derivations were. A viewer looking at a work with sixty rings and no dust can conclude whatever they like about the person who held it, and that conclusion is theirs, unrepeatable, and correctly located.

This will be the most frequently violated requirement in the document, because narrating provenance is very good marketing copy and a bare integer is not. It is a requirement anyway. A marketplace that describes a work as treasured has invented a fact about a stranger and attached it to somebody's property.

6.7 Merging, splitting, and what happens to the record

A score MAY define a merge, in which two works are consumed and one is produced. Where it does:

1. The child's record MUST carry both parents' records, and the child MUST be marked merged permanently.
2. hops and holders become ill-defined across a merge, since the child has two lines. The score MUST state how it combines them, from sum, max, or both, and a client MUST show which was used.
3. age MUST be taken from the older parent. A merge does not make an object younger, and taking the newer origin is how a work launders its age.
4. A merge is irreversible. A score MUST NOT offer an unmerge, and a client MUST state before a merge that both parents cease to exist and that the operation cannot be undone.

A score MAY define a split only where the work was itself produced by a merge, and the split MUST produce the parents' records rather than halves of the child's. Splitting an unmerged work is not defined here: an object with one history has nothing to divide, and dividing the picture is a different operation from dividing the record.

Fractional ownership is not specified here. A claim on part of a work is a custody arrangement, needing a custodian, a redemption path, and a rule for what happens when the arrangement ends, none of which this document provides and all of which BRC-146 section 11 sets out for the analogous case. What this document can say is narrower and is worth saying: where a work's ownership becomes a set rather than a single key, every quantity in section 6.1 that reads "the owner" is undefined, and a score intended for fractional ownership MUST state what it reads instead.

7. Marks

Section 6 is everything the chain observed about a work's holders. A mark is the one thing a holder gets to choose. It is bounded, permanent, attributable, and made while they hold the work, and it is the mechanism by which the katamari picks up something somebody put there deliberately.

The whole of the design tension is in the bounds. A holder who may add anything anywhere is a holder who may overwrite the work, and the first work under a permissive score to be defaced is the last work anybody buys under it. So the vocabulary is closed, the count is fixed, and nothing is ever free-form.

7.1 The rules that hold for every mark

1. A mark MUST be confined to a slot the score defines, with a fixed maximum size and a fixed maximum count, and the count MUST NOT exceed the ceiling of section 2.6. A client MUST refuse to render a score whose marks are unbounded in either.

   The count bounds marks made on the work. Marks a work inherited through a merge are not made on it and do not consume its slots, so a child of two full parents carries both sets and has its own slots still open. A score MUST state whether inherited marks are carried or dropped, since the two produce visibly different objects and section 6.7(1) otherwise leaves the answer to whoever implements the merge.

2. A mark MUST carry the type identifier derived in section 2.7 and MUST be signed by the key the lineage shows as holding the work at the height the mark was made. A client MUST verify both, and MUST ignore a mark that fails either. Without this rule a mark is not a holder's mark, it is a stranger's graffiti attached to somebody else's object.

3. A mark's height is derived, not asserted. It is the confirmation height of the transaction that carried the mark, and it MUST NOT appear in the mark object, for the reason BRC-168 section 3.1 gives about its own commitments: a self-asserted time is the thing a chain is being used to replace. Marks are ordered by that height, ties broken by the lexicographically lowest transaction identifier, so that every client renders them in the same order.

4. A mark MUST NOT be removable, by anybody, including the artist, the marker, and every subsequent holder. A guest book editable by whoever holds it last is not a record of anything.

5. A mark's vocabulary MUST be enumerated in the score, from section 7.3. Free bytes MUST NOT be permitted, in any quantity, under any encoding.

6. A score MUST state its marking mechanism, from section 7.4, and its eligibility rule, from section 7.5.

7.2 The mark object

A mark is a JSON object, canonicalised and signed the way section 2.6 canonicalises a score. Two things are carried by the transaction rather than by the object, and both are derived rather than claimed: the height, per section 7.1(3), and the identity of the marker, which is the key that signed.

No other field is permitted. A client MUST ignore a mark carrying an unrecognised field rather than rendering the part it understood, because a mark is the one place in this document where a stranger's bytes reach a renderer.

What value holds, by kind.

keyprint and weight take no value because neither is chosen: a keyprint is derived from the marker's key per section 8.2, and a weight is derived from the satoshis destroyed. A mark object carrying a value for either is malformed.

A keyprint needs no mark object at all. Its value, its marker and its height are already in the lineage, so there is nothing left for an object to assert and nothing for a signature to add. A client derives keyprints from the lineage directly, subject to the eligibility rule of section 7.5 exactly as any other mark is. This is the only kind with that property, and it has it because it is the only kind the holder does not choose.

Canonicalisation and the signature.

1. A mark MUST contain only objects, arrays, strings and integers, as section 2.6 requires of a score, so that canonicalisation is the uncontentious part of RFC 8785.
2. The preimage is SHA-256 over the RFC 8785 canonical form of the object with signature removed. This is BRC-168 section 3.1's construction and BRC-169 section 7.2's: canonicalising rather than signing the transmitted bytes lets a relay or an indexer re-serialise the object without invalidating it, while any change to a value is detected.
3. The signature MUST be by the key the lineage shows as holding the work at the mark's height, verified per section 7.1(2). There is no separate marker field: the signer is the claim, and a field naming the marker would be a second, weaker copy of a fact the signature already carries.
4. A client MUST verify the signature before rendering, and MUST ignore rather than render a mark that fails. A mark whose signature does not verify is not a damaged mark, it is somebody else's.

How each mechanism carries the object. The mechanisms of section 7.4 differ only in which transaction the object rides in, and all of them carry it identically: as a BRC-48 PushDrop output whose pushed fields, in order, are the ASCII string derived-collectibles-mark, the ASCII string 1, and the canonical form of the object. For on-acquisition and on-disposal that output is in the transfer transaction; for standalone it is in a transaction of its own; for co-signed the object carries a second signature appended to the same field, by the counterparty's key; and for commit-reveal the commit output carries SHA-256 of the canonical form in place of the object, and the reveal carries the object itself.

7.3 What a mark may be

Every kind below resolves to a value from a set fixed at mint, which is what makes it renderable a century later and what stops it being a channel for arbitrary content. A score MAY offer more than one kind and MUST enumerate each.

Two of these deserve a note because they are the interesting ones.

keyprint is a mark nobody chooses. It is a deterministic derivation from the holding key, so a holder cannot shop for a nicer one without changing keys, and it produces a work in which every holder has left a trace whether or not they wanted to. It is the closest thing here to a fingerprint on a handled object, and it is the only mark kind with no aesthetic decision in it at all.

7.4 How a mark is made

The mechanism is what a client checks against the chain, so a score MUST name exactly one and a client MUST reject a mark made another way. The options are ordered from cheapest to re-derive to most demanding.

A score MAY additionally require a mark to be timelocked, in which case the marking output encumbers satoshis to the holder's own key until a stated height, and the mark is admitted only while that lock stands. This is the strongest available form and prices a mark in patience rather than in destruction, per BRC-146 section 4.5. Its costs transfer too: a locked marker cannot leave, and a term cannot be shortened.

7.5 When a holder may mark

The eligibility rule is what stops a work being filled by its first owner. A score MUST name one.

tenure-gated and slotted are the two that behave well over a long life, and for the same reason: both make marking scarce in a way a buyer cannot shortcut. An unrationed score is filled inside a week by whoever is most enthusiastic, and everything after that is a work with no room left in it.

7.6 A mark is untrusted content

A mark is content authored by a third party and rendered in every future viewer's client, and MUST be treated as data.

1. A client MUST NOT interpret a mark as markup, script, a style, a font, a URL to fetch, a filesystem path, or an instruction of any kind.
2. A client MUST render a mark within the bounds the score set, and MUST clip rather than reflow. A mark that can change the layout of anything outside its slot can obscure the work.
3. A client MUST validate a mark against its declared kind before rendering, and MUST ignore a mark that does not conform rather than rendering a best effort at it.
4. A string mark MUST be checked against the score's character set, and a client MUST apply the confusability skeleton of BRC-169 section 2.3 wherever a mark is displayed beside a name, since a string mark is the obvious place to impersonate somebody.
5. A dedication mark MUST be resolved and displayed fully qualified, and MUST NOT be presented as though the named handle consented to it. Being dedicated to somebody is a claim by the marker, not an act by the named party.

This is BRC-218 section 2.4's rule arriving in a different medium, and it is stricter here for one reason: a chat client that executes a hostile message can be fixed and the message deleted, while a work that executes what a previous holder wrote has that content on the chain permanently, in every wallet that renders it, for as long as the work exists.

8. Determinism

8.1 Integers only

Every value in shared or local state MUST be derived in integer arithmetic. Floating-point arithmetic MUST NOT appear anywhere in a derivation.

The failure this prevents is silent and total. Two clients deriving the same position from the same state will agree on integers and will eventually disagree on doubles, and the disagreement appears as a work that is subtly different in two wallets with no way to say which is right. BRC-146's test vector for the same hazard is instructive: the bug is invisible in the cases where both answers agree, which is most of them.

Where a score needs a ratio, it MUST express it as a pair of integers and compare by cross-multiplication. Where it needs a curve, the curve belongs to presentation.

8.2 The derivation

Pseudorandom values are derived from a seed by a construction every language can implement with a hash function and nothing else.

seed        = SHA-256( scoreDigest || origin || uint32BE(domain) )
stream(i)   = SHA-256( seed || uint32BE(i) )

where origin is the work's origin outpoint as 32 bytes of transaction identifier followed by uint32BE(vout), and domain is a small integer the score assigns to each independent use, so that two uses of randomness in one score do not correlate.

An integer in the range [0, n) is drawn by rejection sampling: take successive 32-bit big-endian words from the stream, discard any word at or above floor(2^32 / n) * n, and return the first survivor modulo n. Rejection rather than a plain modulo is required because a plain modulo biases the low outcomes, and a biased rarity is a rarity nobody can reason about.

A keyprint mark (section 7.3) takes the holder's 33-byte compressed key in place of origin, which is what makes it involuntary: the holder supplies nothing and cannot search for a better outcome without changing keys.

Where a score draws from chain entropy rather than from the origin, seed takes the block hash at the stated height in place of origin, subject to section 4.5's depth, class and grinding rules.

8.3 The lineage digest

A score MAY commit to the whole record with

lineageDigest = SHA-256( origin || t(1) || t(2) || ... || t(k) )
t(j)          = uint32BE(height) || ownerKey

over the work's transfers in lineage order up to the evaluation height, where ownerKey is the 33-byte compressed key receiving the work.

It is not a proof of anything and section 3.4 forbids calling it one. What it is for is the disagreement procedure: two clients rendering the same work differently compare lineage digests, and either they differ, in which case they followed different lineages and the argument is about which indexer is right, or they match, in which case the difference is in the derivation and one of the two has a bug. Without it, every disagreement looks the same.

8.4 An indexer is a witness

Every quantity in section 6 is derived by following a chain of transfers, which is what an indexer does. A client MUST NOT treat any indexer as authoritative, SHOULD prefer one it operates or trusts, and MUST NOT accept a score's nomination of one as binding. A value the client took from an indexer without re-deriving it is witnessed per section 3.1, and MUST be rendered as such.

This is BRC-146 section 4.1's rule and the reasoning transfers exactly: two honest indexers agree because they are reading the same chain, so naming one buys convenience rather than agreement, and a score able to bind every viewer to one indexer would let whoever controls it decide what the work looks like.

An unconfirmed transfer is not a transfer. A client MUST NOT advance a record on an unconfirmed spend, and MUST class as probable any value derived from data shallower than settlementDepth.

9. What a Collector Is Shown

A work under this document is a schedule as much as a picture, and a buyer who is shown only tonight's picture has been shown the least informative view of it. A client offering a work for sale SHOULD show:

1. the reference rendering at the current height, with the height, per sections 2.3(4) and 2.8;
2. the confidence class of every property, per section 3.2, and in particular every asserted one;
3. which properties are shared and which are local, per section 2.3(2), and what the local ones would show in the buyer's own timezone;
4. which properties are derived from the clock and which from the record;
5. every external asset the score references, counted and named, per section 5.4;
6. the next height at which any property changes, and what it changes to;
7. whether any property is monotone, and therefore whether the work can return to a state it has left;
8. which quantities the score reads that are cheap to manufacture, per section 6.2;
9. what marks the work carries, who made them, and how many slots remain, per section 7;
10. whether any value was derived by search, and whether it was grindable when it was fixed, per section 4.5.
11. the work as it stood under each previous holder, per section 2.9, which is the part of a provenance a buyer can actually look at rather than read.

Points 6 and 7 are the ones most likely to be omitted and most likely to matter. A work whose patina deepens for ever is a work whose best-looking day was its first, and a buyer entitled to know that before rather than after is every buyer.

10. Not Specified Here

Enforcement, which is reserved rather than merely absent. Nothing here is enforced by consensus. A score is a rule that conforming clients honour, exactly as BRC-146 section 9 says of a gate, and a non-conforming client can render whatever it likes. That is sufficient for a work whose rules nobody gains by breaking, and insufficient wherever a state carries a payment, a royalty, or a mark whose absence somebody profits from.

The consensus-enforced form is therefore reserved for a companion document, in the manner of BRC-218 section 6: a name held open for a specification rather than a name held closed. BRC-226 already demonstrates the mechanism, which is an OP_PUSH_TX covenant compelling the transaction that spends a work to re-create it under stated rules, and a companion would have to settle four things this document deliberately does not touch. Which parts of a score the covenant binds, since binding all of it makes every render a consensus matter and binding none of it changes nothing. How a mark is admitted by script rather than by client convention, per section 7.3. What happens to a work whose covenant cannot be satisfied, which is an object nobody can move. And what the arrangement costs per transfer, since a covenant is paid for by whoever spends it and a work too expensive to move is a work nobody moves.

A client MUST NOT describe a score as enforced, guaranteed, or unstrippable. Until that companion exists, every property in this document is derived by convention, and a collector told otherwise has been sold a promise the mechanism does not make.

Sound, which is reserved rather than dropped. An earlier revision specified it and the specification could not carry its weight: pitch, rhythm and duration are expressible as integer functions of state, and timbre is not, so a score whose identity depended on a particular synthesiser had an undeclared external dependency in the sense of section 5.4 and no vector could be written for it. Nothing in sections 2, 3, 4, 6 or 8 is specific to pixels, so a companion specifying generated audio needs no new derivation machinery: it needs a time base, a synthesis model exact enough that two implementations agree, and an answer to what a work sounds like on a device that refuses to play it. The interval and tempo mark kinds and the constructions that read them are reserved with it.

Fractional ownership. Per section 6.7.

Oracles. A score reading weather, price, or any other off-chain fact is outside this document. It would break section 2.2 outright: the state would no longer be recomputable from chain facts, every value downstream of it would be asserted per section 3.1(1), and a work whose 2126 state depends on a 2026 weather service is a work with an expiry date nobody wrote down.

Renderer identity. This document specifies what to derive, not what to draw with. Two conforming clients agree on state and may legitimately differ in typography, antialiasing, and synthesis. That is the third derivation, and Limitation 9 is about how far it goes.

Estate and inheritance. What becomes of a work whose holder's keys are lost is unaddressed. The work persists because the chain does; the record simply stops.

What Is Derived, and What Is Only Asserted

The case for this document is made at the front and the concessions are distributed across sections 3, 6.2, 11, the Limitations and the Security Considerations. A collector deciding what to believe is entitled to see both totalled in one place, since that decision is the document's whole subject.

What can be recomputed, by anybody, from public facts. That a work's score is the one committed at its origin, because the digest is checked (2.5). That the score is of a stated type, because the type is derived from a printed string rather than assigned (2.7). That the score is the bytes the author wrote, because the canonical form is re-canonicalised and the digest recomputed rather than taken on the word of whoever served it (2.6). Every clock quantity, exactly, at any height, forever (4.2). Every time-based record quantity: age, tenure, the longest and briefest holdings, the count of transfers, of hands and of distinct keys (6.1). Every layer selection, palette, position and repetition the score defines, identically in every conforming client, because the arithmetic is integer and the randomness is a specified hash construction (5, 9.1, 9.2). That a mark was made by the holder of record at the height it claims, because the signature is checked against the lineage (7.1). And that two clients looking at the same work followed the same lineage, because the digests are comparable (9.3).

What is witnessed rather than recomputed. The lineage itself, unless the client walked it (8.4). Any resolution of an owner key to a handle, and therefore ecosystems (6.1) and the label on any retrospective view (2.9). Each is somebody's answer, each is labelled, and each fails soft: a client that cannot reach a witness reports that rather than substituting a guess.

What is estimated. Every conversion from blocks into human time. A duration in days, a date, a season. Exact in blocks, approximate in the units a viewer reads (4.1, 4.3).

What is only asserted, and cannot be otherwise. Price, and everything derived from it (6.2). Any host-supplied attribute. The claim that a work is beautiful, significant, treasured, or neglected, which is the fourth derivation and belongs to whoever is doing the looking (2.1, 6.6).

What nothing here provides at all. Enforcement (11). Confidentiality of who holds what, since the record is public by construction. Recovery of standing lost with a key. Any guarantee that the machinery to perform the work will exist (Limitation 9). And certainty, which the chain does not offer about its own history either (3.1).

The honest summary is narrow. A work whose state is derived is not a work you can be certain about. It is a work whose uncertainty is stated, apportioned, and checkable, which is the most any object on this chain has ever been able to offer, and considerably more than a stored picture with a table of transfers beside it.

Limitations

Nine, and none of them is small.

1. The metronome drifts. Section 4.1 is a rule about expression and does not repair the underlying problem: a score written in blocks and read as calendar time will be wrong by a growing amount. A work whose "century" is 5,256,000 blocks will reach it early, and no version of this document can fix that without importing a clock. The estimated class states the error rather than removing it.

2. Wall-clock resolution is about a day. Median time past lags, and section 4.3 forbids finer use. Anything genuinely diurnal is therefore either chain-derived and offset from the sun, or local under section 2.3 and reproducible only from stated inputs.

3. The timezone database is political and mutable. Local state reads utcOffset, which is a function of rules governments change and sometimes change retroactively, so the same work at the same height in the same room may render differently in two different years. Stating the offset alongside the state (2.8) makes a past local state reproducible; nothing makes a future one predictable. A score whose most valuable states are local has accepted this, which is why 2.3(6) advises against it.

4. Cheap provenance is cheap, and the confidence classes do not catch it. Section 6.2 is a recommendation, not a defence, and section 3's classes are orthogonal to it: a wash-traded hops count is settled and worthless at the same time. One person with two keys and a fee budget can drive hops, holders and returns to any value, and there is no detection available, because the chain cannot see that two keys are one person. Works reading only time-based quantities are immune.

5. Ownership is a key, not a person. Everything in section 6 is about keys. A collector who rotates keys for good reasons appears as two holders and loses a tenure; one who consolidates two works into one wallet creates kin that never happened socially. BRC-146 section 8 works through the same problem for access and recovers part of it with attestations; nothing equivalent is specified here, and a score reading holders should expect the count to be wrong in both directions.

6. Reorganisations change facts. The probable class and the depth rules of 4.5 and 9.4 bound the exposure and do not remove it. A deep reorganisation would change a work's state retroactively, and the state a viewer saw beforehand would have been correct when they saw it and wrong afterwards. That is the chain's own condition, not this document's failure, and section 3.3 is the recommendation to show it rather than hide it.

7. Price is mostly invisible. Per section 6.2. Any construction reading value is reading a lower bound at best, which is why it is classed asserted and why a client that renders it like an age has misrepresented it.

8. A work can be photographed. The derived properties of a work are not enforceable against a screenshot, and for most viewers most of the time a screenshot is what they will see: in a listing, in a feed, in a search result. A still is the third derivation frozen and detached from its inputs, section 3.4 forbids treating it as evidence, and none of that stops it being what circulates.

9. A performance is an approximation, and the machinery of performance rots. The chain preserves the score and the inscribed assets and preserves nothing about what turns them into a picture or a sound. Codecs are abandoned, font formats superseded, colour spaces redefined, audio permission models rewritten, and the browser a work was written against will not exist. The right way to read this is not as a threat to the work but as the ordinary condition of the third derivation: every performance approximates its score, and a long work is one that gets re-derived repeatedly rather than one that never needs to be. Longplayer has been rebuilt more than once in a quarter of a century and is not thereby diminished. What follows is an obligation on the author rather than a caveat for the reader: section 9's integer arithmetic and the inscribing of rules rather than renders exist so that re-derivation is possible, and an author who wants the work performed in a hundred years should write a score somebody could implement from the score alone.

Security Considerations

Marks are attacker-supplied content rendered in every future viewer's client. Section 7.6 is the whole of the mitigation and it is not optional. A client that interprets a mark as markup, script, or a URL has given every previous holder of a work a permanent foothold in every wallet that renders it, and unlike an ordinary injection there is no way to withdraw the content: the chain keeps it.

A score is attacker-influenced input. Anyone can inscribe a score. A client rendering one is executing a stranger's arithmetic against a stranger's assets, and MUST bound everything the score can ask for: the repeat counts of section 5.2, asset sizes, layer counts and the enumerated sets of section 5.2. A score that renders slowly enough is a denial of service against everybody who opens a marketplace page.

External assets are a rug pull with a delay. Section 5.4's digest detects substitution and cannot prevent disappearance. A work whose principal layers are external is a work its author can end by cancelling a hosting bill, and the collector's only protection is having been told which layers those were.

Whoever performs a search chooses the result. Section 4.5. A miner grinding a confirming block hash, or a minter grinding an origin outpoint by choosing inputs, sees the outcome before anybody else and may discard it. Any reveal worth more than the cost of one discarded attempt is a reveal that will be ground.

Wash trading manufactures provenance. Restating limitation 4 as a security property, because it is one: any score whose desirable state is reached by transferring has funded an attack on itself, and the attacker is often the holder. The same applies to section 3.3 if an unresolved state is made desirable, which is why 3.3(2) forbids it.

A work that renders its holders publishes a wallet. A composition showing ecosystems, resolving holders to handles, or drawing a figure per holder is a public statement about who owns what, assembled from facts that were individually public and are considerably more sensitive in aggregate. This is BRC-146's balance oracle in a different guise. A score naming holders MUST be understood as making that disclosure permanent, and a client SHOULD offer to render a work without holder identities.

Indexer capture decides what the work looks like. Section 9.4. An indexer that misreports a lineage changes the state every client relying on it derives, and the discrepancy is invisible to a viewer with one indexer. The witnessed class is what makes the dependency visible; comparing lineage digests per 8.3 is what makes it diagnosable.

A stripped confidence class is worse than no class. An interface that renders asserted and settled values alike has not merely lost information, it has laundered the weakest value into the authority of the strongest. Section 3.2(3) requires the class to survive export for this reason, and a client that shows classes in its own view and drops them at its API has built the failure it appears to prevent.

Determinism failures are silent. A floating-point derivation, a plain modulo, or an unbounded repeat produces plausible output almost always, so the bug ships. Section 9 is written as requirements for that reason.

Implementations

None. This document is a specification ahead of its implementation and says so rather than describing a client that does not exist.

What can be said about implementability is narrower and more useful. Every read this document requires is already performed by deployed software: a 1Sat indexer following an origin per BRC-150 and BRC-156 is what any wallet displaying an ordinal already does, height and block hashes are available from any node or public API, and median time past is derived from eleven headers a client already holds under BRC-9 style verification. Nothing here needs a new script, a new transaction format, or a new overlay topic, which was the criterion for including a mechanism rather than deferring it. The type identifiers of section 2.7 are computed rather than requested, so nothing needs registering either.

A minimal useful implementation is smaller than the document suggests. Sections 2, 3.1, 4.1, 4.2, 5 and 8 produce a work that evolves on height, deterministically, with stated confidence and no record reads at all, and that is the whole of the clock half. Section 6.1's age and tenure add the record half at the cost of one lineage walk. Section 3.3's resolution, marks, sound, merging and kin are each independently optional.

Test vectors. Appendix A carries them, and verify_vectors.py parses every printed value back out of this document and checks it against a fresh run of example.py: eighty-one checks, no third-party libraries, deterministic across runs. Among them: the canonical score re-canonicalises byte for byte; the rejection-sampling vector genuinely discards a word rather than merely claiming to; a property derived from a quantity that did not change between two heights did not change either; the class of tenure crosses settlementDepth between them; two utcOffset values render different waypoints; the signed mark of A.8 verifies against the public key as printed; and the same signature against a mark whose value was altered by one fails.

Four of the last kind are worth naming as a category, because they are the ones a vector suite usually omits. A vector that only demonstrates the happy path demonstrates nothing about an implementation that skips a check: the discard, the tamper, the held-still palette and the class transition each fail loudly on a plausible wrong implementation, which is the only reason to print them.

What the vectors do not cover. There is no renderer, so nothing here checks that two implementations draw the same picture from the same state, only that they derive the same state. The co-signed mechanism of section 7.4 is specified and not vectored, as is the burn behind a weight mark, and neither is the retrospective view of section 2.9, which needs a state derived at a height inside a past tenure. Sound is reserved to a companion under section 10 rather than specified here, so there is nothing owing for it.

Appendix A: Worked Example

Every value below is computed from the rules in this document by example.py, and verify_vectors.py parses them back out of this document and checks them against a fresh run. An implementation producing a different scoreDigest from the same score, or a different state from the same height and lineage, has a bug, and its renders will not agree with anybody else's.

These keys are published in a public specification and are therefore compromised by construction. They are for conformance testing only.

A.1 The type identifiers

Re-derived from the strings printed in section 2.7, which is the whole of their authority:

A.2 The score

A reduced beach: four layers rather than section 5.1's eight, enough to exercise one operation of each kind, one local property, and both a chosen and a derived mark. Asset digests are SHA-256("BRC-210 EXAMPLE ASSET / " + label), so the example is reproducible without shipping any artwork.

Its marks object offers kinds of palette and keyprint, under the standalone mechanism and the tenure-gated eligibility rule at 4,032 blocks, with 12 slots and a seven-entry palette.

The RFC 8785 canonical form, 1712 bytes:

{"grid":[1024,640],"hemisphereDefault":"north","layers":[{"bands":[1,2,3],"locality":"shared","op":"select","reads":"season","slot":"ground","variants":[{"digest":"ecd1c4136cd224fb9ebd679a9911364fda892d9c3e74d6400e9468eb3c5d75bf","storage":"inscribed"},{"digest":"43ed804b66ad4eaa7f4159768df3040ed2ad272be9edfdbf5020ea1125579f79","storage":"inscribed"},{"digest":"e442c36bcc74d46514364c9ab24e55a53f3b3b8ae5d9875ca3943f4312d24543","storage":"inscribed"},{"digest":"1fd3d6a6a1acf9369fc6929e951e20e3b189149b41ac54e3cc57d04ebce73301","storage":"inscribed"}]},{"bands":[36,108],"locality":"local","op":"place","path":[[128,96],[512,48],[896,96]],"reads":"dayPhase","slot":"celestial","variants":[{"digest":"d8afc51a18adaf4c3b74fa12eea98aad5e627541f95c15b88e0db5565a6beeee","storage":"inscribed"}]},{"bands":[1,3,8],"locality":"shared","op":"palette","palettes":[["e8e2d0"],["d8cfb6"],["c2b697"],["a89a78"]],"reads":"hops","slot":"surface","variants":[{"digest":"ab0495f4ea270dd49cbfd22506762c3283289b6591ce671fb11215ff39dd7c48","storage":"inscribed"}]},{"bound":16,"divisor":1,"locality":"shared","op":"repeat","reads":"holders","slot":"chorus","variants":[{"digest":"227903df8672eaba5f5ed23c15defc0148739591a2dcaca0c62145417c4a6607","storage":"inscribed"}]}],"marks":{"eligibility":"tenure-gated","kinds":["palette","keyprint"],"mechanism":"standalone","palette":["ffd27f","9fd0ff","ffa8a8","b8f0c0","e0c4ff","fff4a8","c8c8c8"],"region":[64,480,960,600],"slots":12,"tenureBlocks":4032,"type":"4zYAcdXK54vxfdCPLF4mdYbDA7Ew97HDvIJOqVs68sw="},"protocol":"derived-collectibles","seasonBoundaries":["03-01","06-01","09-01","12-01"],"settlement":"resolve","type":"iDB79v3araIhb1GLVn21KzfM6n8KJHT2qvXn9hUswpo=","version":1}

scoreDigest = 842f23000912be13e568bf222c19461a0db588d038ac791aec13e652e4bb4bdf

That digest is what the minting transaction's PushDrop output carries, per section 2.6(3).

A.3 The derivation of section 8.2

The work's origin is vout 0 of 0795cda147e624791aa48a1ba71d6e47a49c6d55a91b46a5cf4412e8037570c7.

A weather layer drawing one of four states under domain 1:

seed  = SHA-256( scoreDigest || origin || uint32BE(1) )
      = aafa95c911b5e08f518ce5b5d67de02d855ea7ff7fbb329b25efa0dde4d19a98
draw(4) = 1

The discard path. A realistic n rejects a few parts in four billion and no reachable vector would ever exercise it, so this one uses a deliberately hostile n = 2500000000, for which floor(2^32 / n) * n is 2500000000 and roughly two words in five are rejected. Under domain 6:

seed              = e7d0befc9fe984dbd7ee22abb3cc98bcd85f3e46dfa0f1c765c07bc970249c9c
word 0            = 3829205201   rejected, at or above the limit
word 1            = accepted
draw(2500000000) = 331813804

An implementation that returns word 0 % n here, rather than discarding and drawing again, is biased and will disagree with every conforming client on this vector.

A.4 The lineage

Private keys are SHA-256(label) reduced mod n, as BRC-168 and BRC-169 do, so an implementer can regenerate them. The work is minted to Alice at height 900000 and transferred three times:

The lineage digest of section 8.3, over uint32BE(height) || ownerKey for each transfer in order:

lineageDigest = 6dd555fd41a03b270d8aa5725a7cd8d8268c30f4d9d3644c58a9bed4c0d8edf1

A.5 The record and the state, at two heights

The median time past at 921600 is given as 1786752000, which is 2026-08-15 UTC. Against the score's boundaries that is season index 1, summer in the northern hemisphere, so the ground layer selects variant 1.

And the resolved layers:

Three things in that pair are the reason it is the vector worth having. hops is 3 at both heights, so the patina palette does not move: a property derived from a quantity that did not change must not change either. tenure moves from 10 to 4042. And the class of tenure moves from probable to settled, because the transfer at 921590 is 10 blocks deep at 921600 and 4042 deep at 925632, which crosses settlementDepth. A score with settlement of resolve renders the first unresolved and the second settled, per section 3.3, from the same derived value.

A.6 One local property, at two offsets

The celestial layer is declared local and reads utcOffset, converted to blocks at the ten-minute target by integer division, per section 8.1:

localDayPhase = ( h + utcOffset / 10 ) mod 144

Both are the same work at the same height. The first is the reference rendering of section 2.3(4), because utcOffset is at its neutral value; the second is what a collector ten hours east sees. Each is reproducible by anybody told the offset, which is the whole of what section 2.3 asks, and neither is reproducible by anybody who was not, which is why section 2.8 requires the offset to travel with the state.

A.7 A keyprint mark, which nobody signs

Alice's keyprint under section 7.3, which she does not choose and which needs no mark object at all, per section 7.2: her key, her height and her identity are already in the lineage. Her key stands in for the origin in the derivation of section 8.2:

seed  = SHA-256( scoreDigest || alicePubKey || uint32BE(3) )
      = 07389818f683d6441ec96bfd7ea4a24f4e8808c31f2f01be7db3c4253e6214a0
draw(7) = 6   ->   palette entry `c8c8c8`

She cannot shop for a different one without changing keys, which is the property that makes a keyprint a trace rather than a decision.

A.8 A signed mark

Alice's palette mark, which she does choose, and which therefore is an object and is signed. The mark object of section 7.2, before signing:

{"kind":"palette","origin":"0795cda147e624791aa48a1ba71d6e47a49c6d55a91b46a5cf4412e8037570c7_0","protocol":"derived-collectibles-mark","type":"4zYAcdXK54vxfdCPLF4mdYbDA7Ew97HDvIJOqVs68sw=","value":3,"version":1}

211 bytes, canonical per RFC 8785, with signature absent because the preimage is the object without it. Note what is not in there: no height, because section 7.1(3) derives it from the carrying transaction, and no marker, because the signature is the claim.

preimage  = SHA-256( canonical form )
          = e74e09e758096f916de36d5ce0f86e7e0420d10552590c67073407c65c2ada61
signature = 3044022075d5fadc6e985335f55e70b5d2a1be803cb7f4bbc164a0f08b1e60208210b80302200b327916c6ec2ca3d0150ec97423332d3530d6448e3b14fb82560a497becd62a

Deterministic ECDSA per RFC 6979 over secp256k1, DER-encoded, low-S normalised, by Alice's key from A.4. It verifies against her public key as printed.

The vector that matters is the negative one. Change value from 3 to 2, leave the signature alone, and verification fails. An implementation that renders the altered mark has skipped section 7.2(4), and the failure is invisible in every case where nobody has tampered with anything, which is almost every case.

References

• BRC-9: Simplified Payment Verification
• BRC-42: BSV Key Derivation Scheme (BKDS)
• BRC-43: Security Levels, Protocol IDs, Key IDs and Counterparties
• BRC-45: Definition of UTXOs as Bitcoin Tokens
• BRC-48: Pay to Push Drop
• BRC-52: Identity Certificates
• BRC-60: Simplifying State Machine Event Chains in Bitcoin
• BRC-87: Standardized Naming Conventions for BRC-22 Topic Managers and BRC-24 Lookup Services
• BRC-113: Merkle Proof Token
• BRC-145: Registry-Free Typed Content Anchor with On-Chain Code Provenance
• BRC-146: Access Gates for Metanet Rooms
• BRC-147: 1Sat Ordinals Basket Profile for BRC-46 / BRC-100
• BRC-150: 1Sat Provenance Remittance for Basket 1sat
• BRC-156: Latched 1Sat Provenance for Basket 1sat
• BRC-168: Verifiable Time Allocation
• BRC-169: Universal Handle Addressing and Resolution for the Metanet
• BRC-218: Chat-Native Command Grammar for the Metanet
• BRC-224: Block Media Format (BMF), Composable On-Chain Audio/Video
• BRC-226: Miner-Enforced Resale-Royalty Covenant Tokens (OP_PUSH_TX)
• RFC 2119: Key words for use in RFCs to Indicate Requirement Levels
• RFC 6979: Deterministic Usage of DSA and ECDSA
• RFC 8785: JSON Canonicalization Scheme (JCS)
• BIP-113: Median time-past as endpoint for lock-time calculations
• S. Nakamoto, "Bitcoin: A Peer-to-Peer Electronic Cash System" (2008), section 11, on the probability of an attacker catching up from a given depth
• Ordinal Theory Handbook, "Rarity" (satoshi rarity from the issuance schedule)
• S. LeWitt, "Paragraphs on Conceptual Art", Artforum (1967), and the wall drawings as executed instructions
• V. Molnar, G. Nees and M. Mohr, algorithmic composition from the 1960s
• B. Eno, Discreet Music (1975) and 77 Million Paintings (2006)
• Art Blocks, hash-seeded immutable generative works; Async Art, independently owned mutable layers; EulerBeats, seed-derived audio; Terraforms by Mathcastles, on-chain state advancing on block progression
• J. Cage, Organ2/ASLSP (1987), in performance at Halberstadt since 2001 on a 639-year schedule
• J. Finer, Longplayer (1999), a thousand-year composition, and its documented migrations between performing systems
• K. Paterson, Future Library (2014 to 2114)
• Namco, Katamari Damacy (2004)