OUROBOROS
Deposit-refund loops that close, custody chains that sign, and recycling claims that survive an audit.
Open the live chamber in the app
Who this serves
- Deposit scheme operator. Every deposit escrowed, every refund against a verified return.
- Municipal waste authority. Hauler payments released on weighbridge attestations.
- Recycler and processor. Inbound custody signed; your output claims carry proof.
- Producer responsibility org. Recovery targets measured on a ledger, not on self-reports.
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
| Agent | Role | Ceiling |
|---|---|---|
scheme-treasury | Holds deposit escrows | Refund on verified return only. Cannot mint. |
return-points | Verify and sign returns | Attest returns at their own location, nothing else. |
hauler-fleet | Moves material, signs custody | Its own handoffs; paid on attested weight. |
processor-intake | Signs intake and output | Attestations on its own gates. |
The flow, step by step
- The deposit escrows when the container ships. It is visible, not pooled away.
- Custody is signed handoffs: round, station, processor.
- A registered return point verifies and signs the return.
- The refund releases. One container, one refund.
- Recovery is a ledger fact. The quarterly report is a query.
Each need, mapped to a live primitive
| The need | The protocol primitive | Status |
|---|---|---|
| Deposits held, not pooled away | Escrow per deposit; refund on verified return | LIVE |
| Custody as signed handoffs | Attested chain from bin to processor | LIVE |
| Verified processing gates payout | Milestone contracts: weighbridge attestation releases | LIVE |
| Municipal books in public | Immutable ledger; an audit is a query | LIVE |
| Haulers with reputations | Trust scores on verified delivery, not tender prose | LIVE |
| Fraud rings surface | Collusion detection over the refund graph | LIVE |
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.
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
- A container ships and its deposit enters escrow. Not a liability line: escrow, on the ledger.
- The container comes back. A registered return point verifies and signs.
- The attestation couriers in through the fabric.
- One refund per container identity. The double-claim arrives as a refused duplicate, not a quiet loss.
- The loop closes on the ledger, append-only.
- What never returns stays visible as unredeemed escrow instead of vanishing into a reconciliation.
- Downstream, the collection round signs, the transfer station weighs and signs, the processor signs intake.
- The weighbridge attests the tonnage. The invoice does not.
- The municipal payment for the round releases against the attested weight.
- The hauler is credited exactly once, and the hauler who reliably delivers what it collects carries that record to the next tender.
- The processor’s intake closes the custody chain.
Adoption, phase by phase
Discover: The loop, re-read as escrow.
- Runs. Nothing. One material stream redrawn as deposits, returns, custody handoffs and round payments.
- Agents. None. The scheme operator pins down what a verified return requires, before hardware is bought around the wrong answer.
- Integrates. Nothing. RVMs, scales and routes stay exactly as they are.
- Deliberately not yet. No escrow, no gate, no chain.
- Proof that gates the next phase. One quarter’s reconciliation re-expressed as escrow flows, and the unexplained gap in the spreadsheet appears as a named, sized unredeemed balance.
Pilot: One municipality, real refunds, small deposits.
- Runs. A single-VM frame for the scheme. Return points join with seats; one hauler enrolls.
- Agents. scheme-treasury, the refund gate, return-point attestors, one hauler signing custody.
- Integrates. RVMs feed the return points; one weighbridge feeds the round settlement.
- Deliberately not yet. One municipality. Processors still invoice in parallel. The PRO reads reports, not the ledger.
- Proof that gates the next phase. A month of returns refunds exactly once per container identity, with every staged double-claim refused and logged.
Production: The scheme at scale, the quarter as a query.
- Runs. One registry per scheme or authority. About nine containers, beside the systems that already run the routes.
- Agents. The full cast; haulers paid on attested weight; unredeemed escrow visible as a standing figure.
- Integrates. RVMs, weighbridges and route scanners feed attestors; producer responsibility reporting reads the ledger.
- Deliberately not yet. Environmental certification. The ledger proves custody and payment, and the regulator’s standards remain the regulator’s test.
- Proof that gates the next phase. The quarterly recovery report to the PRO is produced as a query over the ledger, and an auditor reproduces it independently to the tonne.
Federation: Schemes and processors as peers.
- Runs. Unchanged. Neighbouring schemes and large processors bring frames or seats.
- Agents. Hauler records travel with DIDs to the next tender; cross-scheme material flows settle like everything else.
- Integrates. Each new participant is a signed card and a licence.
- Deliberately not yet. A corrupt scale is a physical-world problem the ledger records but cannot prevent, in every phase.
- Proof that gates the next phase. Material crossing two schemes settles both sides from one custody chain, with no reconciliation meeting between the operators.
Sizing
| Level | What | Containers |
|---|---|---|
| L1 | Return points and small haulers join with accounts | 0 of theirs |
| L2 | A processor runs intake agents against a hosted seat | agents only |
| L3 | One 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
- Infrastructure. One registry per scheme or authority; processors and haulers connect as agents.
- Agents. 4 to 6 roles; return points are the widest tier and the cheapest to run.
- Integration. Weighbridges, reverse vending machines and route scanners feed the attestors; the physical logistics stay as they are.
What this does not claim
- OUROBOROS proves custody and closes payment loops; it does not certify that processing met any environmental standard, which remains the regulator’s test.
- Recovery figures are as honest as the attested weights behind them; a corrupt scale is a physical-world problem the ledger records but cannot prevent.
Browse all 21 blueprints, read the documentation, or start at theprotocol.cloud.