Format for Bitcoin Outpoints

Abstract

This document specifies the canonical portable format for representing a Bitcoin outpoint together with the minimum data required for interoperable validation and use. The format is intentionally narrow: it standardizes the identity of the output, its value, its optional locking script, and the transaction-validity payload required to verify the creating transaction. This specification aligns with the output model used by BRC-100 and current Wallet Toolbox implementations.

Motivation

Outputs are the fundamental bearer objects of Bitcoin. They are also the units tracked, discovered, moved, and reinterpreted by modern wallet software. Historically, some implementations represented outputs together with BRC-8 transaction envelopes and optional mAPI responses. That representation is no longer normative for interoperable wallet behavior.

Current interoperable wallet systems use the BRC-62 / BRC-95 BEEF family for transaction-validity data, and use compact output objects centered on the outpoint itself. This document updates BRC-36 to reflect that reality while preserving its original purpose: defining a portable and implementation-neutral baseline format for Bitcoin outputs.

Specification

Canonical JSON Object

A BRC-36 outpoint object is a JSON object with the following fields:

• outpoint (required): The canonical identifier for the output, encoded as an outpoint string in the form <txid>.<vout>.
• satoshis (required): The number of satoshis contained in the output.
• lockingScript (optional): The hex-encoded Bitcoin locking script for the output.
• tx (required): The transaction-validity payload for the creating transaction, encoded in BRC-95 Atomic BEEF format.

Semantics

• The outpoint field is the canonical identifier of the output. Implementations MAY derive txid and vout from this field for internal use, but they are not part of the canonical BRC-36 object.
• The lockingScript field is optional because some contexts only require identification and proof of the output, while others additionally require the locking script bytes.
• The tx field is required. A BRC-36 object is intended to be self-contained with respect to transaction validation data.
• The tx field MUST encode an Atomic BEEF whose subject transaction is the transaction identified by the txid component of the outpoint.
• The Atomic BEEF payload MUST contain sufficient data to validate the subject transaction according to the rules of the BEEF family of specifications.

Explicit Replacement of Historical Assumptions

The following historical representations are not normative for BRC-36:

• BRC-8 transaction envelopes
• rawTx, inputs, proof, and mapiResponses as BRC-36 fields
• mAPI-era output-sharing formats

Implementations MAY continue to support such formats for historical compatibility, but interoperable BRC-36 exchange is defined only by the object specified in this document.

Scope Boundaries

BRC-36 standardizes portable output facts only. It does not standardize wallet-internal state such as:

• spendability flags
• change classification
• wallet-specific purpose or type labels
• storage-layer IDs or offsets
• basket assignment
• tags or labels
• custom spending metadata

These concerns are either internal to a wallet or defined by other standards such as BRC-37, BRC-46, and BRC-100.

Binary Profile

In addition to the canonical JSON object, BRC-36 defines a canonical standalone binary representation for a single outpoint object. This binary profile is designed to be independently usable while remaining aligned with the serialization conventions employed by BRC-100.

Binary Field Order

The binary representation of a BRC-36 object consists of the following fields in order:

• outpoint (Byte Array): The outpoint, encoded as 32 bytes of TXID followed by the output index.
• satoshis (VarInt): The number of satoshis in the output.
• lockingScript (VarInt Length + Byte Array): The locking script, if present. If absent, encode -1.
• tx (VarInt Length + Byte Array): The required Atomic BEEF payload.

Binary Encoding Rules

• The outpoint field MUST use the same byte-level representation employed by BRC-100 for output objects.
• The satoshis field MUST be encoded as a VarInt.
• If lockingScript is absent, its length field MUST be encoded as -1.
• The tx field MUST be present and MUST contain a valid BRC-95 Atomic BEEF byte sequence.
• The binary profile carries exactly the same semantics as the canonical JSON form and MUST NOT introduce transport-only framing fields.

Mapping to BRC-100

This specification is intentionally aligned with the output model used by BRC-100:

• outpoint aligns directly with the BRC-100 output identifier.
• satoshis aligns directly with the BRC-100 output amount.
• lockingScript, when included, aligns directly with the optional script-return behavior in BRC-100 listOutputs.
• tx corresponds to the transaction-validity payload returned in BRC-100 contexts that include full transaction data, except that BRC-36 standardizes a single-output portable object and requires the payload to be an Atomic BEEF associated with that output's creating transaction.

Example

JSON Example

{
  "outpoint": "7001295a287fee8e7ad5de58ed30bd61923977ddc9b7a44830ebb9a68b12dc39.0",
  "satoshis": 500,
  "lockingScript": "76a9148055582669432149141abcf887fced6881f7404288ac",
  "tx": "01010101..."
}

Binary Layout Example

[outpoint bytes][satoshis varint][lockingScript length + bytes]
[atomicBEEF length + bytes]

Implementation

Implementations of BRC-36 should adhere to the following guidelines:

• Treat outpoint as the canonical identifier at the interoperability boundary.
• Include lockingScript whenever the recipient is expected to inspect or evaluate the script.
• Ensure the tx payload is a valid Atomic BEEF for the transaction that created the output.
• When other standards extend this object, preserve the semantics of the four base fields defined here.