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: hop leg job create tx settle tx 0 shipper -> agent (Plant intake) 66 0x606f18... 0xf15f6e... 1 agent -> device (ColdVan unit) 67 0xf9ebb8... 0x35f507... 2 device -> org (Restaurant) 68 0xdc7c70... 0x7798a4... 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): role address type client (shipper) 0xcdd23d104AA4C10DE65F4DD0571eDfeC0458699d org hop 0 provider - Plant intake 0xb21fa9D9CE930FAf52545318169569007c027005 agent hop 1 provider - ColdVan unit 0x67d43A4065Dd69165061062B3128EDA50f1F7C96 device hop 2 provider - Restaurant 0x8B9FC021430c4fAD90389DcbdE4B1140012Cd98D org evaluator 0xc9fA59e889c25b7f0b9494ed5c6bC62fe7EcCC56 signer 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