Protocol

Metadata & attribution

A first-class, signed metadata field on the transaction: builder/app attribution, payment references, and commitments to off-chain data, without overloading a call.

Why a top-level field

Legacy transactions carry attribution and annotation data as a trailing “data suffix” appended to tx.input. 8130 replaces the single input blob with a structured calls array, so there is no trailing location to piggyback on. Rather than smuggle attribution into a call's argument bytes, 8130 gives it a dedicated, optional metadata field in the envelope.

Concept	Meaning
Signed	metadata is covered by both the sender and payer signature payloads, so it is tamper-evident: a relayer or builder cannot rewrite attribution.
Charged, but inert	Priced per byte through tx_payload_cost like any other tx bytes. It does not affect validation or execution.
Off-chain consumers	Indexers, explorers, and payment services read it directly from the transaction. Producers MAY use any encoding.
Opaque by default	The protocol treats it as bytes. Structure is defined by a companion encoding standard, not by consensus.

What goes in it

Attribution: builder / app / wallet codes, so front-ends and infra can be credited or measured onchain-adjacent.
Memo / reference: a human memo or a payment reference for reconciliation.
Commitment: a digest committing to off-chain data (an invoice, a remittance document) that can be selectively revealed later.

Attribution codes

The dominant use is attribution. 8130 does not mint its own code registry; it reuses the ERC-8021 attribution key space (app, wallet, and related codes) so existing registries and parsers apply unchanged. In a sponsored flow, the same field lets an app credit itself while a payer service (ERC-8168) covers gas, attribution and payment stay independent.

Structured encoding (experimental)

The prototype encodes metadata as a single deterministic CBOR value in four forms, so the common cases cost only a few bytes over the raw data:

Concept	Meaning
text string	A memo. A bare text string is shorthand for { t: <text> }.
byte string	A commitment digest (typically 32 bytes).
map	Reserved keys: ERC-8021 schema-2 attribution keys (a/w/…), plus h (commitment), t (text memo), and scope keys p (phase) and c (call).
array	Several of the above in one field (e.g. attribution + per-call commitments).

There is no magic byte: a parser branches on the CBOR major type, and foreign producers that opt out lead with 0xFF (which can never begin a well-formed CBOR item). The same value can also ride other transports, e.g. a calldata data suffix on non-8130 transactions, where the scope keys simply do not apply.

Example: sponsored transfer with attribution

A sponsored USDC transfer. The payer prepends its settlement in phase 0; the user's transfer runs in phase 1. The wallet tags the user action with app and wallet codes, scoped to phase 1 so the credit attaches to the intended action, not the payer's repay.

metadata (CBOR diagnostic notation)text

{ a: h'a1b2c3',   // app code    (ERC-8021)
  w: h'6d7977',   // wallet code (ERC-8021)
  p: 1 }          // scope: phase 1 only

// encoded ≈ 27 bytes

Example: batch commitments + Merkle root

A self-paid batch of five remittances. Each transfer carries a commitment to its off-chain remittance document, scoped to its own call. Aggregating the five digests into one Merkle root keeps every document individually provable while collapsing the field to a single record.

per-call commitments vs one Merkle roottext

// One record per call, each scoped to its call index:
[ { h: h'…d1', c: 0 },
  { h: h'…d2', c: 1 },
  { h: h'…d3', c: 2 },
  { h: h'…d4', c: 3 },
  { h: h'…d5', c: 4 } ]        // ≈ 211 bytes

// Or aggregate into a single tx-scoped Merkle root:
{ h: h'…root' }               // ≈ 41 bytes
// each leaf still provable via a Merkle proof;
// revealing one leaf discloses only sibling hashes

Selective disclosure

Any value MAY be replaced by a salted commitment, recursively: one primitive for privacy-preserving attribution and off-chain references. The producer keeps the preimage and shares a proof package out-of-band; a verifier checks it against the onchain digest. Salting each leaf prevents confirming guesses about siblings.

Wallet integration (ERC-5792)

The prototype also defines an ERC-5792 metadata capability that supersedes the old dataSuffix: apps pass typed, scoped records to the wallet, and the wallet resolves scope against the finalized calls and encodes the signed field. Scope values MUST be encoded only after calls is finalized, since a sponsor may prepend a phase.