The Arbiter

The Arbiter is Nava’s verification engine. Before any AI-generated transaction executes on-chain, the Arbiter checks it for correctness, safety, and alignment with what the user actually asked for. It outputs a clear ACCEPT or REJECT decision along with a full audit trail.

Why It Exists

Effective AI agents must be creative and adaptive. A trading agent that rigidly follows a fixed strategy cannot respond to changing market conditions, novel protocol features, or unexpected execution environments. But creativity and verifiability are in tension: the more creative an agent’s behavior, the harder it is to verify whether that behavior aligns with the operator’s intent. The Arbiter resolves this by accommodating creative agent behavior while maintaining provable alignment with user intent.

How It Works

The Arbiter uses a two-tier verification approach:

1. HARD checks (deterministic): fast, rule-based validations that run in milliseconds. These cover things like amount matching, token address verification, ABI encoding, gas limits, and sanctions screening. They are predictable and repeatable.
2. SEMANTIC checks (LLM-powered): deeper reasoning that evaluates whether the transaction holistically matches the user’s intent, detects manipulation attempts in prompts, and catches subtle misalignments that deterministic rules cannot.

Both tiers run together as part of a single validation pass. HARD checks execute first, followed by SEMANTIC checks. If any critical check fails, the transaction is rejected immediately.

The Execution Escrow Lifecycle

Every transaction flows through three phases:

Phase	What Happens
1. AGENT.PROPOSE	The AI agent builds a transaction from user intent and submits it to escrow with a reasoning trace.
2. ARBITER.VERIFY	Deterministic checks run first, then LLM semantic checks. The output is ACCEPT or REJECT with failure localization and explanation.
3. ESCROW.EXECUTE	If enough verification services approve, the escrow contract executes. Users configure which services are required and what quorum is needed.

All of this happens over NavaChain, producing an immutable record of every proposal, verification request, and response.

Verification Graph

The checks are organized as a directed acyclic graph (DAG). Each node represents a specific check, and edges represent dependencies. Independent checks run in parallel while dependent checks run in sequence.

The current graph contains 18 HARD nodes and 5 SEMANTIC nodes, grouped into four families.

Node Families

Intent Alignment (8 HARD + 2 SEMANTIC)

Verifies that the transaction matches what the user asked for. HARD checks cover operation type matching, token address verification (including ETH/WETH equivalence), decimal-aware amount validation, fee alignment, deadline consistency, slippage bounds, multi-step ordering, and approval prerequisites. SEMANTIC checks use LLM reasoning for holistic element matching and requirement compliance.

Legal Compliance (3 HARD)

Ensures the transaction is legally permissible. Includes sanctions screening against prohibited entity databases, token legitimacy verification against multi-list registries, and threshold compliance for regulatory reporting limits. Sanctions and token legitimacy failures cause immediate rejection.

Technical Invariants (6 HARD)

Confirms the transaction is well-formed. Covers ABI encoding validation, token address resolution, decimal scaling verification, gas limit checks with operation-specific ranges, protocol compatibility, and protocol-specific structural validation (CoW order structure, Compound amount magnitude, and similar).

Adversarial Detection (2 HARD + 3 SEMANTIC)

Detects exploitation attempts. HARD checks identify MEV-vulnerable parameters. SEMANTIC checks catch MEV-seeking language in prompts, analyze parameter manipulation, and verify cross-field consistency.

Supported Protocols

Each protocol has its own tailored validation graph:

Protocol	Total Nodes	HARD	SEMANTIC	Notes
Compound V2	19	14	5	Gas checks, amount magnitude guard, threshold compliance
Uniswap V3	17	13	4	Universal Router calldata decoding
CoW Protocol	20	16	4	Order structure, settlement contract, zero-amount guard
ERC-20 Transfer	~8	~8	0	Minimal graph covering format, sanctions, token legitimacy, gas, and MEV

Each protocol has a dedicated Prompter class containing its own validation logic.

The Arbiter generates protocol-specific verification graphs tailored to each protocol’s mechanics without requiring cooperation from the protocol itself. The protocol’s smart contracts are unaware that verification occurred. Hyperliquid and Polymarket support are currently in development. A DPO-trained graph composer model (QWen2.5-7B) is being deployed to enable dynamic graph generation for new protocols at runtime, eliminating the need for per-protocol engineering.