Skip to main content
Per-Transaction Attribution Discipline (PTAD) is the fourth of Intention’s four protocol-native guarantees. It is the construction that reconciles two requirements that normally pull in opposite directions: batch-matching throughput and per-transaction auditability.

​
Definition

Let B=(t0,…,tn−1)B = (t_0, \ldots, t_{n-1}) be a committed block and let δ(Σ,B)=(Σ′,E,O)\delta(\Sigma, B) = (\Sigma', E, O), where O=(O0,…,On−1)O = (O_0, \ldots, O_{n-1}) is the per-transaction output array. Each OiO_i is a pair (WriteSeti,Eventsi)(\text{WriteSet}_i, \text{Events}_i). PTAD requires:
For any finalized block BB with pre-state Σ\Sigma, the output array OO is a pure function of (Σ,B)(\Sigma, B). Any two implementations of δ\delta produce the same OO up to byte equality. Moreover, no state change or event exists in δ(Σ,B)\delta(\Sigma, B) that is not present in some OiO_i or in the designated system-write channel.
The last clause — that nothing is dropped — is the completeness property of PTAD, and it is the basis for the Verifiable Execution Stream.

​
Why it matters

A derivatives venue must match orders in batches for throughput, while attributing every state change to the specific transaction that caused it for auditability. These pull in opposite directions: batch matching is a whole-block operation, attribution is per-transaction. Existing on-chain protocols compromise one or the other. Without per-transaction attribution, downstream consumers — indexers, risk systems, autonomous agents, compliance auditors — must reconstruct causal structure through statistical inference over incomplete event logs. The existence of a large indexer industry around general-purpose chains is direct evidence of this gap. On Intention, the attribution is produced by the chain itself, cryptographically bound to the transaction that caused it, and there is nothing for an indexer to reconstruct.

​
How Intention enforces it

PTAD is realized by a four-phase attribution pipeline that propagates a transaction-index field through the entire execution path, plus a strict sorted-container discipline that keeps the output deterministic under batch matching.

​
Phase 1 — Pre-scan

Each operation is tagged with its transaction’s index in the block. The tag travels with the operation through every subsequent phase. Classification is a pure function of the transaction’s typed payload, so tagging can happen during block ingestion.

​
Phase 2 — World-state mutation

Every write to the working state records the active transaction index in a dirty tracker under last-writer-wins semantics: the final state of a key belongs to the transaction that last wrote it. The dirty tracker is not an auxiliary log — it is the working state while the block is executing.

​
Phase 3 — Batch matching

The matching engine processes operations in canonical order within each market, recording every fill, placement, and removal as a (transaction-index,event)(\text{transaction-index}, \text{event}) tuple. A fill against a resting order is attributed to the taker’s transaction — the causally correct attribution, since the taker’s arrival triggered the match.

​
Phase 4 — Finalize and distribute

The dirty tracker is flushed into per-transaction write sets. Events from pre-match, matching, and post-match sources are merged in chronological order into each transaction’s event list. System-level writes (block counters, funding updates, insurance-fund movements not attributable to any single user transaction) are routed to a distinguished system-write channel. The result is a complete per-transaction output array plus the system channel.
Every map in the dirty tracker — and every collection whose iteration order is observable in the execution output — uses sorted (B-tree) containers. Hash-randomized containers would produce different iteration orders on different validators, breaking OTD and therefore PTAD. This discipline is a consensus-safety invariant, not a performance tradeoff.

​
The Verifiable Execution Stream

The attribution pipeline produces the Verifiable Execution Stream (VES) — Intention’s user-facing, protocol-level observable. For every committed block, VES exposes:
  • The ordered transaction list.
  • The per-transaction output array with attributed writes and events.
  • The system-write channel.
  • The certified price quorum.
  • The quorum certificate — a 2f+12f+1 aggregate signature over all of the above.
VES is complete: no execution effect occurs inside Intention that is not observable on the stream. It is verifiable: each block carries the 2f+12f+1 aggregate signature that any consumer can check independently. A node with VES from genesis to the current head can reconstruct the entire chain state from scratch. The chain is the index. Third-party indexers may exist as value-added layers, but they are no longer infrastructure-critical.

​
What this enables

  • Trustless risk systems. A risk engine subscribed to VES sees every position change as it happens, attributed to the user who caused it, with cryptographic provenance. No indexer in the trust path.
  • AI-native participation on a trustworthy substrate. Autonomous agents get completeness, attribution, and verifiability — the three properties they need to act on the chain without statistical reconstruction over third-party data.
  • Regulatory-grade audit trails. Every state change is bound to an authorized transaction. Trade-record retention obligations can be satisfied by archiving VES itself rather than reconstructed traces.
  • Batch throughput without sacrificing attribution. Intention does not choose between batching and per-transaction semantics — the pipeline provides both.
PTAD depends on OTD (so the output function is deterministic) and on RNS (so all state changes from the atomic matching-risk composition land in the correct per-transaction outputs). Drop either and PTAD collapses.