Skip to main content
IntentionKernel replaces the general-purpose VM model with a closed-world execution environment. Its instruction set is the enumerated set of typed financial operations required to run a derivatives venue. The protocol knows the meaning of every transaction and can make protocol-level claims about its effect — the precondition for the four guarantees.

​
Why not a general-purpose VM

General-purpose VMs exist to make unknown programs safe to run over shared state. That leads to bytecode verification, reentrancy protection, and conflict detection under parallel execution — mechanisms necessary for open composition but which introduce non-determinism and attack surface. More importantly, a general-purpose VM makes every transaction an opaque state transition from the protocol’s perspective. The protocol can say “this transaction’s signature is valid and it did not abort.” It cannot say “this transaction was a cancel of order 42 at price-time priority 17.” For financial infrastructure, the protocol must know.

​
The closed instruction set

IntentionKernel’s instruction set is a small, stable enumeration. Everything a user or validator can do is one of:
  • Order operations. Placement, cancellation, and replacement of limit, market, and conditional orders. Time-in-force variants (GTC, GTD, IOC, FOK, post-only, AON), the reduce-only flag, and stop-loss / take-profit triggers are enumerated at the protocol level.
  • User configuration. Subaccount creation, leverage adjustment, position-mode selection (cross/isolated; net/hedged).
  • Administrative configuration. New-market listing, fee schedule updates, risk-tier definitions — authorized by governance.
  • Transfers. Internal subaccount transfers, account-to-account transfers, cross-chain deposits and withdrawals.
  • Agent authorization. Approval and revocation of scoped delegate permissions.
  • Vault operations. Creation, deposits, withdrawals, and configuration of pooled-liquidity vaults.
  • Validator-emitted operations. Price quorum submissions and reconfiguration transactions.
A transaction whose payload is not a recognized member of this set is rejected at validation. The set changes only by protocol upgrade.
The closed-world model has three consequences: the complete system behavior is a finite union of per-instruction transition functions (enumerable for audit), every operation has fixed cost (no dynamic fee market required), and classification from transaction to execution path is a pure function of the typed payload.

​
Deterministic priority scheduling

Within each block, IntentionKernel processes transactions in a protocol-defined priority order:
  1. System and consensus operations
  2. Administrative configuration
  3. Deposits
  4. User configuration
  5. Post-only passive orders
  6. Transfers
  7. Cancellations
  8. Aggressive order placements that may take liquidity
This is not a fee market or a gas auction. It is a fixed schedule independent of fees paid, bids, or any user-controllable signal. One consequence: cancellations execute before aggressive placements in the same block, so a maker’s stale quote cannot be sniped by an aggressive order landing in the same block — a structural defense that behaves like a frequent batch auction with price-time tiebreaking inside each batch.
“Time” in Intention’s price-time priority is the canonical intra-block position committed by consensus, not wall-clock time. Within a block, no sub-millisecond colocation advantage matters — every transaction in a block shares the same canonical “time.”

​
State object categories

The kernel’s global state is five categories of protocol-maintained objects:
  • Accounts and subaccounts — isolated risk and balance containers with position-mode settings, fee tiers, balances, positions, and per-instrument leverage. All fields are fixed-point integers; no floating-point arithmetic appears on the execution path.
  • Positions — per-instrument long and short exposure, separate IM and MM quotas, a funding-accumulator snapshot, and bankruptcy prices.
  • Order books — two sorted maps per market (bid and ask), keyed by integer subtick units, with FIFO chains of resting orders at each level.
  • Price quorums — the most recently certified price vector, with the round and epoch of certification and the aggregate signature proving 2f+12f+1 stake-weighted endorsement.
  • System parameters — market configurations, fee schedules, risk parameters, insurance fund state, validator set, and upgrade-signaling state.

​
The atomic execution context

The most consequential property of IntentionKernel is that matching, risk, clearing, and oracle reads execute within a single atomic context. A market order does not run through three contracts. It runs as one subsystem call sequence inside one execution step: match against the book, update taker and maker positions, check margin, run liquidation if undermargined, cascade through the insurance fund and ADL if needed — all seeing the same intermediate state, all committing or aborting as one unit of the state transition function. This atomic composition is the concrete form of Risk-Native Semantics. Intermediate states produced during matching — such as the order-book state between one fill and the next — are visible to risk logic running in the same context but are not externally observable except through the attribution pipeline. That confinement eliminates the class of MEV that would otherwise arise from externally visible intermediate state.

​
Upgrades

Adding a new operation type is a protocol upgrade, not a contract deployment. Protocol upgrades require supermajority governance, a signaling period, and coordinated validator software updates. Parameter updates (fee schedules, risk tiers, new markets under existing types) require only simple-majority governance and take effect at the next epoch boundary. Intention expects protocol upgrades to be rare: the set of financial primitives required to run a derivatives venue is small and stable.