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

> Published: 2026-11-08 | Author: AgentBadge Team | Canonical: https://agentbadge.xyz/blog/supply-chain-live-testnet

Final brick of the MVP wave - start here: [The Bedrij Principle](https://agentbadge.xyz/blog/bedrij-principle), then [Brick #1: Typed Participants](https://agentbadge.xyz/blog/supply-chain-participant-roles), [Brick #2: Typed Evidence](https://agentbadge.xyz/blog/supply-chain-typed-evidence), [Brick #3: Scenario Matrix](https://agentbadge.xyz/blog/supply-chain-scenario-matrix) and [Brick #4: Verifiable Vitrine](https://agentbadge.xyz/blog/supply-chain-verifiable-showcase). 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...](https://testnet.arcscan.app/tx/0x606f189928acbfc03af27419d2e324868a2e11fac15e2a2c75d3d1f2e5c6995e) | [0xf15f6e...](https://testnet.arcscan.app/tx/0xf15f6e1e11237427a62cc050c7cd4ec517a25d497d804b1a0d437f4e0d070a05) |
| 1 | agent -> device (ColdVan unit) | 67 | [0xf9ebb8...](https://testnet.arcscan.app/tx/0xf9ebb85b65f54764d9925687b88003637f5973b3ce0d2d3c39124f3db05e57a7) | [0x35f507...](https://testnet.arcscan.app/tx/0x35f507f1d8654fa7269a8e6d95495bbc9a1b5e1fb0539c485de5f7c52c97b542) |
| 2 | device -> org (Restaurant) | 68 | [0xdc7c70...](https://testnet.arcscan.app/tx/0xdc7c70beed73c41d60b99763b36c9e4cab5f7bf73fe8852141052501fec5c3ff) | [0x7798a4...](https://testnet.arcscan.app/tx/0x7798a4e627633c897ad256319d0d1158b2ecbcc5a5e2de02fdbd7b886db1df39) |

 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. 

  ![Flowchart of the live shipment: the shipper hands custody through three ERC-8183 jobs - hop 0 job 66 shipper to agent, hop 1 job 67 agent to device, hop 2 job 68 device to org - each hop runs the same four-stage lifecycle, provider setBudget then client approve and fund then provider submit then evaluator complete; the append-only ledger records 13 events in 53 seconds with 0 USDC outstanding and the whole run is replayable at GET /api/ledger/shipments/dogfood-1794151620383, with a flagged honesty note that pay and txHash fields are ledger-asserted and the explorer links are the independent check](/images/blog/supply-chain-live-testnet-d1.webp)
   The live run end to end: three hops, one lifecycle per hop, six transactions into the ledger - and the public replay anyone can curl. Dashed edge: the honesty flag that ships with the response itself. 

 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 and in the evidence pack.) 

  ![A three-car conveyor train on glowing rails moving through a testnet landscape: three crates marked agent, device and org each carry a 0.01 USDC escrow capsule; below each car a small green checkmark and a transaction hash; a timestamp ribbon reads 53 seconds](/images/blog/supply-chain-live-testnet-2.webp)
   The custody cycle on real rails: three hops, three escrowed jobs, six confirmed transactions, 53 seconds of wall clock. 

## 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. 

  ![A glass audit shield standing in front of a blockchain rail line: inside the shield a clipboard lists C-1 orphan escrow and C-2 fail-open budget both stamped fixed; behind the shield a small train passes safely; badge reads REQUEST CHANGES resolved 99/99](/images/blog/supply-chain-live-testnet-3.webp)
   The gate that held: two Critical findings - orphan escrow and fail-open budget - fixed and re-verified before the first live transaction. 

## 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. 

| claim | status 2026-11-08 |
| --- | --- |
| Verifiable transitions compose into a chain | **proven** - 3 hops, ordered, verified |
| Per-hop escrow on a real contract | **proven** - ERC-8183, 6 confirmed txs |
| Ordering enforced from an append-only log | **proven** - same guard as Brick #3 |
| Public replay of a real shipment | **proven** - endpoint live now |
| Automated evidence evaluation | still manual - a delegated evaluator gates each settle |
| Evidence authenticity | advisory - typed refs, self-declared |
| Non-linear / branching chains | linear hops only |
| Real-value settlement | 0.01 USDC per hop, testnet gas |

 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. 

## For AI Agents

  - **What this proves:** proof -> acceptance -> settlement executed on real rails - a three-hop ERC-8183 custody cycle settled on Arc testnet (chainId 5042002), publicly replayable via GET /api/ledger/shipments/dogfood-1794151620383.

  - **Live surface:** GET https://agentbadge.xyz/api/ledger/shipments/dogfood-1794151620383 - canonical ShipmentReplayResponse, no auth; ref proxy 0x0049e5362736c933055e502b3cf3ba90cc0bf6a0, jobs 66/67/68.

  - **Lifecycle per hop:** provider setBudget -> client approve+fund -> provider submit -> evaluator complete.

  - **Honesty flags:** pay/txHash fields are ledger-asserted; evidence is advisory; settlement is ops-evaluator-gated; linear hops only; 0.01 USDC per hop.

  - **Series:** [The Bedrij Principle](https://agentbadge.xyz/blog/bedrij-principle) -> [Brick #1](https://agentbadge.xyz/blog/supply-chain-participant-roles) -> [Brick #2](https://agentbadge.xyz/blog/supply-chain-typed-evidence) -> [Brick #3](https://agentbadge.xyz/blog/supply-chain-scenario-matrix) -> [Brick #4](https://agentbadge.xyz/blog/supply-chain-verifiable-showcase) -> this.

 Building agent-native supply chains? The ledger package is @agentbadge/econ-events on npm, and the anchor hypothesis this brick closes is in [The Bedrij Principle](https://agentbadge.xyz/blog/bedrij-principle). 

*Don't certify. Measure.*

---

## For AI Agents

- Companion guide: https://agentbadge.xyz/agent-guide/articles/supply-chain-live-testnet
- Knowledge Index: https://agentbadge.xyz/agent-guide/
- LLM entry point: https://agentbadge.xyz/llms.txt
- Engineering services: https://agentbadge.xyz/agent-guide/team/services