# Format for Bitcoin Outpoints

Ty Everett (`ty@projectbabbage.com`)

## 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](/wallet/0100.md) 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](/transactions/0008.md) transaction envelopes and optional mAPI responses. That representation is no longer normative for interoperable wallet behavior.

Current interoperable wallet systems use the [BRC-62](/transactions/0062.md) / [BRC-95](/transactions/0095.md) 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](/transactions/0095.md) 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](/transactions/0095.md) 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](/transactions/0008.md) 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](/outpoints/0037.md), [BRC-46](/wallet/0046.md), and [BRC-100](/wallet/0100.md).

## 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](/wallet/0100.md).

### 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](/wallet/0100.md) 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](/transactions/0095.md) 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](/wallet/0100.md):

* `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

```json
{
  "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.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://bsv.brc.dev/outpoints/0036.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.