THEPROTOCOL

OUROBOROS

#20 of 21Tier II · full anatomy6/6 primitives live in production
Waste and Circular Economy

Deposit-refund loops that close, custody chains that sign, and recycling claims that survive an audit.

Open the live chamber in the app
The animated flow, the attack replays and the deep architecture run there; this page is the reference text.

Who this serves

The problem

The circular economy runs on claims nobody can check: deposit schemes leak refunds to fraud, recovery rates are self-reported, and the custody chain between the bin and the processor is a stack of paper the auditor samples once a year. Money moves on trust in an industry priced by the tonne.

The system

OUROBOROS runs a deposit-refund scheme the way an engineer would: every deposit sits in escrow when the container ships, and the refund releases when the return is verified at a registered point, one refund per container identity, with the double-claim arriving as a refused duplicate rather than a quiet loss. The scheme operator stops reconciling spreadsheets against warehouses; the loop closes itself, and what does not return stays visible as unredeemed escrow rather than vanishing.

Downstream, custody is a chain of signed handoffs: the collection round signs, the transfer station weighs and signs, the processor signs intake, and the municipal payment for the round releases against the weighbridge attestation instead of the invoice. When the producer responsibility organization asks what was actually recovered this quarter, the answer is a query over the ledger, and the hauler who reliably delivers what they collect carries that record as a score the next tender can read.

The cast and their ceilings

AgentRoleCeiling
scheme-treasuryHolds deposit escrowsRefund on verified return only. Cannot mint.
return-pointsVerify and sign returnsAttest returns at their own location, nothing else.
hauler-fleetMoves material, signs custodyIts own handoffs; paid on attested weight.
processor-intakeSigns intake and outputAttestations on its own gates.

The flow, step by step

  1. The deposit escrows when the container ships. It is visible, not pooled away.
  2. Custody is signed handoffs: round, station, processor.
  3. A registered return point verifies and signs the return.
  4. The refund releases. One container, one refund.
  5. Recovery is a ledger fact. The quarterly report is a query.

Each need, mapped to a live primitive

The needThe protocol primitiveStatus
Deposits held, not pooled awayEscrow per deposit; refund on verified returnLIVE
Custody as signed handoffsAttested chain from bin to processorLIVE
Verified processing gates payoutMilestone contracts: weighbridge attestation releasesLIVE
Municipal books in publicImmutable ledger; an audit is a queryLIVE
Haulers with reputationsTrust scores on verified delivery, not tender proseLIVE
Fraud rings surfaceCollusion detection over the refund graphLIVE

The attack this chamber refuses: The container that returned twice

The attack. A fraud ring re-presents redeemed container identities across different return points to drain the deposit pool a second time.

Why it fails. A refund is keyed to the container identity and released from its own escrow exactly once; the second claim finds the escrow already settled. The idempotency machinery that absorbs honest retries is the same machinery that refuses dishonest ones, and the ring’s correlated claims are a shape the daily graph sweep reads.

Rail S06 · Presence proof. The verified-user bit is set by the authenticator and covered by the signature. Possession is not presence.

What actually happens. The duplicate claims refuse cleanly, the pool never drains, and the correlated return-point pattern lands on the fraud desk as a flagged set.

Deep architecture

OUROBOROS deployed: the scheme’s frame holds the deposit escrow, the refund gate and the custody ledger; return points, haulers and processors act from their side of the fabric; the weighbridges feed the round settlements. What never comes back stays visible as unredeemed escrow instead of vanishing, and the quarterly recovery answer is a query. The trace replays one container and one collection round.

The deployment, traced

  1. A container ships and its deposit enters escrow. Not a liability line: escrow, on the ledger.
  2. The container comes back. A registered return point verifies and signs.
  3. The attestation couriers in through the fabric.
  4. One refund per container identity. The double-claim arrives as a refused duplicate, not a quiet loss.
  5. The loop closes on the ledger, append-only.
  6. What never returns stays visible as unredeemed escrow instead of vanishing into a reconciliation.
  7. Downstream, the collection round signs, the transfer station weighs and signs, the processor signs intake.
  8. The weighbridge attests the tonnage. The invoice does not.
  9. The municipal payment for the round releases against the attested weight.
  10. The hauler is credited exactly once, and the hauler who reliably delivers what it collects carries that record to the next tender.
  11. The processor’s intake closes the custody chain.

Adoption, phase by phase

Discover: The loop, re-read as escrow.

Pilot: One municipality, real refunds, small deposits.

Production: The scheme at scale, the quarter as a query.

Federation: Schemes and processors as peers.

Sizing

LevelWhatContainers
L1Return points and small haulers join with accounts0 of theirs
L2A processor runs intake agents against a hosted seatagents only
L3One frame per scheme or authority~9, one VM up

One container, shipment to refused double-claim

sequenceDiagram
  participant Sch as scheme-treasury
  participant TEG as deposit escrow
  participant RP as return point (their frame)
  participant Fab as federation fabric
  participant Gate as refund gate
  participant ES as custody ledger
  Sch->>TEG: deposit escrowed at shipment
  RP->>Fab: return verified, signed
  Fab->>Gate: relayed, principal checked
  Gate->>TEG: refund, one per container identity
  TEG-->>ES: loop closed, append-only
  RP->>Fab: the same container, claimed again
  Fab->>Gate: relayed
  Gate-->>RP: refused duplicate, on the record
  Note over ES: what never returns stays visible as unredeemed escrow

Topology, as declared

flowchart LR
  P["producer"] -->|"deposit per container"| TEG["deposit escrow<br/>one refund each"]
  H["hauler custody<br/>signed handoffs"] --> RP["return point<br/>verifies + signs"]
  RP -->|"verified return"| G{"return gate<br/>idempotent"}
  G -->|"release refund"| TEG
  W["weighbridge attestation"] -.->|"gates hauler payment"| CS["milestone contract"]
  TEG --> ES[("recovery ledger<br/>audit = query")]

Standing it up

What this does not claim