Derived Collectibles

Crumbs, root, Kuro

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.

Stage	From	To	Whose	Reproducible by
1	chain facts, score	shared state	this document, normatively	anybody, from the height
2	shared state, declared viewer inputs	local state	this document, normatively	anybody told the inputs
3	state	render	the client	anybody with the same client
4	render	reading	the viewer	nobody, including the viewer

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.

Input	Type	Supplied by
utcOffset	integer minutes, -720 to +840	The viewer's own setting or platform offset at the moment of rendering.
hemisphere	north or south	The viewer's own setting. Never a network lookup, and never inferred from an address.
calendar	an identifier from a set the score enumerates	The viewer's own setting, where a score renders dates at all.

1. 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.
2. 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.
3. 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.
4. 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.
5. 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.

Field	Type	Required	Meaning
protocol	string	yes	The ASCII string derived-collectibles. Carries no BRC number, per section 2.7(2).
version	integer	yes	1 for this document.
type	string	yes	The score type identifier of section 2.7.
grid	[integer, integer]	yes	Width and height in integer units, for the place operation of section 5.3.
layers	array	yes	Ordered back to front, per section 5.1.
hemisphereDefault	north or south	conditional	Required where any layer reads season. Also the value the reference rendering of section 2.3(4) uses.
seasonBoundaries	array of MM-DD	conditional	Required where any layer reads season. Ascending, per section 4.4.
settlement	resolve or hold	no	Whether a probable property renders unresolved and resolves, per section 3.3. Absent means hold.
marks	object	no	Mark configuration: kinds as an array of the kinds the score offers, plus the mechanism of section 7.4, the eligibility rule of section 7.5, slots, and whatever each kind needs to enumerate its choices.

A layer object:

Field	Type	Required	Meaning
slot	string	yes	Names the layer. Unique within the score.
locality	shared or local	yes	Per sections 2.2 and 2.3.
op	one of section 5.2's operations	yes
reads	string	yes	The name of one clock quantity from section 4.2 or one record quantity from section 6.1.
bands	array of integers	conditional	Ascending thresholds. Required for select, palette, place and absent.
variants	array of asset objects	conditional	Required except for absent with no asset.
palettes	array of arrays of strings	conditional	Required for palette. Six-digit lowercase hexadecimal, without a leading #.
path	array of [integer, integer]	conditional	Required for place. Waypoints on the grid.
divisor, bound	integers	conditional	Required for repeat.

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-190 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.

Limit	Value
Layers	16
Entries in any bands, variants, palettes or path	16
repeat bound	64
Mark slots per work	32
Inscribed asset size	1 MiB
Total inscribed asset size per score	8 MiB

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-190 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:

Object	Derivation string	type
Score (section 2.5)	derived collectibles score v1	iDB79v3araIhb1GLVn21KzfM6n8KJHT2qvXn9hUswpo=
Mark (section 7)	derived collectibles mark v1	4zYAcdXK54vxfdCPLF4mdYbDA7Ew97HDvIJOqVs68sw=

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-190 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.

Class	Means	Typical source
settled	Re-derived by this client from data buried at least settlementDepth blocks	age, hops over old transfers, any clock quantity below the tip
probable	Re-derived by this client, from data shallow enough that a reorganisation could change it	a transfer six blocks deep, entropy not yet matured under section 4.5
witnessed	Reported by an indexer and not independently re-derived	a lineage the client took on trust, per section 8.4
estimated	Re-derived through a lossy conversion, so exact in its own units and approximate in the ones displayed	a date or duration from a height, a season from median time past
asserted	Cannot be re-derived by anybody from chain facts	valueMoved, lastPrice, a host-supplied display name

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-190 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:

Quantity	Derivation	Notes
height	h	The beat.
chainDay	h / 144	144 blocks is a day at target. Not a day.
retargetEpoch	h / 2016	The difficulty period.
halvingEpoch	h / 210000	The longest hand on the clock.
dayPhase	h % 144	Position within the chain day, 0 to 143.
retargetPhase	h % 2016
halvingPhase	h % 210000
subsidy	Per consensus, from halvingEpoch	Halves every epoch.

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.

Mode	Cost	Predictability	Who chooses the result
By computation	free	fully predictable from inputs	nobody
By search	a block's worth of work per attempt	unpredictable before the fact	whoever performed the search
By witness	a network request	not derived at all	whoever answered

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:

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:

Operation	Effect
select	Choose one variant from a fixed, enumerated set.
absent	Render nothing.
palette	Render the layer's asset with a palette chosen from a fixed set.
place	Render at a position derived from state, along a path the score defines.
repeat	Render n instances, n derived from state and bounded by the score.

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:

Label	Meaning
inscribed	The bytes are on chain, at a stated location, and a client can fetch them and recompute the digest.
external	The bytes are somewhere else. The digest says what they should be; nothing guarantees they will be there.

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:

