Prototype · Hedera testnet Hosted demo retired Context: built from scratch for ETHOnline 2026, "From Scratch" track.

Quorum402

An HTTP 402 challenge that a crowd can answer together.

Quorum402 proposes a new payment scheme for x402, for resources that no single buyer can pay for alone. Payments go into a contract nobody controls. The resource is released only if enough separate buyers pay before the deadline, and if they don't, every payer can take their money back without asking anyone.

Watch the demo Code The specification

The problem

x402 turns HTTP "402 Payment Required" into a real payment handshake. As of September 2026, though, every x402 scheme describes one payer settling one request. None can express "I will pay if enough others do": many separate payers, one resource, all or nothing, and a refund when the crowd doesn't show up.

That situation is common. The demo sells a shared price benchmark that needs at least three contributors to protect their privacy. A trip might only run with twenty travellers. Group buying and all-or-nothing crowdfunding work the same way.

What we built

A proposed quorum scheme for x402. It adds a conditional payment flow and a 202 Accepted response that means "paid, resource still owed". A plain exact offer is listed next to it, so clients that don't know the new scheme can still pay.

QuorumPools, a Solidity contract on Hedera with no owner, admin, pause switch or upgrade key, holds the money. A coordinator serves the resource without keeping a database: what is for sale, and who is owed what, is worked out from the chain and its index on every request.

The Graph's hosted network doesn't index Hedera, so the project runs its own graph-node, and the index sits in the request path. An autonomous buyer agent and end-to-end tests run both outcomes against the real testnet.

How it works

  1. The seller opens a pool on-chain with the resource URL, a seat price, the number of separate buyers it needs, and a deadline.
  2. A buyer asks for the resource and gets "402 Payment Required" with the pool's terms.
  3. The buyer pays the pool contract, never the seller. A facilitator settles the payment, and the coordinator records one seat per address.
  4. While the crowd is still short, the buyer gets "202 Accepted" and a receipt. The payment that completes the crowd gets "200" and the resource.
  5. Earlier buyers redeem their receipt by signing with the account that paid. They don't need a session or an account.
  6. If the deadline passes before the pool fills, any payer can reclaim their money with their own key, or anyone can push refunds to everyone. The seller is paid only if the pool fills.

Engineering highlights

A contract nobody controls

The contract has no owner, admin, pause switch or upgrade path, so the all-or-nothing rule is enforced by the code itself. A check compares the deployed bytecode with what the source compiles to.

Nothing settles until it can be recorded

Every check runs before the irreversible payment step, so a refusal costs the buyer nothing.

No database to trust

Each buyer's entitlement is worked out again from chain state on every request, so receipts survive restarts and redeployments.

No fake crowds

Each address gets one seat, and a solvency check stops a pool reaching its threshold without real funds behind it.

Backward-compatible

The new scheme is offered next to a plain exact payment, so existing x402 clients keep working.

Both outcomes tested for real

The end-to-end tests run both the crowd that arrives and the crowd that falls one seat short, against Hedera testnet.

How it was built

Built with Claude Code, directed by one senior engineer, and disclosed in full: the repository publishes a detailed AI-usage record, as ETHGlobal's AI policy requires.

The contract was specified before its code, the scheme was specified alongside the code, and each design decision was recorded as an architecture decision record when it was made (six in all). The work went through 26 pull requests, each checked by CI: build, subgraph drift check, lint with zero warnings allowed, type-checking and the test suite.

Scheme specification The six ADRs AI-usage record Pull requests

Status, stated plainly

Prototype · Hedera testnet Hosted demo retired

A working prototype, run end to end on Hedera testnet in September 2026 and shown in the demo video. The pool contract is still deployed and can be inspected. The hosted coordinator and indexer have been shut down, so the live demo no longer answers, but everything can be run locally from the repository.

Payments are in testnet HBAR, and there is no mainnet deployment. On Hedera, attributing a payment to a pool relies on the coordinator, a trust boundary the design records openly in its second ADR.

As of .

Verify it yourself

  1. The contract is deployed See contract 0.0.10409980 on HashScan, or its mirror-node record (memo "quorum402 pool contract", created 7 September 2026).
  2. Nobody can change it Read ADR 0003, then run the README's deployment check, which reads the bytecode back from the network and checks who can change it.
  3. Both outcomes were run Verifying it end to end covers the crowd that arrives and the crowd that falls one seat short.
  4. The tests pass The latest CI run on main shows 266 passing.
  5. Watch it run The 3-minute demo shows two buyers told to wait, a third who completes the crowd, a receipt being redeemed, and a pool that never fills being refunded.

Skills demonstrated

Need this level of rigour on your idea?

Tell us about your idea. We'll tell you honestly how we would build it, and whether we're the right fit.

Start your MVP See our services