What is LOOP?
LOOP is an open, draft protocol that lets cities describe the materials and products they hold, publish what is surplus, and record transfers to other cities in one shared machine-readable format. Each city keeps its own records in its own infrastructure. The name stands for Local Optimization with Overflow Protocol.
Cities already hold the data. What they lack is a common way to express it, so surplus in one district and demand in the next stay invisible to each other. LOOP supplies that common expression, and nothing else: no platform to join, no operator in the middle, and no obligation to move records off municipal infrastructure.
Lab-only status. Everything described here exists as a specification, published schemas, and a reference implementation running a scripted demonstration. There are no public pilots, no deployments, and no compliance claims.
On this page
Why this exists
Material recovery today runs as a set of islands. A city knows, more or less, what enters and leaves its own facilities. It usually has no practical way to know that the district twenty kilometres away is landfilling exactly the feedstock its own processor is importing. The information exists on both sides. It has no shared shape, so nobody can act on it.
Today
Four neighbouring cities, four separate systems. Each sees only its own flows.
With a shared format
The same four cities, exchanging directly. No central database appears here.
The platform answer
One operator, one database, everyone joins. Cities are rightly reluctant: it hands operational data and pricing leverage to a third party, and the value of the network accrues to whoever runs it.
The protocol answer
A shared format and a small set of endpoints, the route email and the web took. Any city that speaks the format can exchange with any other. Nobody joins anything, and no operator sits in the middle.
There is a second, more immediate reason. Between 2026 and 2027 a series of European rules turn material and product information into something that has to be digital, structured, and exchangeable. Cities will be asked for structured data whether or not they have somewhere to put it. See the dates.
How LOOP works
The core of the protocol is four steps. The specification calls this the minimal interoperability flow: the smallest thing two nodes can do together and still be useful.
Every record has a defined life
Each entity moves through a fixed set of states. Once something reaches a final state it cannot quietly go backwards.
| Record | States | Final |
|---|---|---|
| Offer | openreservedwithdrawn | withdrawn |
| Match | proposedacceptedrejectedexpired | rejected, expired |
| Transfer | scheduledin transitcompletedcancelled | completed, cancelled |
| Material status | availablereservedwithdrawn | withdrawn |
Four rules stop the obvious failure
These constraints stop the same skip of aluminium being sold to three neighbouring districts at once. The reference implementation enforces them in the database rather than by convention.
- A match can only be created against an offer that is still open.
- Only one active match may exist for an offer at any moment.
- A transfer requires a match that has actually been accepted.
- An offer can never promise more than the batch contains.
The six core concepts
The specification names six concepts. Two are implemented and exercised in the lab demonstration; the economic three, and the metric derived from them, are design models on paper. Each card below states which.
MaterialDNA
Material identityImplemented
The digital identity of a physical material or batch: what it is made of, its category, quantity, quality, where it came from, and every hand it has passed through.
Explore MaterialDNA →ProductDNA
Product identityImplemented
The same idea one layer up: category, condition, manufacturer, lifecycle stage, and a link to the material records a product is composed of.
Explore ProductDNA →Node and federation
The network shapeTwo-node demo
One node per city, holding its own records, signing its own messages, choosing its own peers. Announcements travel a limited number of hops.
Explore Node and federation →LoopCoin
Local unit of accountDesign only
A design for a node-issued local unit with expiry and decay built in, so value circulates rather than accumulates.
Explore LoopCoin →LoopSignal
Community preferenceDesign only
A number between zero and one per material category, expressing how strongly a community wants to keep or attract that material.
Explore LoopSignal →LoopCost
Routing metricDesign only
The figure derived from those signals: a base price plus export and import penalties and a distance component.
Explore LoopCost →How the economic concepts fit together, on paper
LoopSignal is the input and LoopCost is the output. A city expresses, as a number between zero and one, how strongly it wants to keep or attract a material category. That number becomes a penalty on the calculated cost of moving the material across the boundary, in both directions equally.
Try the model
Move the inputs and watch the cost change. A city that badly wants to keep a material raises its own signal, which raises the penalty on sending it away.
LoopCostTotal routing cost for one transfer
Base pricethe offered price, in LoopCoin100.00
Export penaltyBasePrice x OriginLoopSignal30.00
Import penaltyBasePrice x DestinationLoopSignal20.00
Distance costDistance_km x 0.02 LC2.40
Total
The figures update in your browser from the published formula. Nothing is priced, settled, or sent anywhere.
A transfer inside one city incurs only the base price, so short local loops come out structurally cheaper than long ones, without anybody being forbidden from trading further afield when it genuinely makes sense. LoopCoin is the proposed unit those figures would be denominated in, with expiry and decay built in to discourage hoarding.
Anatomy of an identifier
Identifiers are readable on purpose. A material identifier encodes country, city, year, category, and a unique suffix; a product identifier follows the same shape with a different prefix.
A product record for a desk from the same city and year reads PRD-DE-MUC-2025-DESK-F4A7B2.
Categories are a fixed list rather than free text, which is what makes cross-city search possible.
A product record can point at the material records it is composed of, so a desk references its steel and its particle board without duplicating either.
Key terms
Canonical definitions live in the specification. These are the short forms.
- LOOP
- Short for Local Optimization with Overflow Protocol. An open, federated protocol for describing material and product flows between municipal nodes.
- Node
- One autonomous LOOP implementation, typically run by a municipality.
- Node operator
- The municipality, cooperative, or authorised entity accountable for running a node and its data governance.
- Federation
- The peer-to-peer arrangement by which nodes discover each other and exchange metadata, with no central authority.
- MaterialDNA
- The digital identity of a physical material or batch.
- ProductDNA
- The digital identity of a finished or semi-finished product.
- Offer
- A published statement that a material or product is available, in a stated quantity, until a stated date.
- Match
- A proposed and then accepted pairing between an offer and a receiving party.
- Transfer
- The record of the material actually moving: scheduled, in transit, then completed or cancelled.
- LoopCoin
- A draft model for a node-issued local unit of account with expiry and decay properties.
- LoopSignal
- A draft model for a community preference value between 0 and 1 for a material category.
- LoopCost
- A draft routing-cost formula combining base price, export and import penalties, and distance.
- Overflow
- The routing idea the protocol is named after: what happens to surplus when local demand cannot absorb it.
- Settlement
- The step confirming a transfer and its payment. Modelled in the specification, not implemented.
- Audit trail
- The recorded sequence of registration, offer, match, and transfer events held by a node.
- Evidence log
- An append-only record of protocol events, each with a hash and a retention date.
- Data residency
- The property that a city keeps its own records in its own infrastructure.
- Access-scope tier
- One of public, operator, or regulator: who a given passport field is meant to be visible to.
- Digital Product Passport
- The EU concept of a machine-readable record that travels with a product. Usually shortened to DPP.
- Core-DP
- The smallest machine-checkable LOOP profile: two lab nodes, registry and search, the offer-to-transfer sequence, and an evidence log.
- Profile
- A document narrowing the protocol for one interoperability target without changing the base schemas.
- RFC
- Request for Comments. The written proposal format used to change the protocol in public.
What a node is, and what running one involves
A node is one city's LOOP implementation. The specification says what a node must be able to do, not how to build it. Three of the six components it describes are built; the economic three are not.
What a lab node runs on
- A modest serverA small VPS or bare-metal host is enough for lab volumesContainer
- PostgreSQL-compatible databaseHolds the registries and the evidence logContainer
- Redis-compatible cacheQueues and short-lived stateContainer
- S3-compatible object storeDocuments and attachmentsContainer
Where the money goes
- Protocol and schemasOpen source and royalty-freeFree
- InfrastructureWith material-flow volume and retention periodScales
- IntegrationDepends on the ERP or waste system already in placeMain cost
Integration, not hosting, is the line that varies. Connecting a node to an existing enterprise resource planning or waste-management system depends entirely on what a city already runs. The implementation guide sets out a minimum viable checklist.
Data, privacy, and residency
The most consequential design decision in LOOP is what it refuses to carry. If personal data is never in the shared payload, cross-boundary exchange does not become a personal-data transfer question: the awkward part of the assessment disappears instead of being managed.
Permitted in payloads
- Node identifiers
- City names
- Organisation identifiers
- Facility and operator references
Never in payloads
- Personal names
- Email addresses
- Phone numbers
- Any other personal data
What a node operator is expected to hold up
- Data residencyRecords stay in municipal infrastructure, under municipal jurisdiction
- Transport securityCurrent TLS, with forward secrecy expected
- Token expiryAccess tokens must expire; nodes sign their own requests
- Rate limitsPer-user, per-node, and per-search ceilings
- Immutable logRegistrations, settlements, signal changes, node interactions
Federation exchanges agreed material-flow metadata, not raw records. Nothing is pooled centrally because there is no centre. A baseline data-protection assessment for the lab demonstration is published at the DPIA Lite page; any real deployment would need its own.
How the pieces fit together
The word LOOP covers four distinct things: the written specification, the schemas that make it checkable, the software that implements it, and this documentation hub.
- The specificationNormative rules, endpoints, federation behaviourShared
- Schemas and contextsMachine-checkable field definitionsShared
- Node implementationsAny software that speaks the protocolYour choice
- This documentation hubMirrors the spec, schemas, and examplesYour choice
A city can replace the bottom two entirely and still interoperate.
Nodes discover each other through a registry of peers and sign requests with a node identifier, a signature, and a recent timestamp. Announcements propagate with a limited hop count rather than flooding the network, so a working node needs to know its immediate neighbours, not the whole world.
LOOP and the regulatory landscape
European rules are moving material and product information from paper and spreadsheets into structured, machine-readable records. Several are already operative. The pattern is consistent: an identifier that travels with the thing, structured data behind it, and an authority or counterparty able to look it up.
The dates that matter
- 21 May 2026DIWASS is liveCross-border waste shipment documents move electronically. Green-list paper allowed until 31 December 2026.
- 20 Jul 2026EU DPP Registry liveIndexes identifiers and metadata only. Passport content stays with whoever holds it.
- 12 Aug 2026PPWR appliesPackaging identification and conformity documentation. The harmonised data-carrier format is still unadopted.
- 27 Sep 2026Green claims rules bindTightened substantiation for sustainability claims shown to consumers.
- 18 Feb 2027Battery passports requiredEV, light means of transport, and industrial batteries above 2 kWh. Format and access acts are overdue.
- 2027 onwardFirst ESPR product groupsNo product-specific delegated act adopted yet. Iron and steel is furthest along.
What a city can do about each
| Regulation | Status | City action | Where LOOP could help |
|---|---|---|---|
| Waste Shipment and DIWASS(EU) 2024/1157 | Live since 21 May 2026 | Confirm contractors can file shipment documents electronically. Keep records at least five years. | Shipment document reference, facility and operator identifiers, retention date on the transfer record. |
| Packaging and Packaging Waste(EU) 2025/40 | Applies since 12 Aug 2026 | Map packaging categories in procurement. Do not commit to a label format yet. | Packaging as a product record with pool and batch references that survive a reuse cycle. |
| Green claims for consumersDir. (EU) 2024/825 | Binding 27 Sep 2026 | Review published circularity statistics against tightened substantiation rules. | Recorded data is kept separate from any environmental claim about it. |
| Ecodesign and the DPP(EU) 2024/1781 | Delegated acts pending | Assess procurement volumes in the first-wave categories. | Optional passport, classification, and traceability blocks as extension points. |
| Batteries Regulation(EU) 2023/1542 | 18 Feb 2027 | Audit fleet and depot batteries now; treat exact data requirements as unconfirmed. | Battery category, passport identifier, backup copy location, due-diligence reference. |
| German circular-economy policyNKWS and KrWG | Strategy since Dec 2024 | Framing for municipal reuse and repair programmes and cross-boundary material data. | Municipal node interoperability and reusable material identity as design goals. |
Extension points, not claims
LOOP carries optional passport, classification, and traceability blocks alongside its core fields. They are draft discussion fields designed to be extensible toward passport-style requirements, so adopting one later is an addition rather than a rebuild. They are not a readiness claim.
A converging design
The EU registry that went live in July 2026 indexes identifiers and metadata only: passport content stays with whoever holds it. That decentralised, reference-by-identifier shape is the one LOOP arrived at independently.
Caution one
Several acts that would define exact data formats are late. The packaging data-carrier format, and the battery passport format and access rules, are all still unadopted. Any vendor telling you today exactly which fields you will need is guessing. Keep your data structured and your format commitments loose.
Caution two
The international framework that several passport-style field names draw on is itself still pre-release. Any description of a LOOP field as aligned to it is directional, not a conformance statement.
What exists today, and what does not
The protocol is at an early stage. The line between what runs and what is still on paper is drawn below.
Exists today
- A versioned written specification, published schemas, and JSON-LD contexts.
- Worked example payloads for every record type.
- A reference backend implementing the specification endpoints.
- A scripted lab demonstration of the register-to-transfer flow.
- A two-node federation handshake and exchange.
- Public governance, security, and data-protection documents.
Does not exist
- Any public pilot or production deployment.
- Any settlement, currency, or payment behaviour.
- Collection of community preferences, or routing decided from them.
- Generalised federation beyond two nodes.
- Any certification, conformity assessment, or regulatory approval.
- Blockchain-style permanence. The evidence log is append-only storage.
The smallest checkable profile covers exactly two nodes, registry and search, the offer-to-transfer sequence, signed messages, an append-only evidence log, and error handling. It is profile conformance, not full protocol conformance, and it says so.
Governance, and how to take part
Protocol changes go through a public Request for Comments process. Anyone can open a discussion and submit a proposal against a published template; substantial changes need community review before adoption, and each proposal moves through documented states so the reasoning stays on the record.
Versioning is a policy
Minor versions are additive and must not remove or rename existing required fields. Receivers accept additive versions and preserve fields they do not recognise. Payloads written against the previous version stay valid. What you write today should not stop parsing next year.
Candid about its limits
A public proposal records that the standing two-person review quorum is not currently meetable with one active maintainer, and documents the narrower substitute rather than quietly ignoring the rule. A published claims policy forbids asserting pilots, deployments, or compliance without current evidence.
Cities can shape the vocabulary while it is still soft. Tell us what would have to be true for this to be worth running, and which existing systems it would need to talk to.
Questions cities ask
What is LOOP, in one sentence?
LOOP is an open, draft protocol that lets cities describe the materials and products they hold, publish what is surplus, and record transfers to other cities in a common machine-readable format, while each city keeps its own data.
Is LOOP something a city can deploy today?
No. LOOP is an early-stage, low technology readiness level concept. It consists of a written specification, JSON schemas, and a reference backend that runs a scripted lab demonstration. There are no public pilots and no production deployments, and the demonstration flow is explicitly not a pilot.
Does LOOP make my city compliant with the EU Digital Product Passport rules?
No, and nothing on this site should be read as a compliance or certification claim. LOOP carries optional fields designed to be extensible toward passport-style data, so that adopting future requirements is an addition rather than a rebuild. Compliance depends on delegated acts that, for most product groups, have not yet been adopted.
What would it cost a city to run a node?
In the lab configuration a node is a modest server running a PostgreSQL-compatible database, a Redis-compatible cache, and an S3-compatible object store as containers. The protocol itself is open source and royalty-free. The real cost driver is integration with whatever waste-management or asset system the city already runs.
Where does our data live, and who can see it?
Each node stores its own records in its own infrastructure, under its own jurisdiction. Federation exchanges agreed material-flow metadata, not raw records. Protocol payloads are designed to carry no personal data: node identifiers, city names, and organisation identifiers are permitted, while names, emails, and phone numbers are not.
Does LOOP require a blockchain or a cryptocurrency?
No. Nodes exchange signed JSON-LD messages over ordinary HTTPS and keep an append-only evidence log. That log is append-only storage, not a distributed ledger. LoopCoin is a design sketch for a local unit of account with expiry properties; it is not implemented, and no value is issued or settled anywhere.
How is this different from the waste-management system we already have?
Existing systems are excellent at running one organisation and poor at talking to the one next door. LOOP does not replace them. It defines the shared vocabulary and the small set of endpoints that would let two such systems describe the same material to each other without a bilateral integration project each time.
How would we influence the protocol?
Changes go through a public Request for Comments process: anyone can open a discussion and submit a proposal, and substantial changes need community review before adoption. Cities that want to shape the vocabulary before it hardens are exactly the input the process is short of.