Build AI agents that can handle real capital

An independent verdict on every action, with the audit trail to take agents from sandbox to production.

You're on the waitlist
How It Works
1

Agent proposes

Code inputTypescript
await nava.verify({
action: 'Swap 5,000 USDC for ETH on Uniswap',
policy: 'treasury',
tx: {
protocol: 'uniswap',
function: 'exactInputSingle',
amountIn: '5000 USDC',
amountOutMin: '1.47 ETH',
}
});

Any framework, any model. Your agent reasons, plans, and proposes an action without constraints.

2

Guardian verifies

Terminal outputJSON
{
"reasonCode": "allowed",
"policy": "treasury",
"checks": [
{ "checkId": "venue", "status": "passed" },
{ "checkId": "chain", "status": "passed" },
{ "checkId": "asset", "status": "passed" },
{ "checkId": "recipient", "status": "passed" },
{ "checkId": "slippage_guard", "status": "passed" },
{ "checkId": "sanctions", "status": "passed" }
]
}

The Guardian independently checks the proposal against your policy and returns a verdict.

3

You execute

Agent
Auto-execute
Swap 5,000 USDC for ETH
Approved

Executed automatically · tx 0x8f3a…c291

Send 2,000 USDC to 0x91b4…7c2a
Rejected

recipient_not_allowed — not in your allowlist

Buy 3 ETH at market
Approved

Executed automatically · tx 0x2d7c…af90

Swap 800 USDC on SushiSwap
Rejected

venue_not_allowed — SushiSwap not in policy

On an approved verdict, execution proceeds through your own settlement path. Nava returns the verdict; you keep control of execution.

4

Auditable operations

Terminal outputJSON
Transaction #4,291
Action: "Swap 5,000 USDC to ETH"
Policy: treasury
venue passed
chain passed
asset passed
recipient FAILED recipient_not_allowed
slippage_guard passed
sanctions passed
REJECTED (recipient_not_allowed)
→ Agent re-proposed to an allowlisted recipient
Re-check: allowed
APPROVED tx: 0x8f3a...c291

Every verdict comes with the reason behind it, down to which check failed and why. Auditable by compliance, verifiable by users.

Product Stack

Nava Guardian

An independent verdict on every action your agent proposes.

  • Deterministic checks per action: venue, chain, asset, recipient, sanctions, slippage guard
  • Returns an allow/deny verdict with the reason code behind it
  • Framework-agnostic. Drop into any agent stack
Terminal outputJSON
{
"reasonCode": "allowed",
"policy": "treasury",
"checks": [
{ "checkId": "venue", "status": "passed" },
{ "checkId": "chain", "status": "passed" },
{ "checkId": "asset", "status": "passed" },
{ "checkId": "recipient", "status": "passed" },
{ "checkId": "slippage_guard", "status": "passed" },
{ "checkId": "sanctions", "status": "passed" }
]
}

Nava Gateway

One endpoint for agent payments and escrow requests.

  • Route any agent payment or escrow request through one endpoint
  • Policy-checked against your rules before settlement
  • Value only moves when it meets your policy
Terminal outputJSON
{
"x402Version": 1,
"scheme": "exact",
"network": "base",
"payload": {
"authorization": {
"from": "0x9a8f...4b21",
"to": "0x3fC9...7FAD",
"value": "5000000000",
"validAfter": 1751289600,
"validBefore": 1751293200,
"nonce": "0x7c3e...af90"
},
"signature": "0x4b2c...a803"
}
}
Why Nava

From sandbox to production

Your agents get smarter as the network grows:

Error patterns discovered by any agent help protect all agents

Coverage broadens as new policies join the network

Built-in audit trail for your peace of mind

before

Agents stuck in sandbox environments

Manual oversight required for every trade

No deployment confidence without liability risk

Weeks of defensive coding and testing

after nava

Agents handling real capital in production

Ship financial agents with an independent verification layer

Built-in verification flags policy violations on every action

Audit trails for accountability

Start Building

Devs and traders

Drop verification into any agent you're building.

You're on the waitlist
Devs and traders

Institutions

Enterprise-grade verification for Agentic Finance.

Devs and traders