GovFlow

Inspiration

Public construction money moves down a chain: a city pays a prime contractor, and the prime pays its subcontractors. That chain is a favorite target for payment-redirection fraud. Someone sends a convincing email saying "we've changed our bank details," and the next payment goes to the impostor. Cabarrus County, North Carolina lost $2.5 million this way on a school construction project, and stories like it come up again and again.

Two things bothered us. First, most payment systems trust a vendor record that anyone with access can edit. Second, contractors who are legitimate still wait weeks or months to get paid. We wanted a system where every payee is verified, every bill is checked against work that was actually accepted, any change of payout wallet freezes the money until people decide, and honest contractors get paid in minutes.

What it does

GovFlow handles a public contract from tender to payout. The agency, the prime contractor, the subcontractor and the inspector each have their own live room, and all of them show the same deal.

• Verified parties. Before a contract is awarded, GovFlow runs CRS sandbox checks on the business and the people behind it: TransUnion identity, credit file, PitchPoint liens and judgments, and Fraud Finder. An applicant who fails can't be selected. The database itself refuses the award. Only an attestation hash is stored, never the raw data.
• Claude reads the paperwork. Claude pulls company and owner details out of uploaded bid documents and matches them to CRS-verified companies. It then reads each pay application against the contract, the schedule of values and the accepted milestones, and returns MATCHED, MISMATCH or UNSURE with reasons.
• Agents pay for their own checks. Before any payout, the payer's agent buys a fresh CRS check on the payee for 0.01 test USDC over x402. The new result has to match the identity recorded at award.
• Fraud freeze. A "new wallet" email freezes the bill instantly. The agent re-verifies the payee, checks the claimed sender against CRS, and Claude writes a case file. Two approvers then reject the change.

• Two approvals, then settlement. USDC settles on Base Sepolia to the verified wallet. The same rules apply one level down, from prime to subcontractor.

  How we built it

• SpacetimeDB on Maincloud is the source of truth and the referee. Tables are private, and each org reads only its own my_* views. Reducers enforce roles, state machines, two-person approval, freezes and spend caps. Each room updates live because it subscribes to the same rows, so there's no separate sync code.

• A Node API connects as a single service identity. It does the outside work (Claude, CRS, x402, Coinbase CDP) and writes results back through service-only reducers, and the database checks every rule again.

• Claude (claude-opus-5-5) runs through the Anthropic TypeScript SDK with structured JSON output. One prompt extracts details from documents, one matches bills, and one writes fraud case files.

• Coinbase CDP + x402. An x402 seller endpoint sells the verification check. The agent's CDP wallet is limited by spend controls: one allowed payee, USDC only, Base Sepolia only, and $$0.01 \text{ USDC/call}, \quad 0.10 \text{ USDC/day} \;\Rightarrow\; \le 10 \text{ checks/day}$$ Payouts are CDP server-wallet ERC-20 transfers with idempotency keys and a 1.00 USDC cap.

• CRS sandbox: TransUnion identity, credit, PitchPoint liens and judgments, and Fraud Finder, all run on test personas.

• Next.js + shadcn/ui for the tender board, the rooms, the Live demo view, and the ledger and audit views.

  Challenges we ran into

• Keeping an AI agent away from the money. The agent can only propose. Approving, unfreezing and paying are reducers that require verified humans. Even a fully compromised agent can't pay an impostor.

• Making Claude's verdict stable enough to drive a state change. We tested it on clean bills, bills for the wrong work, and prompt-injection bills. We backed it with rule checks in code that always override Claude, so a bill that tries to give the model instructions is never MATCHED.

• Live demos and flaky sandboxes. The payee check now retries with a 25-second timeout. If CRS still doesn't answer, it reuses the last CRS result and labels it clearly, so the demo never stalls silently.

• Testnet hygiene. We added a Base Sepolia-only guard, a payout cap, faucet limits, and fixed CDP idempotency keys that collided after a database reseed.

• Data gaps. The CRS sandbox has no business-registry or OFAC product. The registry check is a clearly labelled mock, and sanctions come from the Treasury SDN list.

  Accomplishments that we're proud of

• The full flow runs live, end to end: tender, CRS screening, award, Claude bill match, paid x402 CRS check, impostor email, freeze, CRS re-check, case file, change rejected, two approvals, USDC settles on Base Sepolia. The impostor wallet receives nothing.

• The rules live in the database rather than the UI, and the SpacetimeDB module has 73 tests.

• Four sponsors, four distinct jobs: CRS answers who is this?, Claude answers is this bill right?, x402 + Coinbase move the money, and SpacetimeDB enforces the rules.

  What we learned

• x402 is a natural fit for agents that buy checks one at a time, as long as the wallet's spend controls are strict.

• The safest way to use an LLM in a money flow is to let it explain and flag, while code and humans make the decisions.

• A live, subscription-based database makes multiplayer views almost free: every party sees the same truth at the same moment.

  What's next for GovFlow

• Claude vision checks on evidence photos and documents, including a PII checklist.

• Real business-registry and sanctions data sources.

• A bank on-ramp and off-ramp, and payout reconciliation reports.

• Step-up (OTP) authentication for approvers.

• Talking to city finance and capital-projects teams to test the workflow against real procurement.

Built With

• claude
• coinbase
• crs
• next.js
• spacetimedb
• typescript