Definition
Let and be two honest nodes starting from identical pre-state , executing the same committed block whose quorum certificate is valid. Let the execution result on each node be — the post-state, the ordered event stream, and the per-transaction output array. OTD requires:Why it matters
OTD is the protocol-level enforcement of price-time priority — the rule that has organized order-book markets for more than two centuries. On a general-purpose chain, price-time priority is an application-layer promise subject to block-producer reordering. A trader cannot independently verify, from the chain’s own data, that their order was matched in the position their arrival time should have given them. Under OTD, an observer that knows the pre-state and the committed block can independently reconstruct the exact sequence of fills, events, and state changes, byte for byte. The observer does not need to trust anyone — not the validators, not the indexer, not the exchange operator. Matching priority stops being a claim and becomes a property. OTD is also the base property that makes the other guarantees coherent. PTA requires an unambiguous “the transaction that consults the price” — which is only well-defined if the transaction order is itself unambiguous. PTAD requires the per-transaction output array to be a pure function of input — which is only true if execution is deterministic.How Intention enforces it
OTD is a joint property of consensus and execution. At the consensus layer, the Canonical Sequencing Commitment promotes the transaction order within a block to a first-class consensus-committed object. The block hash covers the ordered payload after batch resolution, so any reordering after consensus would invalidate the existing signatures. stake-weighted signatures on the block already constitute a commitment to the specific ordering. At the execution layer, IntentionKernel runs transactions sequentially over the canonical order and enforces a strict byte-determinism discipline:- No hash-randomized iteration. Sorted (B-tree) containers are used in place of hash containers throughout the execution path, even where the latter would be faster for per-key operations. Hash-randomized iteration would produce different output orderings on different validators.
- No floating-point arithmetic. Floating-point may differ across CPU architectures, compilers, and rounding-mode defaults. All quantities are fixed-point integers in protocol-defined scales.
- No system-time reads. The only time reference used by execution is the block timestamp, which is itself a consensus-committed field.
- No runtime entropy. No calls to random-number generators in the execution path. Any randomness required by the protocol is computed deterministically from chain state.
- Canonical serialization. A strictly defined format with no optional fields, no implementation-defined ordering, and no variable-length padding.
What this enables
- Independent verification of matching priority. Anyone with the pre-state and the committed block can reproduce the exact fills. No indexer is in the trust path.
- Consensus without re-execution ambiguity. Validators agree on state roots because they agree on every byte of the state, not because they agree on an equivalent serialization.
- A base for the other guarantees. PTA binds a specific price to a specific ordered transaction list. PTAD produces a per-transaction output array that is a pure function of . Both require OTD to hold.
- Block-granularity price-time priority. Since “time” inside a block is the canonical intra-block position committed by consensus, no sub-millisecond colocation advantage applies within a block. Combined with the priority schedule that runs cancellations before aggressive placements, this is a structural defense against same-block sniping.
OTD is strictly a property of execution against a finalized block. It does not constrain which transactions enter a block — that is the domain of leader discretion, mitigated separately by reputation and venue-diversity requirements in IntentionBFT.