AI / Web3Architecture record

Autonomous Agent Commerce Rail

If agents are going to buy services from each other, three things have to exist that mostly do not: a way for an agent to prove which agent it is, a way for its owner to cap what it can spend, and a way to prove afterwards that a specific call was paid for. This project builds all three as a working rail. Agents hold their own keys, operate under an allowance their principal sets, and every paid call produces a portable receipt that can be verified without trusting either party.

150
TypeScript files
demo + rail
Per call
Settlement
pay-as-you-go
2
Signature families
classical + post-quantum
Portable
Receipts
verifiable by third parties
Repository shape

Demo application with agent identity, payment rail, allowance policy and a visual walkthrough

How this is presented

Documented as an architecture record. The demonstration needs funded accounts and a running chain connection, so the mechanism is what is published.

One paid API call between two agents

Follow a single request. Every step exists to remove a reason the two agents would otherwise have to trust each other.

PrincipalExternal

The human or organisation that funds an agent and sets its limits.

ExternalClient surfaceServiceOn-chainData store
A paid API call

Identity, authorisation, payment and proof.

Highlights

Agents hold their own cryptographic identity rather than borrowing a human's credentials.
Spending allowance enforced by policy, so a compromised or looping agent has a bounded blast radius.
Every paid call produces a portable receipt verifiable without trusting either counterparty.
Per-call settlement on a low-fee chain, making micro-transactions between agents practical.
Post-quantum signature support alongside classical signing.
The flow is visualised in the interface, so the mechanism is legible rather than implied.

Identity, allowance, payment, receipt

Four pieces, each solving one thing an agent economy needs. The design goal is that no party has to trust another: identity is proven, spending is bounded, and payment is provable after the fact.

Agent identity

Gives each agent a keypair it controls and can prove ownership of.

  • Derived hierarchically so a principal can issue agents deterministically.
  • Classical and post-quantum signing behind the same interface.

Allowance policy

Caps what an agent may spend on its principal's behalf.

  • Delegation is a budget, not blanket authority.
  • Bounds the damage from a misbehaving or looping agent.

Payment rail

Executes per-call settlement between agents.

  • Token transfers on a low-fee chain make per-request payment viable.
  • Settlement is tied to the specific call it pays for.

Receipts

Produces portable evidence that a call was made and paid for.

  • Verifiable by a third party without trusting either side.
  • Turns a payment into a durable, referenceable fact.

Demonstration structure

Small on purpose: the value is in the four primitives an agent economy needs, not in surface area. 12 units across 4 groups.

Application

3
applibmiddleware

Primitives

4
agent identityallowance policypayment railreceipts

Chain

2
Solana programsSPL token transfers

Cryptography

3
Ed25519post-quantum signinghierarchical derivation

Stack by layer

Agent identity
Ed25519 keypairsPost-quantum signingHierarchical derivation
Payment rail
Solana programsSPL token transfersPer-call settlement
Policy
Spending allowancePrincipal delegationReceipt generation
Surface
Next.js demo interfaceLocal SQLite stateFlow visualisation

Delivered work

Agent economy primitives

  • Cryptographic agent identity with hierarchical derivation.
  • Allowance policy enforcing principal-set spending caps.
  • Per-call settlement on a low-fee chain.
  • Portable, third-party-verifiable receipts.

Demonstration

  • Next.js interface visualising the full call-and-pay flow.
  • Local state persistence for reproducible runs.
  • Post-quantum signing available alongside classical keys.

Modules and demo strategy

Agent identity

Lets agents prove who they are without borrowed credentials.

  • Own keypair per agent, derived from the principal.

Allowance enforcement

Bounds autonomous spending.

  • Turns a runaway loop into a rejected request instead of a large bill.

Receipts

Makes payment provable after the fact.

  • Verifiable without trusting either counterparty.

Frontend documentation format

How this project is presented

The mechanism explained as a flow rather than run live.
Requires funded accounts and a chain connection to demonstrate.
Verified file counts.