Authenticated 1Sat Inscription

Abstract

This BRC specifies, to the byte, a single transaction output that carries an inscription, stays spendable so the inscribed satoshi can be transferred, and binds the inscription to the identity that created it. It composes four things in one output script, in a fixed order: a standard spend condition (commonly a pay-to-public-key-hash lock), the BRC-160 ord inscription envelope, an optional metadata section, and an author-identity section that signs the output. The output is the single-satoshi token of BRC-159, and this document adds the authenticity that BRC-160 leaves to a separate specification. Two facts are fixed that an implementation gets wrong silently. First, the data that rides after the inscription MUST sit behind one bare OP_RETURN (0x6a), which leaves the spend condition's result on the stack and keeps the satoshi spendable, and MUST NOT sit behind OP_FALSE OP_RETURN (0x00 0x6a), which strands the satoshi forever; the difference is one byte and does not fail visibly at creation. Second, the author-identity section is an Author Identity Protocol (AIP) section whose signing component and algorithm are ordered as the 1Sat Ordinals signing convention places them, which is the reverse of generic Bitcom AIP, and whose selector -1 signs the exact output-script bytes that precede the section. This BRC pins that order and selector, states the Bitcoin Signed Message preimage the signature covers, and gives canonical pass and fail hex vectors for a full locked, inscribed, metadata-bearing, signed output. Each vector's signature was verified by public-key recovery, and the spendable and unspendable output forms were checked against a post-Genesis script interpreter.

Motivation

An inscription envelope (BRC-160) proves that some content was present in a script at an outpoint. It does not prove who put it there. BRC-160 says so in its scope: issuer authenticity is "specified separately", and its security section states that an envelope "does not by itself prove" anything about who authored the content. For a collectible, a licensed work, a credential, or any record whose value depends on provenance, that gap matters: anyone can copy the content bytes of an existing inscription into a new output and present it as their own. Closing the gap needs a signature by a known identity key over the inscribed output, and a rule that fixes which bytes are signed so that two independent verifiers agree.

The 1Sat Ordinals ecosystem already uses the Author Identity Protocol for this, with a convention recorded in the 1Sat Ordinals signing document: the author pushes an AIP section after the inscription, inside the same OP_RETURN, and uses the selector -1 to mean "the entire output script is being signed". The convention is widely deployed but under-specified in three ways that each break interoperation:

1. The output must stay spendable. A 1Sat token is a chain of one-satoshi outputs (BRC-159); transferring it spends the current output into the next. If the author or the builder appends the metadata and the signature behind OP_FALSE OP_RETURN, the pattern used for pure data carriage (BRC-18), the one satoshi can never be spent again and the token is frozen at that outpoint. The spendable pattern is a bare OP_RETURN. The two differ by a single leading OP_FALSE byte, both relay, and both confirm; the harm appears only when a holder later tries to transfer and cannot. The correct template has to be stated to the byte.

2. The field order diverges. Generic Bitcom AIP, as two widely used reference libraries encode it, pushes the algorithm name before the signing address. The 1Sat Ordinals signing convention pushes the signing address before the algorithm name. A verifier that assumes the wrong order reads the address as the algorithm and rejects every valid signature. One order has to be canonical for this output type.

3. The signed range is terse. "The entire output script is being signed" does not say whether the OP_RETURN opcode is inside the signed bytes, whether a metadata section before the author section is inside them, or whether the Bitcom pipe separator that introduces the author section is inside them. A verifier that includes or excludes the pipe differently from the author computes a different Bitcoin Signed Message hash and rejects a valid signature. The range has to be defined byte-exactly, including the pipe.

This BRC fixes all three. It gives one spendable output template, one canonical field order with a stated rationale and a note on the divergence, one signed range, and the Bitcoin Signed Message preimage over it, so that a builder can assemble an authenticated inscription and any verifier, having never spoken to the builder, accepts it or rejects it for the same reason.

Scope and conformance

Section 1 defines terms. Section 2 specifies the data-carrying ordinal output: the single-OP_RETURN rule, the spendable bare-OP_RETURN template, the unspendable OP_FALSE OP_RETURN form it must avoid, and relay guidance. Section 3 specifies where a metadata section is placed. Section 4 specifies the author-identity section: its push order, the signed range, the Bitcoin Signed Message preimage, and the divergence from generic AIP. Section 5 specifies verification. Section 6 lists every requirement by role.

In scope: the bytes of one output that locks a satoshi, inscribes content, optionally names it with metadata, and carries one author signature over itself. Out of scope: how an identity key is certified or discovered (see BRC-52 and BRC-202); the one-satoshi token chain and origin rules (BRC-159); the envelope's own field grammar (BRC-160); collection membership and traits; content larger than one output and multipart carriage; marketplace listings and transfer covenants; the metadata schema's own key set beyond the one example this document carries; and the fee, funding, and change of the transaction that creates the output.

This BRC adds a layer to an existing output type and changes nothing in the standards it builds on. It does not redefine the envelope of BRC-160, the token of BRC-159, the AIP wire format, or the Bitcoin Signed Message construction; it selects and pins a profile of them for one output type and states the bytes that profile produces.

The key words MUST, MUST NOT, SHOULD, SHOULD NOT and MAY are to be interpreted as described in RFC 2119 and RFC 8174 when, and only when, they appear in capitals. Three roles are used: an author holds the identity key and produces the signature; a builder assembles and funds the output (it may be the same party as the author, or a platform acting for it); a verifier reads an output and reports whether its author signature is valid and whose identity key it binds (an indexer, a marketplace, or a wallet).

Relationship to existing standards

Inscription envelopes and the single satoshi: BRC-159 and BRC-160

BRC-159 defines a 1Sat Ordinals token as a chain of outputs of exactly one satoshi, identified by the outpoint where the chain began, and transferred by spending the current one-satoshi output into the next. BRC-160 defines the ord envelope that attaches content to such an output: OP_FALSE OP_IF <"ord"> OP_1 <content-type> OP_0 <content> OP_ENDIF, where "ord" is the three bytes 0x6f 0x72 0x64, a single-byte push of 0x00 or 0x01 is accepted as an alias for OP_0 or OP_1, and the envelope may be placed before the lock, after the lock, or separated from it by OP_CODESEPARATOR. This BRC uses the lock-first placement, requires the token to be one satoshi as BRC-159 does, and requires the output to remain spendable so the chain can continue. It supplies the issuer authenticity that BRC-160 places out of its own scope.

