Reference
TCC-0005 Recipient payloads
The TRP layout that packs one payload per recipient into a transaction's single payload. The marker, the entries, and the rules for reading and writing.
| Number | TCC-0005 |
|---|---|
| Status | Final |
| Category | Payments |
| Identifier | Marker 00 54 52 50 01 (TRP, version 1) |
A transaction has one payload. A payment to several recipients can give each of them its own payload by packing them into that one field in the layout below. Consensus does not look inside: the node checks only the payload's size, and anyone can read every entry. Wallets show a recipient the entries for its own outputs; explorers show each entry beside its output.
Layout
| Bytes | Field |
|---|---|
| 5 | Marker 00 54 52 50 01: a zero byte, ASCII TRP, version 1 |
Then one entry after another, at least one:
| Bytes | Field |
|---|---|
| 1 | Output index the payload belongs to |
| 2 | Payload length, big-endian, at least 1 |
| length | The payload |
Output indexes rise strictly from entry to entry, so an output has at most one payload. Outputs without an entry, such as the change, have none. The whole field stays within the manifest's max_transparent_payload_bytes (1,024 bytes), marker and headers included.
Two entries, Rent for output 0 and the bytes 00 ff for output 3:
0054525001 00 0004 52656e74 03 0002 00ffReading
A payload is in this layout only when it starts with the marker and every entry is complete, with nothing after the last one. Anything else is an ordinary payload for the whole transaction, as before. No text payload can be mistaken for it: text never starts with a zero byte.
An entry is shown as text when it is UTF-8 and passes the wallets' safe-text rule (no control, direction, format, invisible or private characters, no piles of marks); otherwise as hex. Wallets take a recipient's payload as text only under the same rule.
Writing
Wallets build the entries from the payments in their order: the payment at position i becomes output i, and the change output comes last. A payment to several recipients carries either one payload for all of them or one payload per recipient, never both.
Vectors
crates/wallet/tests/vectors/recipient-payloads-v1.json in the node repository lists layouts with their entries and payloads that are not in this layout. The Rust crates, the WASM, the SDK, the web wallet and the explorer check against it.