Brick #5: The Experiment Ran - a Three-Hop Supply Chain Settled on Arc Testnet

Final brick of the MVP wave - start here: The Bedrij Principle, then Brick #1: Typed Participants, Brick #2: Typed Evidence, Brick #3: Scenario Matrix and Brick #4: Verifiable Vitrine. The hypothesis under test: a complex economic system can be composed from verifiable state transitions.

Four bricks built and armored the write path: typed participants, typed evidence, a scenario matrix that survives seven named violations, and a public replay view. The anchor article ended with a promise - "The experiment has started." This article is the receipt: on 2026-11-08 a real three-hop shipment ran the full custody cycle on Arc testnet, each hop escrowed in its own ERC-8183 job, all three settled and verified in 53 seconds. Proof -> acceptance -> settlement, on real rails, with transaction hashes you can open yourself.

What exactly ran?

Short answer: shipment dogfood-1794151620383 - a cold-chain delivery with three hops, played by three different participant types from Brick #1. A shipper contracted an agent (Plant intake), the agent handed custody to a device (ColdVan unit), and the device delivered to an org (Restaurant). Each hop carried a 0.01 USDC escrow in its own ERC-8183 job on the ref proxy 0x0049e5...bf6a0, Arc testnet (chainId 5042002). Result: status completed, 3/3 hops verified, outstandingUsdc: "0".

The shipment, in one table:

Six real transactions - three job creations, three settlements. Not a fixture, not a fork, not a replayed simulation: Arc testnet, confirmed on the public explorer.

The participants are real keys with real labels (Brick #1's typed roles, live):

What did each hop actually execute on-chain?

Short answer: the full ERC-8183 lifecycle, not just an event log entry. Per hop the executor drives four stages of contract state: the provider signs setBudget, the client approves and funds the escrow, the provider submits the deliverable, and the evaluator completes the job - releasing escrow only after the accept.

provider setBudget | client approve + fund <- 0.01 USDC escrowed | provider submit <- deliverable declared | evaluator complete <- escrow released 

That ordering is the Bedrij primitive running on contract state instead of test fixtures. Hop i+1 cannot hand off before hop i is paid - the same ShipmentOrderError guard the scenario matrix breaks against, now re-deriving state from a log whose pay/verify events were produced by real settlement transactions. The economic loop the anchor drew as proof -> acceptance -> settlement fired three times in 53 seconds of wall clock (15:27:41Z - 15:28:34Z).

And because the run wrote to the production Postgres ledger (SC_DOGFOOD_DB=1), the whole timeline is publicly replayable - Brick #4's vitrine, pointed at a real shipment:

curl https://agentbadge.xyz/api/ledger/shipments/dogfood-1794151620383 

{ "shipmentId": "dogfood-1794151620383", "status": "completed", "timeline": [ "13 events, 15:27:41Z - 15:28:34Z" ], "hops": [ "3 hops, all verified, jobs 66/67/68" ], "aggregate": { "completedPct": 100, "outstandingUsdc": "0" } } 

(Truncated for print - the verbatim response is at the URL above.)

What did running it live actually find?

Short answer: four executor bugs that no test caught, because the in-memory chain lets any key call any method. The ref contract does not. Running against real signatures exposed the write path's hidden assumptions - which is exactly why a live dogfood is the last brick, not the first.

• Provider-signed setBudget. The ERC-8183 ref variant restricts setBudget to the provider account. The executor used to send it as the client - on a real contract that is a revert, in a test it is silent. Fix: spec.providerKey plus a sendAsAccount path that signs locally and broadcasts the raw transaction.
• Provider-signed submit before complete. complete requires the job to be in Submitted status - the provider must declare the deliverable first. The earlier order tried to complete directly after funding.
• ClientCannotBeProvider. Hop 2's receiver is the restaurant - but the client wallet cannot also act as a provider. The run needed a dedicated restaurant key (SC_DOGFOOD_RESTAURANT_KEY) or the contract refused the hop.
• Resume, don't orphan. A failed live run leaves funded-but-unfinished jobs on-chain. SC_DOGFOOD_RESUME_JOBS reuses them instead of orphaning escrow - the same C-1 orphan-escrow finding the audit flagged before we ever went live.

Two earlier attempts informed this one. An in-memory run (dogfood-1794150937615, jobs 63/64/65) exercised the resume path on reused jobs; the DB-backed run above is canonical because it is the one the public replay serves.

Did the audit hold up under live fire?

Short answer: yes - the two Critical findings were exactly the class of bug that kills a live run, and both were fixed before the first testnet transaction. Audit first, live second: the gate was load-bearing.

Brick #5 had its own external adversarial review before going live. Verdict: REQUEST CHANGES - 2 Critical, 4 High confirmed. C-1 was the orphan-escrow hole: if createShipment succeeded on-chain but the ledger write failed, escrow sat funded with no record. C-2 was a fail-open budget path - a null/zero-amount job could slip past as a plan of "0". Both were fixed and re-verified, the pack went from 87/87 to 99/99 green with 12 new regression tests, and only then did the executor see a real network. The findings that would have lost testnet escrow were found by an auditor, not by a revert.

What does this prove - and what does it still not prove?

Short answer: the transition contract executes on real rails. It does not yet prove automated verification, non-linear chains, or real money at scale - and the article says so in the same breath as the result.

Three honesty notes matter for anyone replaying the shipment. The pay/txHash fields in the replay response are ledger-asserted - written by our executor, not independently chain-verified (the tx hashes above are the independent check; open them). Settlement was ops-settled - the evaluator signer is a delegated operations key, not the logical evaluator in the plan. And the amounts are deliberately tiny: a dogfood run proves the rail, not the revenue.

The experiment ran

The anchor article asked whether a complex economic system could be composed from verifiable state transitions, and promised five bricks of measurement. The bricks are laid:

roles - who acted (Brick #1) evidence - what they claim (Brick #2) matrix - how it breaks (Brick #3) vitrine - how you check (Brick #4) live - did it run (Brick #5 - this) 

What shipped in one number: 53 seconds, 3 hops, 6 transactions, 13 log events, 0 USDC outstanding - a custody cycle that a stranger can re-derive from a public endpoint, with the transaction hashes in the explorer one click away. The transition contract did not just type-check against a fixture. It settled.

That is the whole answer to the hypothesis. Not "we believe it works" - here is the shipment, replay it.

Don't certify. Measure.

Hero image: https://agentbadge.xyz/images/blog/supply-chain-live-testnet-hero.webp — canonical: https://agentbadge.xyz/blog/supply-chain-live-testnet