Data-carrying output scripts: BRC-18, BRC-19, BRC-48 and BRC-21

BRC-18 carries data behind OP_FALSE OP_RETURN, which makes the output provably unspendable, the correct choice when the output exists only to carry data. The inscription output here must do the opposite: carry data and stay spendable, because its satoshi is a token that has to move. BRC-19 is the spendable counterpart, data behind a bare OP_RETURN (a "true return") whose output stays spendable; the data-carrying form of section 2 is exactly that arrangement, applied to a 1-satoshi ordinal output and stated to the byte, so section 2 states why the bare OP_RETURN form keeps the satoshi spendable after the Genesis upgrade and why the BRC-18 form must not be used for it. BRC-48 carries data in a push-drop prefix of the locking script rather than behind OP_RETURN; it is an alternative to the metadata section of section 3, usable where a verifier reads pushes rather than an OP_RETURN payload, and this BRC does not use it. BRC-21 authenticates a spending transaction's preimage inside the locking script; a data-carrying ordinal may use a BRC-21 covenant as its spend condition, but the author authenticity here is a message signature over the output, evaluated off-chain by a verifier, and is independent of the spend condition.

Message signatures and identity binding: BRC-3, BRC-77, BRC-52 and BRC-202

The author signature uses the Bitcoin Signed Message construction, the long-standing scheme that prefixes a message with a fixed magic string, double-hashes with SHA-256, and produces a 65-byte recoverable ECDSA signature from which the signer's address is recovered. BRC-77 and BRC-3 are the ecosystem's message-signature and digital-signature standards; AIP's BITCOIN_ECDSA algorithm predates them and is the recoverable Bitcoin Signed Message, so section 4 states that construction in full rather than referencing a newer scheme. The signing address identifies a key; binding that key to a real-world or pseudonymous identity is the work of a certificate (BRC-52) or an identity-key decentralized identifier (BRC-202). This BRC proves that the holder of a given key authored the inscription; it does not say who that key belongs to, which those standards address.

Other ordinals profiles

BRC-147 and BRC-150 profile 1Sat tokens for wallet baskets and provenance remittance. They govern how a wallet holds and hands on a token; this BRC governs the bytes of one authenticated output and does not duplicate them. No existing BRC specifies the author-identity section of a 1Sat inscription or the spendable data-carrier template for it, so this document does not overlap an allocated number.

Prior art outside the BRC series

The Author Identity Protocol defines the 15PciHG22SNLQJXMoSUaWVi7WSqc7hCfva Bitcom prefix, the BITCOIN_ECDSA algorithm, and the index selector. The 1Sat Ordinals signing document records the convention this BRC pins: the signing address before the algorithm, and the selector -1 for the whole output script. The Magic Attribute Protocol defines the 1PuQa7K62MiKCtssSLKy1kh56WWU7MtUR5 prefix and the key-value metadata of section 3. The Genesis upgrade specification defines the post-Genesis OP_RETURN semantics that section 2 depends on.

Specification

1. Terminology

• Output script: the scriptPubKey of the single output this BRC specifies, a byte string.
• Lock: the spend condition at the start of the output script. Unless stated otherwise it is a 25-byte canonical pay-to-public-key-hash script, OP_DUP OP_HASH160 <20-byte hash> OP_EQUALVERIFY OP_CHECKSIG, hex 76a914 <hash> 88ac.
• Envelope: the BRC-160 ord envelope, as section 1's reference states it.
• Metadata section: the Magic Attribute Protocol pushes of section 3, carried after the OP_RETURN.
• Author section: the AIP pushes of section 4, carried last in the OP_RETURN.
• Signed range: the output-script bytes an author signature covers, defined in section 4.2.
• PUSH(b): the minimal push of the byte string b: for a length n below 0x4c, the byte n followed by b; for n up to 0xff, 0x4c n b; for n up to 0xffff, 0x4d and n as two little-endian bytes and b; otherwise 0x4e and n as four little-endian bytes and b.
• Bitcom pipe: the one-byte string 0x7c, the ASCII |, pushed as 01 7c, that separates two Bitcom protocol sections in one OP_RETURN.

Hex strings are byte strings in the order they appear in a script. ASCII strings are their UTF-8 bytes.

2. The data-carrying ordinal output

2.1 One output, one OP_RETURN

An authenticated inscription is one output of value exactly 1 satoshi (BRC-159). Its output script is, in this order:

<lock> <envelope> OP_RETURN <metadata section?> <author section?>

The lock comes first, the envelope second, then a single OP_RETURN, then the optional metadata section (section 3), then the optional author section (section 4). A builder MUST place the lock before the envelope (R1). A builder MUST emit at most one OP_RETURN in the output script (R2): after the Genesis upgrade a top-level OP_RETURN ends script evaluation (section 2.2), so a second OP_RETURN would never be reached and any section placed after it would be unreadable by a spend and ambiguous to a verifier. All sections that ride after the inscription therefore share the one OP_RETURN, concatenated as pushes, with a Bitcom pipe between two adjacent sections of different protocols (section 3, section 4.1).

2.2 The spendable bare-OP_RETURN template

The OP_RETURN MUST be a bare OP_RETURN, the single byte 0x6a, and MUST NOT be OP_FALSE OP_RETURN, the two bytes 0x00 0x6a (R3). The reason is the post-Genesis semantics of OP_RETURN. After the Genesis upgrade, a top-level OP_RETURN (one not inside an unexecuted conditional branch) terminates script execution, the bytes after it are not evaluated and need not be valid script, and the validity of the script is determined by the top item left on the stack at that point.

For the template above, spent through a canonical pay-to-public-key-hash lock:

1. The unlocking script pushes <signature> <public key>.
2. The lock runs: OP_DUP OP_HASH160 ... OP_EQUALVERIFY OP_CHECKSIG consumes both and leaves a single true value (0x01) on the stack.
3. The envelope runs: OP_FALSE pushes an empty (false) value, OP_IF consumes it and, being false, skips to OP_ENDIF; the pushes inside the branch are not executed. The stack is unchanged, its top still the true value from step 2.
4. OP_RETURN (0x6a) is reached at the top level and terminates execution. The top item is true, so the script is valid and the satoshi is spendable. The metadata and author sections after 0x6a are never executed and so carry arbitrary push data freely.