Name	Meaning	Derivation	Class
age	Blocks since mint	h - originHeight	settled
hops	Transfers so far	Count of lineage transfers	settled past depth
hands	Tenures the work has passed through	hops + 1, so a reacquisition is a further hand	settled past depth
holders	Distinct owners	Count of distinct owner keys, the minter included	settled past depth
tenure	Blocks in the current hands	h - lastTransferHeight, or h - originHeight where hops is 0	probable while shallow
longestTenure	The longest anybody has held it	Max over every tenure, the one still running included	settled
shortestTenure	The briefest	Min over every tenure, the one still running included	settled
returns	Reacquisitions	Transfers to a key that held the work before	settled
firstHolderHolds	Whether the work has never been transferred	True while hops is 0, false permanently after	settled
ecosystems	Distinct handle domains among holders	Where owners resolve to handles per BRC-169	witnessed
marks	Marks added	Section 7	settled
lineageDigest	A commitment to the whole record	Section 9.3	as its inputs
valueMoved	Cumulative satoshis paid across transfers	Section 6.2	asserted
lastPrice	Satoshis paid at the most recent transfer	Section 6.2	asserted
merged	Whether the work has ancestors on more than one line	Section 6.7	settled

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-190 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.

Construction	Reads	What it does
Patina	hops	A surface accumulates handling. Deepens monotonically and never reverses, which is what makes it read as wear rather than decoration, and which is section 3.4's one-way function made visible.
Growth rings	age	One ring per halvingEpoch, drawn from the centre out, so the work's age is countable by looking.
Settling	tenure	Elements drift toward rest while nobody moves the work, and are disturbed on transfer. Pairs naturally with section 3.3's resolution, since both say the same thing about a recent transfer.
Dust	longestTenure	Accumulates over the longest unmoved stretch and is never cleared, so a work that slept for a decade carries the decade.
Depth of field	hands	Each tenure occupies a plane, receding, so the composition acquires literal depth from the number of times it changed hands.
The minter's mark	firstHolderHolds	Present only while the work has never left its creator, and gone permanently once it does. Unrepeatable by construction.
Homecoming	returns	A distinct, non-accumulating state while a work is back with a previous holder. The only construction here that is not monotone, and the score must say so.
Scars	shortestTenure	A record of the briefest holding, which is the trace a flip leaves.
The cairn	order marks, slotted	Each holder adds one stone. The pile is the provenance, countable at a glance.
Footprints	position marks	Every holder leaves one, where they chose, and the tide never takes them.
Windows	palette marks	One lit window per holder, in their colour. A work held by forty people is a lit street.
Rings and knots	keyprint marks	An involuntary trace per holder, so the work records who had it without anybody deciding to be recorded.

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-190 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.

Field	Type	Required	Meaning
protocol	string	yes	The ASCII string derived-collectibles-mark.
version	integer	yes	1 for this document.
type	string	yes	The mark type identifier of section 2.7.
origin	string	yes	The work being marked, as <txid>_<vout>. A mark that does not name its work can be replayed onto another one.
kind	string	yes	One of section 7.3's kinds, and one the score enumerates.
value	integer, string or array	conditional	The holder's choice, per the table below. Absent exactly where the kind derives its own value.
signature	string	yes	DER-encoded ECDSA, hexadecimal, per the rule below.

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.

Kinds	value
palette, variant, glyph, dial	An integer index into the set the score enumerates, or the integer itself for dial.
position	[integer, integer], inside the score's region.
order	An array of integers, a permutation of the score's set.
string, dedication	A string, within the score's length and character set.
kin	An origin, as <txid>_<vout>.
curated	A digest from the score's pool, 64 lowercase hexadecimal characters.
keyprint, weight	Absent.

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.

Kind	The holder supplies	Example in a work
palette	One entry from a fixed palette	The colour of a light left burning in a window
position	Integer coordinates within a fixed region	Where on the shore they left a footprint
variant	One option for a layer slot the score reserved for marking	Which shell is on the sand
glyph	One symbol from an enumerated set	A sigil cut into the rock face
dial	An integer in a bounded range	How far the tide came in that year
order	A permutation of a fixed set of elements	The arrangement of stones in a cairn
pairing	Two enumerated elements chosen together	A bird and the branch it sits on
string	A fixed-length string from a restricted character set	Initials scratched into a post
dedication	A BRC-169 handle, resolved and displayed fully qualified	Who they held it for. A mark that names somebody else
kin	The origin of another work under the same score	A rope tied between two works, per section 6.4
curated	One digest from a pool the score enumerated at mint	An asset the artist prepared and the holder chose between
keyprint	Nothing. Derived from the holder's own key per section 8.2	An involuntary mark: the shape of their key, which they did not choose and cannot pick
weight	An integer derived from satoshis burned, per section 7.4	How deep the mark is cut, priced in something destroyed

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.

Mechanism	The holder does this	What it costs, and what it buys
on-acquisition	Carries the mark in the very transaction that transfers the work to them	Cheapest to verify, since the mark and the transfer are one object. Forces the choice at the moment of purchase, before they know what the work will become.
on-disposal	Carries the mark in the transaction that transfers the work away	The parting mark. They decide what the work was to them at the moment they know, which is when they let it go.
standalone	Publishes a BRC-48 PushDrop output referencing the work's origin, signed by the holding key, at any height while they hold it	One extra transaction. Lets a holder mark when they have decided rather than when the chain forced them to.
co-signed	Marks in the transfer, signed by both the outgoing and incoming holders	Records a handover rather than a holder. Two parties agreed that this is what passed between them.
countersigned	Marks, and a later holder attests it with a BRC-52 certificate	A mark somebody else vouched for, distinguishable from one nobody did.
burn-weighted	Accompanies the mark with satoshis paid to a provably unspendable output	A costly signal in the strict sense: the amount is destroyed, so nobody profits from the mark existing. The construction is BRC-190 section 2.4's, and its warning applies: an output whose key may exist is a gift, not a cost.
delegated	An agent marks under a BRC-169 section 9 delegation whose scope names the marking action