> ## Documentation Index > Fetch the complete documentation index at: https://docs.intention.xyz/llms.txt > Use this file to discover all available pages before exploring further. # Architecture at a Glance > A five-minute orientation to Intention's three-layer stack, two core components, and four protocol-native guarantees. 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](/architecture/overview) 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](/architecture/intention-kernel), the deterministic state-transition kernel, and [IntentionBFT](/architecture/intention-bft), the consensus protocol. This layer is where the four guarantees live. * **[Intelligence layer](/architecture/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 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. 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)](/architecture/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)](/architecture/pta).** The price used to settle a transaction was signed by the same $2f+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)](/architecture/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)](/architecture/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)](/resources/glossary). 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](/architecture/network). For the price feed in particular, see [Oracle](/architecture/oracle). For cross-chain movement, see [Bridge](/architecture/bridge). ## Where to go deeper If you want to understand *what* Intention guarantees, read [OTD](/architecture/otd), [PTA](/architecture/pta), [RNS](/architecture/rns), and [PTAD](/architecture/ptad) in order. If you want to understand *how* the protocol enforces them, read [IntentionKernel](/architecture/intention-kernel) and [IntentionBFT](/architecture/intention-bft).