If instead OP_FALSE OP_RETURN (0x00 0x6a) is used, step 4 is preceded by OP_FALSE, which pushes a false value; OP_RETURN then terminates with a false top item, the script is invalid, and the one satoshi can never be spent. The token is stranded at that outpoint. The two forms differ by the one leading 0x00 byte, both are accepted into blocks, and the failure surfaces only when a holder later attempts a transfer, which is why R3 is a MUST stated to the byte.

A builder MUST ensure the executed portion of the output script (the lock and the envelope) leaves a single true item on the stack when the bare OP_RETURN is reached (R4). A canonical pay-to-public-key-hash lock followed by a well-formed envelope does so. A lock that leaves a false top item, or no item, produces an unspendable output under the same rule, so a non-standard lock MUST be checked against this requirement before it is funded.

2.3 Relay and standardness

After the Genesis upgrade the default node policy propagates non-standard transactions, and the output-script structure recommendations are policy rather than consensus. The spendable template of section 2.2 relays under default policy and confirms, and its spend is an ordinary one-satoshi spend of the lock. A builder SHOULD confirm, against the policy of the miners it relies on, that an output whose OP_RETURN payload is large relays before it funds many such outputs (R5); the payload size is bounded by the transaction size policy, not by this BRC. The spendable and unspendable forms of section 2.2 were both checked against a post-Genesis interpreter under a restrictive policy configuration: the bare-OP_RETURN form validated and spent, the OP_FALSE OP_RETURN form did not.

3. Metadata placement

A metadata section names the inscription so an indexer can list it. When present it uses the Magic Attribute Protocol: the prefix 1PuQa7K62MiKCtssSLKy1kh56WWU7MtUR5 (pushed), the command SET (pushed), then key-value pairs, each key and value a separate push. A typical ord-schema record for a named inscription is:

PUSH("1PuQa7K62MiKCtssSLKy1kh56WWU7MtUR5") PUSH("SET")
PUSH("app") PUSH(<application>) PUSH("type") PUSH("ord") PUSH("name") PUSH(<name>)
[ PUSH(<key>) PUSH(<value>) ... ]

The metadata section is placed immediately after the bare OP_RETURN, with no leading pipe, because it is the first Bitcom section in the OP_RETURN (R6). If an author section follows it, a Bitcom pipe separates the two (section 4.1). A builder MAY omit the metadata section; when it is omitted, the author section, if any, follows the OP_RETURN directly. The metadata section's own key set beyond app, type and name is out of scope for this BRC; a verifier reads the keys present and MUST NOT require any key this BRC does not list.

4. The author-identity section

The author section proves that the holder of one identity key produced this output. It is an AIP section carried last in the OP_RETURN, after any metadata section. This BRC pins the 1Sat Ordinals convention for its field order and selector, and states the signature construction and the signed range to the byte.

4.1 Push order

The author section is, in order:

[ PUSH("|") ]
PUSH("15PciHG22SNLQJXMoSUaWVi7WSqc7hCfva")
PUSH(<signing address>)
PUSH("BITCOIN_ECDSA")
PUSH(<signature>)
PUSH("-1")

• The leading PUSH("|") (the Bitcom pipe, bytes 01 7c) is present when the author section follows another Bitcom section in the same OP_RETURN, for example a metadata section, and absent when the author section follows the OP_RETURN directly. A builder MUST include the pipe when and only when a prior section is present (R7).
• <signing address> is the base58check pay-to-public-key-hash address of the author's identity public key (version byte 0x00), in ASCII, pushed with its minimal push (its length is 33 or 34 bytes). The signing address is pushed before the algorithm name. This is the 1Sat Ordinals convention and is the reverse of generic Bitcom AIP (section 4.4). A builder MUST use this order (R8).
• "BITCOIN_ECDSA" is the 13-byte ASCII algorithm name, pushed as 0d and the bytes. It denotes the recoverable Bitcoin Signed Message of section 4.3.
• <signature> is the 65-byte recoverable signature of section 4.3, pushed as raw bytes (push 41). A builder MUST push the signature as 65 raw bytes and MUST NOT push it base64-encoded (R9); some generic AIP tools base64-encode it, which is a divergence a verifier of this output type does not accept.
• "-1" is the two-byte ASCII selector, pushed as 02 2d31, meaning the signed range of section 4.2. A builder MUST push the selector as the ASCII string -1, not as a numeric encoding (R10).

4.2 The signed range

The selector -1 means the author signs the output-script bytes that precede the author section. Concretely, the signed range is the output script from its first byte up to, and not including, the first byte of the author section:

• when a metadata section is present, the author section begins at the leading pipe push, so the signed range is <lock> <envelope> 0x6a <metadata section>, ending at the last byte of the metadata section; the pipe is not in the signed range;
• when no metadata section is present, the author section begins at the AIP-prefix push, so the signed range is <lock> <envelope> 0x6a, ending at the OP_RETURN byte.

In both cases the signed range includes the OP_RETURN byte 0x6a and excludes the Bitcom pipe that introduces the author section and all of the author-section pushes. A verifier locates the author section by its AIP prefix, treats a pipe push immediately before that prefix as the section delimiter, and takes every byte before that delimiter (or before the prefix, when there is no pipe) as the signed range (R12). Defining the delimiter as outside the signed range is what lets the author compute, and a verifier reconstruct, the same bytes: the pipe belongs to the section it introduces.

A platform MAY add a second author section after the first, separated by a pipe, to attest that it built the output; its signed range then runs up to the pipe that introduces it, so it covers the first author section. Multiple author sections are otherwise out of scope for this BRC.

4.3 The Bitcoin Signed Message preimage

Let M be the signed range of section 4.2. The BITCOIN_ECDSA algorithm signs M as a Bitcoin Signed Message:

1. Form the preimage VARINT(len(magic)) || magic || VARINT(len(M)) || M, where magic is the 24 ASCII bytes Bitcoin Signed Message:\n (the final two characters are a backslash and an n written here for print; the byte is a single line feed, 0x0a), so VARINT(len(magic)) is 0x18. VARINT(x) is x as one byte below 0xfd, else 0xfd and two little-endian bytes up to 0xffff, else 0xfe and four, else 0xff and eight.
2. Compute h = SHA-256(SHA-256(preimage)).
3. Sign h with the author's identity private key, producing a recoverable ECDSA signature (r, s) over secp256k1 with s in low form (s <= N/2, N the group order), and a recovery id in {0, 1, 2, 3}.
4. The 65-byte signature is header || r || s, where r and s are 32 bytes each big-endian, and header = 27 + recid + (4 if the identity public key is used in compressed form). The header is therefore in 0x1b to 0x1e for an uncompressed key and 0x1f to 0x22 for a compressed key.

An author SHOULD use a compressed identity public key, so the header is in 0x1f to 0x22 and the signing address is the compressed-key address (R11). An author MUST produce a low-s signature (R13), so a third party cannot restate the signature with N - s and change the output's bytes while keeping it valid. The per-signature nonce k MUST be unpredictable and MUST NOT repeat for two distinct messages under one key, because two signatures that share k reveal the private key; deterministic generation per RFC 6979 is RECOMMENDED, which removes the dependence on an entropy source and makes a signature reproducible from the key and the message (R19).

4.4 Divergence from generic Bitcom AIP

Generic Bitcom AIP, as encoded by two widely used reference libraries, pushes the fields in the order prefix, algorithm, signing component, signature, and derives the signed bytes from the data cells of the OP_RETURN (the OP_RETURN byte followed by each preceding data push, joined with pipe separators and selected by numeric indices). The 1Sat Ordinals convention this BRC pins differs in two ways: it pushes the signing address before the algorithm name, and its selector -1 signs the raw output-script bytes of section 4.2 rather than the extracted data cells. The rationale for pinning the 1Sat convention is that this output type is a 1Sat inscription, whose authority for what an indexer parses is the 1Sat Ordinals signing document, and whose content, the lock and the envelope, is script structure rather than a sequence of OP_RETURN data elements, so signing the raw script bytes binds the whole inscription. A verifier of this output type MUST read the signing address before the algorithm name and MUST reconstruct the signed range as raw output-script bytes (R12, R14); it MUST NOT apply the generic-AIP data-cell model to this output type.

5. Verification

A verifier reads an output script and reports whether the author signature is valid and which identity key it binds. It MUST (R14):

1. parse the output script structurally into the lock, the envelope, the OP_RETURN, and, after it, the optional metadata section and the author section;
2. locate the author section by its structural position, the single Bitcom pipe immediately after the end of the metadata section (or the OP_RETURN itself, when there is no metadata section), not by scanning the post-OP_RETURN pushes for the AIP prefix 15PciHG22SNLQJXMoSUaWVi7WSqc7hCfva, because that 34-byte string can occur inside inscribed content or a metadata value and a first-occurrence scan would then misplace the boundary (R17, the Mathematical and cryptographic basis);
3. read, at the author section, the AIP prefix, then the signing address, the algorithm name (BITCOIN_ECDSA), the 65-byte signature, and the selector (-1), in that order;
4. reconstruct the signed range M as the output-script bytes before the author section's delimiter (section 4.2);
5. compute the Bitcoin Signed Message hash h of M (section 4.3);
6. reject the signature unless its header byte is in 0x1b to 0x22, its r and s are each in [1, n-1], and s <= n/2 (low-s); then recover the public key from the 65-byte signature and h, rejecting if recovery has no solution or yields the identity point, derive the recovered key's base58check pay-to-public-key-hash address in the compression form the header byte indicates, and require it to equal the pushed signing address.

The signature is valid if and only if step 6's checks pass and the recovered address equals the pushed signing address; a verifier MUST fail closed on any of those checks (R17). A verifier MUST report the signing address as the identity the output binds, and MUST NOT report a valid author signature as proof of who that identity belongs to, which is a certificate's role (section "Relationship to existing standards"). A verifier MUST reject an output whose OP_RETURN is OP_FALSE OP_RETURN as not a transferable inscription (R15), because its satoshi is stranded (section 2.2), even when the author signature over the stranded bytes verifies.

6. Summary of requirements

Test Vectors

The vectors fix the keys, the content, and every byte of two full authenticated outputs, and give five failing cases and the two OP_RETURN forms, so each can be rebuilt from this document. They were produced by a reference generator with no third-party dependencies, and every signature was verified by recovering the public key from the 65-byte signature and the Bitcoin Signed Message hash and comparing the derived address with the pushed signing address. The spendable and unspendable forms were checked against a post-Genesis interpreter.

Keys

Each private key is the SHA-256 of a label, the ASCII string authenticated 1sat inscription test vector: followed by the role, reduced modulo the secp256k1 order. They are test keys and protect nothing.

The content is the 13 ASCII bytes hello ordinal (68656c6c6f206f7264696e616c), content type text/plain. The owner key holds the one satoshi; the author key signs. They are independent.

Building blocks

The lock is 25 bytes, the envelope 34 bytes, the metadata section 65 bytes. The envelope decodes as OP_FALSE OP_IF PUSH("ord") OP_1 PUSH("text/plain") OP_0 PUSH("hello ordinal") OP_ENDIF.

Case A: a named, signed inscription (metadata section and author section)

signed range (indices -1):
  76a9141e465cb42dde36eeeac5c4a68745b269a844d66688ac
  0063036f7264510a746578742f706c61696e000d68656c6c6f206f7264696e616c68
  6a
  223150755161374b36324d694b43747373534c4b79316b683536575755374d745552350353455403617070036170700474797065036f7264046e616d65034f6e65

