Specifies the peer-to-peer payment flow defined in BRC-29, including BRC-42 key derivation prefix/suffix negotiation, the current Atomic BEEF payment message, and the BRC-100 internalizeAction remittance envelope.
The older BRC-8 extended-envelope format (the transactions array) is
deprecated for new integrations; only the current BRC-100 / Atomic BEEF
transport is modelled here.
Source of truth: /docs/BRCs/payments/0029.md
Logical channel representing a sender delivering a BRC-29 payment message to a recipient. In practice this is carried over whatever higher-level transport the application chooses (HTTP POST, WebSocket, BRC-104 message box, etc.). The channel models the one-way delivery of the payment.
Sender delivers a BRC-29 payment message to the recipient.
Accepts the following message:
Current (BRC-100 / Atomic BEEF) payment message sent from the payer to the payee. Carries one transaction with one or more P2PKH outputs derived via BRC-42 key derivation using the invoice number format `2-3241645161d8-<derivationPrefix> <derivationSuffix>`.
Payment message delivered from sender to recipient. The transaction
field carries a base64-encoded Atomic BEEF blob (BRC-95). For payments
containing multiple outputs each output MUST carry its own
derivationSuffix and outputIndex so the recipient can recover the
correct P2PKH private key for each UTXO.
{
"derivationPrefix": "3q2+7w==",
"derivationSuffix": "iMba2Q==",
"transaction": "<base64-encoded-BEEF>",
"outputs": [
{
"outputIndex": 0,
"derivationSuffix": "X9k4LA=="
}
],
"senderIdentityKey": "02abc123..."
}
Logical channel representing the recipient acknowledging acceptance or rejection of the incoming payment after calling internalizeAction.
Sender receives payment acceptance or rejection from the recipient.
Accepts the following message:
Informal acknowledgement returned by the recipient after calling BRC-100 internalizeAction. No mandatory wire format is defined by BRC-29; the shape below is the conventional minimal envelope.
Minimal response returned to the sender after the recipient has called
internalizeAction. BRC-29 does not mandate a wire format; this is
the conventional shape used by ts-sdk integrations.
{
"accepted": true,
"txid": "string",
"error": "string"
}
Current (BRC-100 / Atomic BEEF) payment message sent from the payer to the payee. Carries one transaction with one or more P2PKH outputs derived via BRC-42 key derivation using the invoice number format `2-3241645161d8-<derivationPrefix> <derivationSuffix>`.
Payment message delivered from sender to recipient. The transaction
field carries a base64-encoded Atomic BEEF blob (BRC-95). For payments
containing multiple outputs each output MUST carry its own
derivationSuffix and outputIndex so the recipient can recover the
correct P2PKH private key for each UTXO.
Informal acknowledgement returned by the recipient after calling BRC-100 internalizeAction. No mandatory wire format is defined by BRC-29; the shape below is the conventional minimal envelope.
Minimal response returned to the sender after the recipient has called
internalizeAction. BRC-29 does not mandate a wire format; this is
the conventional shape used by ts-sdk integrations.
Payment message delivered from sender to recipient. The transaction
field carries a base64-encoded Atomic BEEF blob (BRC-95). For payments
containing multiple outputs each output MUST carry its own
derivationSuffix and outputIndex so the recipient can recover the
correct P2PKH private key for each UTXO.
Describes one P2PKH output within a multi-output BRC-29 payment.
BRC-42 invoice number used to derive the recipient's P2PKH key for each
output. Format: 2-3241645161d8-<derivationPrefix> <derivationSuffix>
where:
2 = security level (BRC-43)3241645161d8 = BRC-29 magic numberRemittance object passed to BRC-100 internalizeAction for each
payment output. The recipient's wallet uses these fields to derive
the private key and credit the UTXO.
Arguments passed to the BRC-100 internalizeAction wallet method by
the recipient when processing an incoming BRC-29 payment.
Minimal response returned to the sender after the recipient has called
internalizeAction. BRC-29 does not mandate a wire format; this is
the conventional shape used by ts-sdk integrations.
Deprecated. The original BRC-8 extended-envelope format. New
integrations MUST NOT use this format; use PaymentMessage instead.
Documented here only for backwards-compatibility reference.