Inspiration
AI agents are starting to move money — proposing purchases, placing orders, paying invoices. The infrastructure they run on measures almost nothing about the agent itself before the money moves: a claim is made, an API is called, a payment executes.
ZeroBeacon was built on the opposite instinct, learned the hard way
in formal mathematics. In Lean, the word sorry marks a genuine gap
in a proof — but the same word appears in comments, headers, and
prose, where it means nothing. Counting sorries naively produces
confident, wrong numbers. The discipline that fixes it — ignore the
mention, find the true gap, and re-measure every count by a second,
independent method before believing it — became the design ideology
of this project: measured, not minted — proven, not asserted.
The PayPal AI Hackathon asks: what happens when AI is put behind the wheel of payments? Our answer: the agent proposes, the harness measures, and PayPal moves the money only on a measured pass.
What it does
This entry is the whole ZeroBeacon package, with the focus on its newest layer. The package has two halves behind one API key, both live at api.zerobeacon.ai:
- The toolset — 1,052 operations across 21 routers (1,003 callable over MCP): market data, a math engine, and commerce utilities from escrow to notary to delivery proof. This is the economy — the work agents do.
- The Trust Stack — the verification layer over that economy, and the centerpiece of this entry: the layer that measures agent work before money moves on it.
The harness flow, end to end. An AI agent proposes a purchase (item, amount, and the claims behind it). Before any money moves, the proposal passes through the Trust Harness:
- Apathy — audit. Every quantitative claim in the proposal is re-measured by a second, independent method. A claim that fails re-measurement stops the flow and is named.
- Proven — verify. Claimed capabilities are checked against the live system with real probes, not against documentation.
- The gate. Only a proposal that passes audit and verification may proceed to payment. On a pass, a PayPal sandbox order is created and, after buyer approval, captured. On a fail, the flow returns a named refusal — and no PayPal order is ever created.
- Anchor — certify. Work that passed is issued a signed certificate. The certificate format and its verification are public; the issuance core is sealed. The moat is issuance, not verification.
- Receipts — record. Every outcome — certificate, refusal, and the executed payment — is written to a chained, tamper-evident ledger, so the whole sequence can be replayed and verified after the fact.
Both outcomes are demoable on demand: a clean purchase that passes and executes, and a tampered agent claim the gate catches before PayPal is ever called. The caught failure is the centerpiece — agentic commerce needs a brake pedal more than another accelerator.
Collision anchoring: how a thousand tools keep their identity
A catalogue of 1,052 operations has an addressing problem most APIs never live long enough to meet: names stop working. Tool names repeat across ZeroBeacon's blocks by design, and in any registry that keeps growing, name collisions are a matter of time. So in ZeroBeacon, a tool's identity is not its name. It is its address.
For engineers. Every operation is registered at a block-anchored
address, /api/mf/{block}/{tool}. The addressing is generated from
four primes — 11, 13, 17, 19 — and the constant 1419 = 3 × 11 × 43.
A beacon function, frac(p × π/10 × 2³²), maps primes to 32-bit
values. The system is collision-anchored, not collision-proof —
and the difference is the design. Two known primes (P1 = 3000105001,
P2 = 5303687339) are intentional fixed points that produce the
canonical beacon value 1d2c7a5b; nine controlled collisions are
known in total. Because the anchor collisions are deliberate, beacon
verification is deterministic. Everything else is probabilistic,
with a stated bound: a random collision lands at roughly
(9/4M)^35 ≈ 1e-197 — practically zero, and published as a bound
rather than dressed up as a proof. (The anchoring method descends
from the Eutheos programme, a Lean 4–verified witness family; that
verification covers the witness family, not this API — the same
claim discipline as everywhere else in this project.)
In plain terms. Think of a warehouse. A warehouse does not find things by name — a thousand boxes are labelled "fragile." It finds things by coordinate: aisle, bay, shelf. The coordinate is the identity; the label is decoration. Collision anchoring is that idea for an API catalogue. Address a million agent tools the way a warehouse addresses a million parcels — by anchored coordinate, not by name — and the catalogue can grow without its contents colliding into each other. Who knows: maybe PayPal wants to build warehouses. We speak the language. And collision anchoring can be adapted to all types of industries — from autonomous vehicles to any kind of routing — and our toolset covers it.
Where this sits beside PayPal
PayPal already does several kinds of trust, and does them well. It verifies identity (KYC — who the parties are). It screens transactions (risk and fraud models score a payment as it happens). It provides recourse (buyer and seller protection, disputes, chargebacks — after something has gone wrong). And it settles: the money actually moves.
Agentic commerce opens a gap none of those cover: nobody measures the work before the money moves. An agent can present a fluent, false claim — work described as done that was never done, counts that were never counted — and every existing check passes, because the identity is real, the transaction looks ordinary, and recourse only starts after the loss. The Trust Stack is that missing upstream layer: Apathy re-measures the claim, Proven probes the live system, the gate refuses before an order exists, Anchor certifies what passed, and Receipts binds the certificate to the executed payment in one replayable chain. PayPal settles payment; the harness settles whether payment should happen.
The toolset has the same shape of gap. PayPal's developer platform hands an agent the money verbs — create an order, capture, refund, dispute: a handful of precise operations. The ZeroBeacon toolset is the workbench around those verbs: 1,052 operations an agent can actually do work with, 1,003 of them callable over MCP, the protocol agents natively speak. PayPal answers how does an agent pay? The toolset answers what can an agent do that is worth paying for — and how does it find the one right tool among a thousand? The harness verifies the result, collision anchoring keeps the workbench addressable at scale, and only then does the payment verb fire.
How we built it
The harness is a set of FastAPI modules hosted on Fly.io alongside
the ZeroBeacon platform, deliberately outside the catalogue's
routers so the toolset's counts are untouched (live-checkable at
GET /health: 1,052 tools, 21 routers). The modules speak REST and
MCP (11 trust tools). The PayPal integration uses the sandbox Orders
API v2: server-side order creation happens only after the gate
passes; capture follows the buyer's sandbox approval; the resulting
payment ID is what Receipts records. The submitted demo app is a
thin public client (Apache-2.0) that calls the hosted harness;
buyer approval happens on PayPal's own hosted checkout, via the
approval link the harness returns — everything a judge needs to
run it is in the public repository, and the hosted demo stays
live and free for the entire judging period.
Challenges we ran into
The hardest problem was honesty discipline, not plumbing: keeping
every claim the system makes about itself measured rather than
asserted. Our audit module exists because an earlier version of our
own tooling counted sorry mentions in comments as proof gaps and
reported wrong totals with total confidence. The harness now treats
its own host's claims the same way it treats an agent's — nothing is
believed until it is re-measured. A second challenge was scoping:
the certificate issuance core stays sealed by design, so the public
surface had to make verification fully possible without exposing
allocation internals.
What we learned
Trust infrastructure for agents is a measurement problem before it is a cryptography problem. Certificates are cheap; knowing what actually happened is the work. Payments turned out to be the ideal forcing function: money moving is the moment a claim becomes a fact, which is exactly where measurement belongs.
For the judges
Your ENTERPRISE key is in this submission's testing field. The
evaluation path takes about ten minutes: read the public page at
GET /trust, run the composed flow with a well-formed proposal,
re-run it with one claim altered and watch the gate refuse before
payment, then fetch and verify the receipt chain. The per-lane key
manual served by GET /api/lane-manual (your key is the selector)
walks the whole path.
Log in or sign up for Devpost to join the conversation.