• signed range, concatenated: 76a9141e465cb42dde36eeeac5c4a68745b269a844d66688ac0063036f7264510a746578742f706c61696e000d68656c6c6f206f7264696e616c686a223150755161374b36324d694b43747373534c4b79316b683536575755374d745552350353455403617070036170700474797065036f7264046e616d65034f6e65 (125 bytes)
• Bitcoin Signed Message hash of the signed range: 6770f94345cd6ef1166d86156bcdb3d3c709b813603abbe889fa2315f2f875dd
• 65-byte signature (header 0x20, a compressed-key recoverable signature): 20213c2d32b58eb3a2c2813cb909dbd5c66b30877ef8862880304ee8bb3eb7aab76274204b7c0b508ff02aacd26eb1fdfd3e258afc5aa4e41c347be4e73728077e
• author section (with leading pipe): 017c22313550636948473232534e4c514a584d6f53556157566937575371633768436676612231436865357477456a4d515a663468656a73725a38676b7036534747544d685870420d424954434f494e5f45434453414120213c2d32b58eb3a2c2813cb909dbd5c66b30877ef8862880304ee8bb3eb7aab76274204b7c0b508ff02aacd26eb1fdfd3e258afc5aa4e41c347be4e73728077e022d31
• full output script (280 bytes): 76a9141e465cb42dde36eeeac5c4a68745b269a844d66688ac0063036f7264510a746578742f706c61696e000d68656c6c6f206f7264696e616c686a223150755161374b36324d694b43747373534c4b79316b683536575755374d745552350353455403617070036170700474797065036f7264046e616d65034f6e65017c22313550636948473232534e4c514a584d6f53556157566937575371633768436676612231436865357477456a4d515a663468656a73725a38676b7036534747544d685870420d424954434f494e5f45434453414120213c2d32b58eb3a2c2813cb909dbd5c66b30877ef8862880304ee8bb3eb7aab76274204b7c0b508ff02aacd26eb1fdfd3e258afc5aa4e41c347be4e73728077e022d31
• SHA-256 of the full output script: 846278345f60241bda23d9ce7d4a0d294ff7137b0c41cffe4e63b150f6a6883c

The author section decodes as PUSH("|") PUSH(<AIP prefix>) PUSH("1Che5twEjMQZf4hejsrZ8gkp6SGGTMhXpB") PUSH("BITCOIN_ECDSA") PUSH(<65-byte signature>) PUSH("-1"). Verification recovers the author address and the signature is valid.

Case B: a signed inscription with no metadata section

The author section follows the OP_RETURN directly, so it has no leading pipe and the signed range ends at the OP_RETURN byte.

• signed range (60 bytes): 76a9141e465cb42dde36eeeac5c4a68745b269a844d66688ac0063036f7264510a746578742f706c61696e000d68656c6c6f206f7264696e616c686a
• Bitcoin Signed Message hash: 98cf3bf18ab3c60b95908eb1bc52812bc0c6c9f82facaae38126b298e7137fa1
• 65-byte signature: 203fbd405503e1b8c0459cb76603e3a18221987454c93007a0e6927d9474c828f2545b9d08bbd0f9e626e6cc0d6f99af75a342b46f8b17265998e9ce8325fc49ed
• full output script (213 bytes): 76a9141e465cb42dde36eeeac5c4a68745b269a844d66688ac0063036f7264510a746578742f706c61696e000d68656c6c6f206f7264696e616c686a22313550636948473232534e4c514a584d6f53556157566937575371633768436676612231436865357477456a4d515a663468656a73725a38676b7036534747544d685870420d424954434f494e5f454344534141203fbd405503e1b8c0459cb76603e3a18221987454c93007a0e6927d9474c828f2545b9d08bbd0f9e626e6cc0d6f99af75a342b46f8b17265998e9ce8325fc49ed022d31
• SHA-256 of the full output script: 62b27c3f0d561070afd76b5d1780d5e42cf5aa4594c681944e331f251766b53a

Verification recovers the author address and the signature is valid.

Failing cases

Each failing case is a signature that a verifier following section 5 rejects, and the reason.

• The pipe inside the signed range. The author mistakenly signs the signed range of case A with the leading pipe appended (...034f6e65017c), producing the signature 1f52964f6545c9498141c445b10fb6d1e6c864a664e2600a4992b3682ebe235a69299830431dcb490defb0d07dc6464f5659897c7f295c6a8636a62115145bdee7. A verifier reconstructs the signed range without the pipe (section 4.2) and recovers a different address, so the signature over the canonical range is invalid. This case exists to catch R12.
• The wrong key. A different identity signs the case A signed range, producing 20587cfbf6894f03072c5d5bd0f1428b0e45fd9454d5e33c032edb4d7f0d5df05035db4b0010dfa822ba683a749e1b7c1e1bdc42f371c40a9a435380c915a905f4. The signature is a valid Bitcoin Signed Message, and recovery yields 1FZVqS6fZ6ELNQDcuHRCF1CGi1DHBaD9yQ, not the author address the output pushes, so verification against the pushed author address fails. This case shows that recovery binds the output to exactly one address.
• Tampered content. The content byte string is changed by one byte (hello ordinal to hello ordina1), so the envelope and the signed range change, while the case A signature 20213c2d32b58eb3a2c2813cb909dbd5c66b30877ef8862880304ee8bb3eb7aab76274204b7c0b508ff02aacd26eb1fdfd3e258afc5aa4e41c347be4e73728077e is kept. Over the tampered range (...6f7264696e6131...) recovery yields a different address, so the signature is invalid. This case shows the signature binds the inscribed content.
• Reversed field order (the generic-AIP order). The author section of case A is rebuilt in the generic Bitcom-AIP order, the algorithm name before the signing address, giving author section 017c22313550636948473232534e4c514a584d6f53556157566937575371633768436676610d424954434f494e5f45434453412231436865357477456a4d515a663468656a73725a38676b7036534747544d685870424120213c2d32b58eb3a2c2813cb909dbd5c66b30877ef8862880304ee8bb3eb7aab76274204b7c0b508ff02aacd26eb1fdfd3e258afc5aa4e41c347be4e73728077e022d31. A verifier following section 5 reads the field after the prefix as the signing address and finds BITCOIN_ECDSA, which is not the base58check address the output is claiming, so verification fails. This case shows why this BRC pins the 1Sat field order (R8, R14) and that the generic-AIP order does not interoperate with it.
• Base64-encoded signature. The author section of case A is rebuilt with the signature pushed base64-encoded as the 88 ASCII bytes ICE8LTK1jrOiwoE8uQnb1cZrMId++IYogDBO6Ls+t6q3YnQgS3wLUI/wKqzSbrH9/T4livxapOQcNHvk5zcoB34= instead of the 65 raw bytes, giving author section 017c22313550636948473232534e4c514a584d6f53556157566937575371633768436676612231436865357477456a4d515a663468656a73725a38676b7036534747544d685870420d424954434f494e5f45434453414c58494345384c544b316a724f69776f453875516e6231635a724d49642b2b49596f6744424f364c732b74367133596e51675333774c55492f774b717a53627248392f54346c69767861704f51634e48766b357a636f4233343d022d31. The signature push is 88 bytes and its first byte is 0x49, not a recoverable-signature header in 0x1b to 0x22, so a verifier rejects it before recovery. This case shows why the signature MUST be 65 raw bytes (R9) and not base64.

