What we built, and what we brought.

• NuntioAccount.sol

  The account that holds the funds and decides every payment. Allowance, per payment cap, frequency limit, expiry, pause, and a merchant allowlist held separately for each spender. There is no address parameter on the paying function at all, so naming a recipient is not something a spender can express.

  • packages/contracts/src/NuntioAccount.sol
  • 1,064 lines
  • 185 tests

• ApprovalQueue.sol

  Where a refused payment goes to ask a human. It is a separate transaction because a revert rolls back its own writes, so blocking a payment and recording that somebody asked for it cannot happen in the same call. Only the owner may agree to a request, and a request is accepted only from the spender it names.

  • packages/contracts/src/ApprovalQueue.sol
  • 800 lines
  • 108 tests

• ServiceRegistry.sol

  Merchant lookup by id. Resolution reverts on an id nobody registered, rather than returning the zero address, which is what makes an invented recipient fail at lookup instead of sending money to a hole and minting a receipt that claims delivery.

  • packages/contracts/src/ServiceRegistry.sol
  • 205 lines
  • 23 tests
  • packages/contracts/deployments/10143.json

• NuntioTeamFactory.sol

  Creates a sealed account and approval queue for a new team in one transaction, then hands ownership to whoever asked. It created the Sandbox, the account every tester joins, and anyone signed in can now create a team of their own through it, owned by their own wallet.

  • packages/contracts/src/NuntioTeamFactory.sol
  • 108 lines
  • 13 tests, plus 3 for its deploy script

• CallerProbe.sol

  A throwaway diagnostic that records what a contract observes as its caller during a real transaction. It exists so that no authorization code has to assume the answer. It is state changing rather than a view, because a read reports what a node computes and not what the chain records.

  • packages/contracts/src/CallerProbe.sol
  • 130 lines
  • 9 tests
  • docs/research/CONSTANTS.md

• The assistant

  A constrained tool caller that emits a typed payment intent and nothing else. It holds no key, builds no calldata and picks no address. The pipeline runs catalog, provider, shape, resolution and assembly in that order, and the first stage refuses a request before the model is ever called.

  • packages/agent/
  • 260 tests across 12 files

• Service resolution in the SDK

  A lookup has four outcomes: known, unknown, suspended, and unreadable. Unreadable is the one that gets deleted, and folding it into unknown would let a rate limited node report a real merchant as invented, which is the most misleading direction that failure can take.

  • packages/sdk/src/registry.ts
  • 206 lines
  • 66 tests in the package, plus 4 against the live chain

• The web application

  Onboarding, policies, spenders, approvals, activity, the assistant screen, the Sandbox and teams: creating your own, invitation links, and owner actions signed by the owner’s own wallet. It includes the held and declined states that the product exists to show. A blocked payment is drawn as a success state, because that is what it is. Payment history reads every account deployment through Envio HyperSync, and each payment shown is read back from its own onchain receipt.

  • apps/web/
  • 996 tests, plus 22 against the live chain

• Persistence

  PostgreSQL for the state a contract cannot hold: agents, jobs, payment intents, an append-only audit trail, Sandbox joins, and the teams people create with their invitations. Duplicate intents and duplicate chain events are refused by the database itself, not by application code remembering to check. Nothing here authorizes a payment; the contract still does that.

  • packages/db/
  • 4 migrations
  • 114 tests, plus 54 against a real database

• The agent worker

  The process that lets an assistant act while nobody is signed in. It records an intent before it signs and a transaction hash the moment one exists, so a crash mid-payment is recovered by reading the chain rather than by sending again. It has run live in observe mode only, recording what it would pay and signing nothing.

  • apps/worker/
  • 240 tests, plus 64 against a real database

• Agent identity

  Each agent gets its own wallet, created by Privy under a key that only the worker holds, so the web server can set an agent up and can never sign for it. The wallet’s own policy allows payments from this account and approval requests for itself, and nothing else; the contract still decides every payment. Its signing and policy code runs live for the Sandbox operator (evidence 10); no agent has been created under the worker’s key yet.

  • packages/agents/
  • 72 tests

494 Solidity tests across 15 suites and 1,748 TypeScript tests across 114 files, all passing on 1 October 2026. Each rule the contracts enforce carries a test that it holds and a test that the invalid case is rejected.

• All six registered services resolve

  Each name held on chain matches the merchant name in the application’s fixtures exactly, and each slug matches the seeding script exactly. They had drifted to no overlap at all, which would have made every payment the assistant could propose revert for a reason that has nothing to do with the assistant.

  • docs/hackathon/evidence/03-every-fixture-merchant-resolves.md
  • 6 of 6

• An id nobody registered reverts

  Asking the live registry for an invented merchant returns the selector for an unknown service followed by the 32 bytes of the id echoed back. The id the SDK decoded is identical to the one the chain returned, which is what makes the log line usable as evidence afterwards rather than only as a message.

  • docs/hackathon/evidence/01-unknown-service-reverts.md
  • 0xcab75967

• Both refusal layers fire, and which one fires is recorded

  A merchant outside the spender’s list is refused by the schema before any network call. A merchant on the list that was never registered on chain gets past the schema and is refused by the registry. They catch different mistakes, and the second one is the one that survives an error in our own data.

  • docs/hackathon/evidence/04-two-layers-refuse-a-hallucination.md