Skip to main content
If you have five minutes to evaluate Intention, this page is the right place to start. It is a flyover of the protocol architecture, with links to the deeper Architecture section for each topic.

​
The three-layer stack

Intention is organized as three layers, each depending on the one below it.
  • Asset layer. The substrate on which value exists on the chain — native balances, tokenized real-world assets, derivative positions, and the collateral that backs them. The protocol does not distinguish between a crypto perpetual, a tokenized commodity, and a tokenized equity; the same execution pipeline processes all of them as long as the reference index is defined.
  • Infrastructure layer. The technical core. Two components do the heavy lifting: IntentionKernel, the deterministic state-transition kernel, and IntentionBFT, the consensus protocol. This layer is where the four guarantees live.
  • Intelligence layer. Autonomous AI agents — liquidity providers, risk engines, semantic oracles, strategy agents — that consume the chain’s execution stream directly and act at block cadence. Not part of the protocol; what the protocol enables. Intention is open by asset, AI-native by protocol: a Layer 1 blockchain for open markets, with native capabilities for AI agents built into the protocol. The four guarantees below produce a fairer venue for human traders and a substrate AI agents can actually reason about. Both audiences are first-class.

​
Two core components

IntentionKernel

A deterministic state-transition kernel — not a general-purpose VM. Its instruction set is the enumerated set of typed financial primitives: order placement, cancel, match, mark, liquidate, fund, settle, transfer. Closed-world execution by design.

IntentionBFT

A HotStuff-family Byzantine-fault-tolerant consensus protocol extended with canonical sequencing commitments, in-consensus price quorums, batch availability decoupling, and stake-weighted leader reputation.

​
Four protocol-native guarantees

Each block satisfies four invariants by construction, not by best-effort enforcement at the application layer.
  • G1 — Order-Time Determinism (OTD). Replaying a committed block against the same pre-state produces byte-identical post-state, events, and per-transaction outputs on every honest node. Enforced by sorted-container discipline, fixed-point arithmetic, and a Differential Test Harness that treats divergence as a consensus bug.
  • G2 — Price-Transaction Atomicity (PTA). The price used to settle a transaction was signed by the same 2f+12f+1 stake-weighted quorum, in the same BFT round, that committed the transaction. Mark prices live inside consensus, not on a separate cycle.
  • G3 — Risk-Native Semantics (RNS). Liquidation, insurance fund accounting, auto-deleveraging, and funding settlement are protocol state machines. They execute atomically with matching, in the same block, under the same prices.
  • G4 — Per-Transaction Attribution (PTAD). Every state change and every event is cryptographically bound to the specific user transaction that caused it — even when matching is performed in batches. The user-facing form is the Verifiable Execution Stream (VES).
These four are coupled. PTA depends on OTD; RNS depends on PTA; PTAD depends on OTD and RNS. They are designed and enforced together because dropping any one cascades into losing at least one other.

​
Why a specialized substrate

A general-purpose smart-contract chain cannot make protocol-level claims about order-book semantics because such claims would not generalize to other applications. On those chains, matching priority is at the mercy of block-producer reordering, mark prices live on a cycle separate from execution, liquidations are keeper races, and attribution is reconstructible only via third-party indexers. Intention compiles matching, risk, clearing, and oracle integration into the native execution semantics of the kernel. New financial primitives arrive through protocol upgrades rather than independent contract deployments — a deliberate tradeoff that prefers a small, stable instruction set to fragmented application contracts.

​
Operational surface

For the operational view — validator roles, batch dissemination, RPC endpoints, and client access patterns — see Network Topology. For the price feed in particular, see Oracle. For cross-chain movement, see Bridge.

​
Where to go deeper

If you want to understand what Intention guarantees, read OTD, PTA, RNS, and PTAD in order. If you want to understand how the protocol enforces them, read IntentionKernel and IntentionBFT.