The two OP_RETURN forms

The spendable and unspendable templates differ by one byte. Both are shown through the metadata section, with the lock and envelope of the building-blocks table.

• spendable prefix (bare OP_RETURN, ...6168 6a ...): 76a9141e465cb42dde36eeeac5c4a68745b269a844d66688ac0063036f7264510a746578742f706c61696e000d68656c6c6f206f7264696e616c686a
• unspendable prefix (OP_FALSE OP_RETURN, ...6168 00 6a ...): 76a9141e465cb42dde36eeeac5c4a68745b269a844d66688ac0063036f7264510a746578742f706c61696e000d68656c6c6f206f7264696e616c68006a

Spent through the owner lock, the first validates (the top stack item at OP_RETURN is true) and the satoshi can be transferred; the second does not (the top item is the false value OP_FALSE pushed) and the satoshi is stranded. A builder MUST produce the first form (R3); a verifier MUST reject the second as a transferable inscription (R15).

Implementations

A reference builder and verifier for the authenticated output exist in a privacy wallet: the builder assembles the lock, the envelope, the bare OP_RETURN, the optional metadata section and the author section in the order of section 4, signs the signed range with the account's identity key, and funds a 1-satoshi output; the verifier locates the author section structurally, recovers the key, and reports the bound address, as section 5 requires. The Test Vectors above were produced by a self-contained generator using a pure secp256k1, Bitcoin Signed Message and base58check implementation with no third-party dependency, and every signature in them was checked by public-key recovery back to the author address. The spendable and unspendable OP_RETURN forms of section 2 were each evaluated on a post-Genesis script interpreter under a restrictive policy: the bare form validated and its satoshi spent, the OP_FALSE OP_RETURN form did not. Two interoperability items remain to confirm against a live 1Sat indexer before marketplace interoperability is claimed: the exact field order and selector of the author section (section 4), and the relay standardness of the full metadata-and-author trailer on a current node.

Mathematical and cryptographic basis

This section fixes the constants and definitions the rest of the document relies on (the group, the compressed encoding, HASH160, base58check, and the message hash), and states what a passing author verification proves and on which assumptions. It is normative for those definitions. Notation: || is byte concatenation; a quoted string is its ASCII bytes; VARINT is the Bitcoin variable-length integer of section 4.3; integers inside a point or a signature are 32 bytes big-endian unless stated.

The secp256k1 group

All keys and signatures are over secp256k1, the curve of Bitcoin's ECDSA: the points (x, y) with x, y in the prime field F_p satisfying

y^2 = x^3 + 7   (mod p)            [a = 0, b = 7]

together with a point at infinity O, the group identity, under chord-and-tangent addition. The parameters are fixed:

p  = FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE FFFFFC2F
   = 2^256 - 2^32 - 977                                   (the field prime)
n  = FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE BAAEDCE6 AF48A03B BFD25E8C D0364141
                                                           (the order of G)
Gx = 79BE667E F9DCBBAC 55A06295 CE870B07 029BFCDB 2DCE28D9 59F2815B 16F81798
Gy = 483ADA77 26A3C465 5DA4FBFC 0E1108A8 FD17B448 A6855419 9C47D08F FB10D4B8
h  = 1                                                     (the cofactor)

G generates a cyclic subgroup of prime order n; because the cofactor is 1 that subgroup is the whole curve, so every non-identity point has order n. Scalar multiplication dG is G added to itself d times. Security rests on the elliptic-curve discrete-logarithm problem (ECDLP): given Q = dG it is infeasible to recover d, the best known attack costing about sqrt(n) which is near 2^128 group operations.

Keys and their addresses

A private key is an integer d with 1 <= d <= n - 1; its public key is the point Q = dG. The bound excludes d = 0 (which gives the identity O, which has no address and no valid signature), so Q always has order n. ECDLP makes Q computable from d but d infeasible from Q, which is why only the holder of d can produce a signature that verifies to Q.

A point Q = (x, y) is encoded in SEC1 compressed form as the 33 bytes

enc(Q) = prefix || x,    prefix = 0x02 if y is even, 0x03 if y is odd.

The prefix records the parity of y, which the curve equation then recovers from x. The two hashes used are

HASH160(b) = RIPEMD160(SHA256(b))      (20 bytes)
HASH256(b) = SHA256(SHA256(b))         (32 bytes)

and the signing address pushed in section 4.1 is base58check over the pubkey hash with the mainnet P2PKH version byte 0x00:

payload  = 0x00 || HASH160(enc(Q))     (21 bytes)
checksum = HASH256(payload)[0:4]
A(Q)     = Base58(payload || checksum)

over the standard Bitcoin base58 alphabet. HASH160 is taken over the encoded bytes, so enc(Q) and the uncompressed 0x04 || x || y hash to two different addresses for one point; R11 RECOMMENDS the compressed form. The version byte is fixed at 0x00 for this profile; other networks are out of scope. Because enc, HASH160, HASH256 and base58check are deterministic, two conforming verifiers derive the identical address from a recovered Q, which is what R14's agreement requirement needs.

The signed message

Let S be the signed range of section 4.2: the raw output-script bytes from the start of the lock up to the first byte of the author section,

S = L || E || 0x6a                     (no metadata), or
S = L || E || 0x6a || Meta             (metadata present)

where L is the lock, E the BRC-160 envelope, 0x6a the bare OP_RETURN, and Meta the raw bytes of the MAP metadata section. S is taken byte for byte, including every pushdata length prefix inside E and Meta; a verifier MUST NOT canonicalize it before hashing. The Bitcoin Signed Message preimage and its hash are

