How It Works

This page explains Warrant in plain language. No deep crypto required.

The four steps

Step 1 — Owner creates a mandate

The owner (user or admin) defines rules and signs them:

Max amount per action
Allowed wallet addresses
Blocked categories
Time windows

Warrant stores the mandate and returns a mandate API key for the agent. Analogy: Signing a company expense policy document.

Step 2 — Agent calls `check()` before acting

Before a transfer, order, or MCP tool runs, the agent sends the planned action to Warrant:

const decision = await warrant.check({
  agent_id: 'my_agent',
  domain: 'web3',
  action_type: 'transfer',
  value: { amount: 50, currency: 'USD' },
  counterparty: { id: '0x…', type: 'evm_address' },
});

Warrant compares the action to the mandate rules and returns:

Verdict	Meaning
ALLOW	Action is permitted under the rules
DENY	Action breaks the rules — do not proceed
ESCALATE	Needs human review (future)

Important: If verdict is DENY, your code must not run the real transfer or tool.

Step 3 — Signed receipt

Every decision gets a receipt — a JSON document signed by Warrant (Ed25519). The receipt includes:

receipt_id — unique id (e.g. rcpt_dec_…)
verdict and reasons
signature — proves Warrant issued it

Share this receipt with auditors or attach it to your own logs. Note: verdict=DENY means the business rule blocked the action. That is normal. A valid DENY receipt is still cryptographically authentic.

Step 4 — On-chain batch (optional but recommended)

Individual receipts are not one transaction each. Warrant batches them:

Builds a Merkle tree of receipt hashes
Publishes the root to ReceiptLog on-chain
Adds proof, batchId, and txHash to the receipt

Auditors can then prove a receipt was included in a published batch. Mandate hashes are also registered on MandateRegistry when a mandate is created or revoked.

Who does what

Role	Action
Owner	Creates mandate, signs rules
Your backend	Creates mandate via application API key
Agent / runtime	Calls `check()` with mandate API key
Auditor	Verifies receipt offline — no Abstraxn account needed

Web2 and Web3 use the same engine

Same API for:

Food ordering (amount + category rules)
Crypto transfers (amount + counterparty allowlist)
Any MCP tool you wrap with check()

Only the domain and action_type change.

Verify without trusting us alone

Auditors use @abstraxn/warrant-verifier:

Paste the receipt JSON
Verify Ed25519 signature (offline)
Optionally check Merkle proof and on-chain ReceiptLog

See Verify receipts.

One-liners for your team

Product: “Rules before the agent acts, receipts after.”
Engineering: “Call check() before irreversible side effects.”
Compliance: “Every decision has a signed, verifiable receipt.”

Next steps

SDK quickstart — code your first flow
On-chain — chains and contracts
API reference — HTTP endpoints

Getting started

Build

Audit & on-chain

The four steps

Step 1 — Owner creates a mandate

Step 2 — Agent calls `check()` before acting

Step 3 — Signed receipt

Step 4 — On-chain batch (optional but recommended)

Who does what

Web2 and Web3 use the same engine

Verify without trusting us alone

One-liners for your team

Next steps

​The four steps

​Step 1 — Owner creates a mandate

​Step 2 — Agent calls check() before acting

​Step 3 — Signed receipt

​Step 4 — On-chain batch (optional but recommended)

​Who does what

​Web2 and Web3 use the same engine

​Verify without trusting us alone

​One-liners for your team

​Next steps

The four steps

Step 1 — Owner creates a mandate

Step 2 — Agent calls `check()` before acting

Step 3 — Signed receipt

Step 4 — On-chain batch (optional but recommended)

Who does what

Web2 and Web3 use the same engine

Verify without trusting us alone

One-liners for your team

Next steps