Marketplace & CO₂ tokenisation#
Profile owners: Nunsys + LogiNex · LDT-UC-05 · Status: 🟠 skeleton pre-filled
1–2 · Identity, problem & context#
The Marketplace of the EU LDT Toolbox (WP6) makes twin data and services discoverable and tradable, and adds an incentive layer: verified CO₂ savings earn tokens/rewards, using the iSHARE Trust Framework to keep claims and identities honest — economic rewards for behavioural change.
3 · Objectives & KPIs#
Decided Metrics: published assets and services; reuse events; verified disclosure and credential exchanges; token-programme uptake.
Needs owner — Nunsys.** Targets and measurement window per metric. The one worth defining carefully is reuse events, since it is the only metric here that measures whether the data space works rather than whether it was built: a listing nobody consumes is activity without value. Define what counts as a reuse event — a contract negotiated, a transfer completed, or a repeat transfer — before the number is reported.
4 · Stakeholders#
Nunsys (operator), LogiNex (CO₂ verification methodology), all data providers/consumers, citizens (reward recipients), cities (public-value guardians).
5 · Data needs & sources#
Offering metadata (DCAT-AP + ODRL), verified emission-savings computations (LCMM / ISO 23795-1 based), transaction records.
6 · Sharing rules this use case needs from the scheme#
- Listing eligibility = valid credential + policy-complete description (+ conformance evidence for certified badges).
- Token issuance only on LogiNex-verified savings — methodology documented & auditable; anti-gaming controls.
- Marketplace ToU as contract annex (Nunsys 🧩 in Contractual framework); transaction fees & tracking per Value creation services.
- Reward data touching individuals (wallets of citizens) → GDPR + Commons rules apply.
7 · Architecture (building blocks used)#
Catalogue (TM Forum product catalogue as the single authoritative source for offerings, exposed read-only as DCAT-AP 3.0 and OGC API – Records, with site brokers remaining the source of truth for the data itself — see Publication & discovery section 3 and PD4 v1.0 §4), EDC-based exchange, credential-gated listing, token ledger.
Needs owner — Nunsys.** The ledger or registry choice for tokens is unmade, and it is not a purely technical decision. A distributed ledger brings MiCA and environmental-footprint questions into a sustainability project; a conventional registry does not, and loses the transferability that makes a token a token rather than a loyalty point. State which, and why.
Whichever is chosen, the scheme needs: where token state lives, who operates it, what happens to balances if the operator stops, and how a token issued on a later-corrected CO₂ figure is handled — reversal, adjustment, or neither. That last question has no answer anywhere in the scheme and is the one an auditor will ask first.
8–12 · Timeline, value, risks, EU alignment#
Decided Marketplace per the WP6 plan (M9+ ramp-up). Value: sustainability of the LDT through revenue, and incentivised participation.
Proposed Risks and mitigations:
| Risk | Mitigation |
|---|---|
| Greenwashing exposure if verification is weak | documented, auditable methodology (LCMM / ISO 23795-1); method reference carried in metadata and provenance; the exposure falls on every participant, which is why this is a scheme rule rather than a LogiNex preference |
| Token regulation (MiCA) | Needs owner — unresolved, see below |
| Gaming of the reward mechanism | anti-gaming controls — unspecified; the open 🧩 in Value creation services |
| Liability for incorrect reward calculations | proposed allocation in Value creation services section 6; not agreed |
| Operator conflict of interest — Nunsys runs the market and sells on it | objective listing rules applied equally, plus an appeal route to TIPS; the appeal route does not exist yet |
Needs owner — LogiNex + iSHARE legal.** The MiCA question needs closing in writing, once: if the reward token is not a crypto-asset under MiCA, record why (non-transferable, no secondary market, redeemable only within the scheme) and the design constraints that keep it so. A token designed without that constraint in mind may acquire it accidentally.