pm(S) = VARINT(24) || "Bitcoin Signed Message:\n" || VARINT(len(S)) || S
      = 0x18 || "Bitcoin Signed Message:\n" || VARINT(len(S)) || S
h(S)  = HASH256(pm(S))                 (the 32-byte message hash)

the magic being the 24 bytes ending in a single line feed 0x0a.

Framing lemma. Because pm prefixes S with its own length VARINT(len(S)), the map S -> pm(S) is injective over byte strings shorter than 2^64: no S' != S yields the same preimage, and no S can be extended or truncated into another valid preimage. Hence distinct signed ranges give distinct preimages, and under the collision resistance of HASH256 distinct message hashes except with negligible probability:

S != S'  =>  pm(S) != pm(S')  =>  h(S) != h(S')   (except negligibly).

The length prefix is also why appending a second author or platform section, which lies outside S, cannot change h(S).

Signing, low-S, and public-key recovery

For a private key d, a per-signature nonce k in [1, n-1], R = kG = (xR, yR), and the message hash z = h(S) read big-endian and reduced mod n, the signature is

r = xR mod n
s = k^{-1} * (z + r*d)  mod n,   with s <= n/2 enforced (low-S).

The nonce k MUST be unpredictable and MUST NOT repeat for two distinct messages under one key: two signatures sharing k reveal d. Deterministic generation per RFC 6979 is RECOMMENDED, which both removes the entropy dependence and makes the test vectors reproducible. Low-S (s <= n/2) removes the s versus n - s signature malleability; a verifier MUST reject a signature with s > n/2.

The 65-byte recoverable encoding is header || r || s (r, s each 32 bytes big-endian), with

header = 27 + recid + (4 if the key is used compressed),   recid in {0,1,2,3},

so header is in 0x1b .. 0x22; a verifier MUST reject a header outside that range. recid fixes R.y's parity and whether xR >= n. Verification is by public-key recovery:

Recover(z, r, s, recid) = r^{-1} * ( s*R - z*G )  (on the curve),

reconstructing R from xR = r (plus n when recid says so) and the parity bit. The verifier derives A(Q') of the recovered Q' in the compression form the header indicates and accepts the author section iff A(Q') equals the pushed signing address. Recovery MUST fail closed: if r or s is outside [1, n-1], if xR is not an x-coordinate of a curve point, or if Q' is the identity, the verifier rejects.

The provenance binding

Fix an author key pair (d, Q) with address A = A(Q). For an output W write S(W) for its signed range and sig(W) for the 65 author bytes. Call W author-valid iff A(Recover(h(S(W)), sig(W))) = A.

Claim. Let W be author-valid. Then:

1. Reuse fails. Any W' with S(W') != S(W) carrying the same sig(W) is author-valid only with negligible probability: by the framing lemma h(S(W')) != h(S(W)), and a fixed (r, s) recovers, over a changed hash, an effectively unrelated point whose address equals A only with probability near 2^-160.
2. Forgery requires the key. An author-valid W' with a fresh signature over h(S(W')) that verifies to A is an ECDSA existential forgery under the key d; under ECDLP and the random-oracle model for HASH256 this succeeds only negligibly. A fresh signature by the holder of d is therefore necessary.
3. What a change costs. L, E (content type and content) and Meta (the name and key-value pairs) are all substrings of S. Redirecting ownership changes L; copying the inscribed content under a different type or content changes E; renaming changes Meta. Each changes S, so by (1) and (2) the existing signature no longer verifies and a valid one binding A can be made only by the holder of d.

This is the provenance guarantee: a copy of the content under a different lock, name, or content is a different message and needs a fresh signature by the same key. The assumptions are ECDLP hardness on secp256k1, ECDSA existential unforgeability in the random-oracle model, collision and second-preimage resistance of SHA-256 (hence HASH256) and of HASH160, the determinism of enc, HASH160 and base58check, and the framing injectivity of pm.

Assumptions and edge cases

• Exact-byte binding. S is raw bytes, so the signature binds the precise pushdata encoding. A logically equivalent re-encoding (a non-minimal push, or the BRC-160 0x00/0x01 aliases for OP_0/OP_1) is a different S and a different message. This is sound for a verifier, which re-reads the raw bytes, but a builder MUST emit minimal, fixed push forms throughout the signed range (the lock, envelope and metadata section) so the content-to-S map is deterministic (R16).
• Author-section boundary. S(W) is well defined only if the first byte of the author section is. The boundary is structural: parse the lock, the envelope, and the MAP section to their ends, then take the single Bitcom pipe (or the OP_RETURN, when there is no metadata) immediately before the AIP prefix. A first-occurrence scan for the 34-byte AIP prefix is unsafe, because that byte string can occur inside inscribed content or a metadata value and would shift S; verifiers determine the boundary structurally.
• Compression-bit restatement. One signature recovers one Q, but Q has a compressed and an uncompressed address; the header bit and the pushed address both lie outside S, so a third party can restate an author-valid output under the other-form address of the same key without d. The key holder's authorship is preserved; only the displayed address form is malleable. A verifier binds the compression form the header indicates and requires it to equal the one pushed address; an application that wants to treat a key as a single identity regardless of address form maps both the compressed and the uncompressed address of one Q to that identity.
• Outpoint non-binding. h(S) commits to no outpoint, value, or transaction, so a verbatim copy of the whole authenticated output at a new outpoint still verifies. Provenance here means the key authored this script (content, lock, and name), not that the key created a unique token: two BRC-159 origins carrying identical authenticated content are indistinguishable by the signature alone.
• Empty and multiple envelopes. A zero-length content or content-type push keeps S well defined, and the envelope parser frames it as a zero-length byte string. More than one envelope in one authenticated output leaves S well defined as raw bytes but makes the reported content ambiguous; a builder MUST place exactly one envelope in an authenticated output.

Security Considerations

What the signature proves. A valid author signature proves that the holder of the identity private key for the pushed address produced a signature over the exact bytes of the signed range: the lock, the envelope, the OP_RETURN, and any metadata section. Because the signed range includes the envelope, it binds the content type and the content; because it includes the lock, it binds the initial owner; because it includes the metadata section, it binds the name an indexer will show. A copy of the content into a new output, under a new lock or a new name, has a different signed range and so needs a fresh signature by the same key, which only the key holder can make.

What it does not prove. The signature proves control of a key, not the real-world or pseudonymous identity behind it. Binding the key to an identity is a certificate's role (BRC-52) or a decentralized identifier's (BRC-202). A verifier that reports the recovered address as "the author" without such a binding states only which key signed. The signature also says nothing about the current owner once the token has been transferred: it binds the output as created, and a later holder is established by the BRC-159 chain, not by this signature.

The stranded-satoshi trap. The single most damaging error is OP_FALSE OP_RETURN in place of the bare OP_RETURN. It is one byte, it relays, it confirms, and the author signature over its bytes verifies, yet the one satoshi can never be spent and the token is dead at that outpoint. R3 and R15 exist to catch it on both sides: a builder must never emit it, and a verifier must refuse to treat such an output as a transferable inscription even when its signature is valid.

Malleability. The author signature is over output-script bytes, so it is unaffected by transaction-level malleability of the spend that creates or transfers the output. The signature itself MUST be low-s (R13); otherwise a third party could restate it as header' || r || (N - s) and change the output's bytes while keeping the signature valid, which would change the signed range and the token's bytes. Because the signature is pushed behind OP_RETURN as data and is never executed, the node does not enforce low-s on it; the author and the verifier enforce it.

Replay and competing authorship. The signature is over output-script bytes and commits to no outpoint, value, or transaction (the Mathematical and cryptographic basis), so a third party can copy the whole authenticated output verbatim into a transaction of their own at a new outpoint, and it still verifies to the same author. This creates a second BRC-159 origin carrying identical authenticated content that the signature alone cannot distinguish from the first. The signature proves that the key authored this script (content, lock, and name), not that the key created a unique token, and it does not establish priority: an author signature carries no timestamp, so of two outputs authenticating the same content the signature does not say which was inscribed first. A party who wants provenance to mean first-published MUST anchor it outside the signature, for example by the earliest confirming transaction or a timestamping service, and an indexer that ranks origins by authorship MUST obtain that ordering elsewhere. Because the lock is inside the signed range, a copier cannot redirect ownership to themselves without a fresh signature by the key, so replay reproduces the author's own output, it does not forge a new owner.

Key reuse across the address. The signing address is the ordinary pay-to-public-key-hash address of the identity key. Signing many inscriptions with one key links them all to one address, which is the point for provenance and a cost for privacy (see Privacy Considerations). An author who also receives payments to that address mixes payment history with authorship; an author SHOULD use an identity key distinct from its spending keys.

Privacy Considerations

An authenticated inscription is public in full from the moment it is created: the content, the content type, the name, and the author's address are all in the output script in the clear, and the signature binds them. Every inscription an author signs with one identity key carries the same address, so an observer links them into one body of work, and links that work to any other on-chain use of the address. An author who wants authorship to be verifiable but not trivially aggregated should use a distinct identity key per context, at the cost of each context's inscriptions being provable only within it. An author who wants the content private should not inscribe it in the clear; sealing the content before inscription, and signing the sealed bytes, keeps the authorship provable while the content stays encrypted until the author discloses the key, but that construction is out of scope here. The metadata section is optional for the same reason: a builder that omits it (section 3) removes the name and the key-value pairs that would otherwise make an inscription easy to find and classify, while the author signature and the content remain.

References

• [BRC-3] Digital Signature Creation and Verification. wallet/0003.md
• [BRC-18] Pay to False Return. scripts/0018.md
• [BRC-19] Pay to True Return. scripts/0019.md
• [BRC-21] Push TX. scripts/0021.md
• [BRC-48] Pay to Push Drop. scripts/0048.md
• [BRC-52] Identity Certificates. peer-to-peer/0052.md
• [BRC-77] Message Signature Creation and Verification. peer-to-peer/0077.md
• [BRC-147] 1Sat Ordinals Basket Profile for BRC-46 / BRC-100. tokens/0147.md
• [BRC-150] 1Sat Provenance Remittance for Basket 1sat. tokens/0150.md
• [BRC-159] 1Sat Ordinals, Single-Satoshi Tokens and Origin Tracking. tokens/0159.md
• [BRC-160] 1Sat Ordinals, Inscription Envelopes. tokens/0160.md
• [BRC-202] Identity-Key Decentralized Identifiers. peer-to-peer/0202.md
• [AIP] Author Identity Protocol. https://github.com/attilaaf/AUTHOR_IDENTITY_PROTOCOL
• [AIP-1SAT] 1Sat Ordinals signing convention. https://docs.1satordinals.com/adding-metadata/signing and https://github.com/BitcoinSchema/1sat-ordinals/blob/master/adding-metadata/signing.md
• [AIP-GO] Author Identity Protocol reference library (Go). https://github.com/BitcoinSchema/go-aip
• [AIP-JS] Bitcoin schema metadata parser (TypeScript), AIP protocol. https://github.com/rohenaz/bmap
• [MAP] Magic Attribute Protocol. https://github.com/rohenaz/MAP
• [BSM] Bitcoin Signed Message, the recoverable message-signing construction with the magic prefix Bitcoin Signed Message: and a line feed. https://github.com/bitcoinjs/bitcoinjs-message
• [GENESIS] The Genesis upgrade specification, post-Genesis OP_RETURN semantics. https://github.com/bitcoin-sv-specs/protocol/blob/master/updates/genesis-spec.md
• [RFC2119] S. Bradner, Key words for use in RFCs to Indicate Requirement Levels. https://www.rfc-editor.org/rfc/rfc2119
• [RFC8174] B. Leiba, Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words. https://www.rfc-editor.org/rfc/rfc8174
• [RFC6979] T. Pornin, Deterministic Usage of DSA and ECDSA. https://www.rfc-editor.org/rfc/rfc6979
• [FIPS180-4] NIST, Secure Hash Standard (SHS), FIPS PUB 180-4 (SHA-256). https://doi.org/10.6028/NIST.FIPS.180-4
• [RIPEMD160] H. Dobbertin, A. Bosselaers, B. Preneel, RIPEMD-160: A Strengthened Version of RIPEMD. https://homes.esat.kuleuven.be/~bosselae/ripemd160.html