AURA Protocol v3.0

One contract, discovery to a provisioned sandbox

Two agents that both have a stake in the price cannot safely tell each other the truth, so a neutral party holds both sides and resolves the trade. That party is Core, and its whole surface is one transport: REST over /v1/*, each request signed with an Ed25519 key. An agent walks the admission chain from discovery to a seeded market, and no human stands in the loop.

Walk the ten phases Four requests to a seeded market Open the contract
The admission journey

Discovery to a provisioned sandbox, one chain

Every phase names its purpose and the operations that carry it. The first six are live on the bench: an agent walks them end to end today. The last four are the certification track, declared in the contract and on the roadmap. This is the same chain the machine reads at /v1/admission, told for people.

1

Discover

Live

Find the protocol and its machine-readable surfaces. Every other phase resolves from the contract.

GET /openapi.jsonGET /llms.txt
2

Learn

Live

Read the law the market upholds: the invariants every conforming actor is held to.

x-aura-invariants
3

Request identity

Live

The agent registers a principal anchor, then an agent record bound to its Ed25519 public key. Identity exists before any scoped call.

POST /v1/principalsPOST /v1/agents/registerPOST /v1/beacons/register
4

Prove key control

Live

Sign every request with the private key. Possession is proven on the wire, never asserted.

X-Signature · Ed25519
5

Obtain scope

Live

Mint a scoped sandbox key. Two proofs resolve in order: signature possession over the exact JSON body, then domain control. The key is the tenant anchor for one namespace.

POST /v1/sandbox/keys
6

Provision sandbox

Live

The Dev Centre provisions an isolated, seeded, deterministic market for the key: house counterparties, ready to transact. Provisioning is an operational action at the Dev Centre, not a Core protocol operation. Re-provision at any time; idle namespaces are reclaimed automatically.

POST https://agentcentre.aura-labs.ai/provision
7

Execute validation flows

Roadmap

Exercise the golden and failure paths against seeded counterparties. The operations resolve today; the guided orchestration is on the roadmap.

You record your own rehearsal. Each party records its own plane, and the platform keeps no authoritative rehearsal record for you, so the flow_transcripts you present at conformance are yours to capture and retain. The bench does keep its own operational trail of a run and can serve it back, but that trail is Core's plane, is bound to the namespace lifetime, and is not your evidence. Record the protocol events you drive, which you observe in your own request and response traffic, and keep a durable copy. They are assessed against your role profile, scout-admission or beacon-admission.

POST /v1/sessionsPOST /v1/sessions/{session_id}/offersPOST /v1/sessions/{session_id}/commitGET /v1/transactions/{transaction_id}/clearing
8

Run conformance

Roadmap

The harness runs your role profile's assertions against the flow transcripts.

conformance harness
9

Receive certification

Roadmap

Core signs the assertion results as presentable, expiring evidence.

signed certification
10

Request production promotion

Roadmap

Present certification and request promotion, gated on the entity verification level the target tier requires.

production promotion
An agent reads this same chain, phase by phase with a next link at each step, from the bench: GET https://sandbox.aura-labs.ai/v1/admission
Get a test account

Four requests to a seeded market

Four signed requests resolve into a provisioned sandbox, and no human sits between them. They are the live phases three, five, and six of the chain above, run against the bench at https://sandbox.aura-labs.ai.

1

Register a principal

Your identity anchor in the protocol. Returns a principal record.

POST /v1/principals

2

Register your agent

Bind your Ed25519 public key to an agent record. From here every request is signed.

POST /v1/agents/register

3

Mint a sandbox key

Two proofs, in order: an X-Signature over the exact JSON body (possession), then domain control by DNS TXT or a well-known document. Returns a scoped, prefixed ak_sandbox_ key, the tenant anchor for one namespace.

POST /v1/sandbox/keys

4

Provision your namespace

Send the key to the Dev Centre. It provisions an isolated, deterministic market: house counterparties, ready to transact. Provisioning is an operational action at the Dev Centre, not a Core protocol operation. Re-provision any time; idle namespaces are reclaimed automatically.

POST https://agentcentre.aura-labs.ai/provision

Reputation-graduated access

Limits scale with proven identity

Every count keys on your verified domain, so the price of abuse is fresh identities rather than fresh compute. Domain verification puts every minted key at T1 today. The higher tiers are declared in the contract and unlock as their verification vocabulary lands.

T0

Anonymous floor

Defined, not reachable: minting a key requires domain proof.

  • Provisions / day1
  • Active namespaces1
  • Idle TTL2h
  • Requests / min30
  • Conformance / day2
Defined
T1

Domain-verified

Prove control of a domain. Every minted key holds this tier today.

  • Provisions / day3
  • Active namespaces1
  • Idle TTL72h
  • Requests / min120
  • Conformance / day10
Live
T2

Entity-verified

A verified legal entity. Declared, inert until the verification vocabulary lands.

  • Provisions / day10
  • Active namespaces3
  • Idle TTL168h
  • Requests / min300
  • Conformance / day50
Declared
T3

Certified

A passing conformance certification. Declared, inert.

  • Provisions / day25
  • Active namespaces10
  • Idle TTL336h
  • Requests / min600
  • Conformance / day200
Declared

One ceiling is tier-independent: a 500-namespace global cap is enforced across the shared bench regardless of tier. Idle namespaces are reclaimed at their tier's TTL, so a slot an agent walks away from is returned rather than held.

Machine-readable protocol

For agents

Every surface below is public, ungated, and machine-first. The admission guide walks the chain link by link, and the contract, the human reference, and the law all resolve from it. An agent reads the same admission chain a person does, served at /v1/admission with a next link at each phase.

/v1/admission

The admission chain, served on the bench. Every phase, its operations, its status, and the next link. The HATEOAS guide an agent follows from discovery to a provisioned sandbox.

openapi.json

The canonical contract. Every operation, request body, response body, and invariant, machine-readable.

reference.html

The human-readable API reference, rendered directly from openapi.json.

invariants.html

The protocol law: the rules every conforming market upholds.

llms.txt

Agent discovery: the map of the protocol surfaces, one link per line.

llms-full.txt

The complete protocol in one document: every layer, operation, and data shape.

/api/mcp

Connect an MCP client to search and call the protocol. Four tools: search_operations, get_operation, list_invariants, execute_operation.

Quickstart

A Scout is an autonomous agent acting for a buyer; a Beacon acts for a seller. Each wraps the same signed /v1/* operations. Get one running in about 15 minutes.

For Buyer Applications

Scout Framework

Integrate buying agent capabilities into shopping apps, procurement portals, or any system where users search for products.

# Install the Scout SDK
npm install @aura-labs-ai/scout

# Configure with your API key
export AURA_API_KEY=your_api_key

# Run the example Scout
npm run example

✓ Scout connected to AURA Core
✓ Ready to register intent
Scout Operations →
For Seller Applications

Beacon Framework

Add selling agent capabilities to e-commerce backends, ERP systems, or any platform that manages inventory and pricing.

# Install the Beacon SDK
npm install @aura-labs-ai/beacon

# Run your beacon
node my-beacon.js

✓ Beacon registered with AURA Core
✓ Polling for buyer sessions...
Beacon Operations →

SDKs & Libraries

Every SDK wraps the same signed /v1/* operations, generated from the contract. Keys and portal access are in the Developer Portal.

JS

JavaScript / Node.js

Official

Wraps the Scout and Beacon operations for Node.js and modern browsers, generated from the contract.

Access in Portal →
PY

Python

Official

Wraps the same operations server-side, typed from the contract schemas.

Access in Portal →
TS

TypeScript Types

Official

The request and response types for every operation, emitted from openapi.json.

Access in Portal →
v1

REST API

Any Language

The protocol itself. One transport: REST over /v1/*, signed with the Ed25519 X-Agent-Id, X-Agent-Timestamp, and X-Agent-Signature headers.

API Reference →

Documentation

The protocol is public and ungated. The API reference, the invariants, and the canonical contract are below. SDK guides and API keys are in the Developer Portal.

📡

API Reference

Every operation in the AURA Protocol v3.0, rendered from the canonical contract.
⚖️

Protocol Invariants

The rules that hold in every conforming market. The law the protocol is built on.
📋

OpenAPI Contract

The canonical, machine-readable protocol specification. One file, the source of truth.
🚀

Protocol Walkthrough

A guided pass through the full lifecycle: intent, commitment, clearing, and settlement.
🏗️

Architecture Overview

Understand the three-layer system: Scout, AURA Core, and Beacon.
🔍

Protocol in Action

A live demonstration of a Scout and a Beacon transacting through AURA Core.
🎞️

A Recorded Run, Replayed

A real agent onboarded itself through its local MCP. Replay the recorded transcript; the hash chain recomputes in your browser.

Resources

Example Projects

Working implementations and demos

Protocol Walkthrough

The full lifecycle, end to end

Invariants

The rules of a conforming market

OpenAPI Contract

The canonical machine-readable spec