Relnet

A governed settlement network where AI agents negotiate and run long-term supplier deals, and people sign on-chain, and contracts enforce the terms.

Comment

Inspiration

A supply deal is signed once and then runs for years: price changes, orders, late shipments, payments. Today people run it by hand, with POs, invoices and bank transfers, and neither side can see the other's rules. I wanted to see how far AI agents could take over that work without anyone having to trust them, or me, or the other company's software.

What it does

relnet is a governed settlement network for long-term supplier and buyer relationships.

  • Agents negotiate. Each company's agent trades signed offers over the open A2A protocol. Terms use a typed vocabulary of 12 integer fields, and money is integer cents. No model output can set a price, a limit or a key.
  • People sign. A person at each company approves the deal on-chain. Agents can propose but never sign.
  • Contracts enforce. Escrow, the late-price rule and order checks live in Aztec contracts, so neither side depends on a server I run. The supplier can prove its on-time rate meets a threshold without revealing individual orders (zero-knowledge, Noir).
  • Payments settle on-chain instead of through a bank. In this prototype the funding step is a simulation.
  • You can check what you run. Releases are deterministic tarballs with a published checksum list and a GitHub build attestation. A verify command checks the hash, the attestation and the contract class ids. Invite and join commands pin each agent's key from a fingerprint that people confirm over a different channel.

Everything uses fictional companies (Lone Star as the buyer, Trinity as the supplier, and a deliberately sloppy "Bargain Bolts" supplier) on a local test network with no real funds.

Why Aztec, and not a plain public chain

A supply deal has two kinds of data. Some of it should be public, and some should not.

  • Public on purpose: the agreed terms, the escrow balance and the order history. Both sides and any auditor can check them, so neither company has to trust the other's records.
  • Private by need: a supplier's performance history. A buyer who learns the exact on-time rate on every order gets bargaining power the supplier never agreed to give.

On a plain public chain, everything is visible, so the supplier's order history would be readable by anyone. The usual workaround is to move the sensitive part off-chain, which brings back a server someone has to run and everyone has to trust. The other option is to build zero-knowledge circuits and a proving pipeline yourself.

Aztec gives me both halves in one contract system:

  • Private state and proofs are built in. In relnet, the supplier proves that its on-time rate meets a threshold without revealing individual orders. That is a Noir circuit run by the supplier's own wallet, and the agreement contract checks the result.
  • Private functions run on the user's machine. The sensitive computation happens on the supplier's side rather than on a host I operate, which matches the goal that nobody has to host anything: the work runs on-chain or on the users' own machines.
  • One toolchain for public and private logic. The same Noir contracts hold the public escrow rules (late-price rule, order checks) and the private performance proof.

What I did not do: I didn't build a Solidity version to compare, and I measured no cost or speed difference. Fees on the local test network are sponsored, so they prove nothing about real cost. This is a design reason, not a measured result. Aztec is also young, and I've only run this on a local network.

How I built it

I built it solo, using TypeScript and Node 24, Noir contracts on Aztec 5.2.1, and A2A v1.0.0 for the agent channel. The agent channel uses Ed25519 keys and signed offers bound to one deal, sender, recipient and round. Releases are built and attested by a GitHub Actions workflow. I wrote 79 automated tests across ten suites, including 13 hostile-agent cases and a test that checks the real on-chain contract against the release.

Challenges

  • Hostile agents. I ran 20 prompt-injection attacks and two bad-faith negotiation duels against real models. None got an approval, a shipment confirmation or a hidden limit out. The loosely written supplier did give ground on price ($4.50 to $3.90), but only inside its own limits. The lesson is that the guard enforces the approved limits, so those limits have to be tight.
  • What a contract class id proves. I tested it and found that some edits to the compiled artifacts don't change it, so the release also checks every file's hash.
  • A trustworthy install. I tested a clean-machine install from the README in a bare container, then ran the live negotiation on a separate Intel Mac.

What I learned

The strongest trust boundary is small: two human signatures on-chain and a contract that rejects anything outside the signed terms. The agents, the channel and the release host can all be untrusted.

Limits (honest list)

Not audited, and no compliance claim. No fee saving is measured, and the funding step is simulated. Both companies share one local test network and the agent channel is plain HTTP with no TLS. Shipment confirmations are plain calls, not signed attestations. The audit-log contract is a stub. Only I have run it so far.

What's next

A second company running it on its own machine, a public network, signed shipment attestations, and a shadow-mode pilot beside an existing PO process.

Built With

Share this project:

Updates

Submission history