The fed8ra pilot explores how European providers could share compute, AI, storage and network resources, account for their contributions and settle net obligations with a connected evidence trail. This page describes the pilot, its demonstrations and the work ahead.
122-firm B200 pilot · verified results ▸Explore the user-portal concept ▸See the netting demonstration ▸
The rail this pilot runs on has been under a continuous live test since 29 September 2026 — the same rail, never changed, that every edge below books into.
Each sealed period holds about sixty million records, and a partner's record is one of them: the six edges of the sample below are booked among these, not beside them. The figures are the pilot page's own (live.tsv, read by this page's script; dated reading 23 Oct 10:54 UTC, 203.57 bn of them since the live run began); the objects per send, the connections and the machines are on the measured numbers.
What has been proven so far, by whom, and what has not. The figures are a dated reading; the full result of the 24-hour run follows when it ends.
A mutually authenticated route on the public port 443: the partner's certificate is signed by the pilot's own authority, the partner pins the relay's fingerprint, one host and one relay per partner, exactly three rail services reachable and nothing else. Proven from outside the cluster with 30 of 30 checks, including a live certificate revocation and a sealed period fetched and verified through the tunnel.
The pinned server edge installed in a cloud sandbox the pilot does not operate, with a key that never left it: one synthetic record → the existing door → FINAL strictly verified 18 min 41 s after submission; the same proof verified offline on two machines, and once more independently against the rail's own seal.
The same package on four Cotrugli machines in Hvar and two in a German data centre, each with its own key and route: every record reached FINAL. A 24-hour sample, one record a minute per edge, runs since 22 Oct 20:45 UTC.
A real OpenNebula 7.4 (the pilot's own) with its state hooks: every VM start and stop becomes one record in the executing provider's own book through the same server edge and the same route. First proven on 23 Oct on an hourly-billed machine in Frankfurt (OpenNebula 7.4.1): a VM's RUNNING and DONE reached FINAL within 23 minutes and were verified by the edge and, independently, against the rail's own seal (records 93,004 and 6,093,148 of 60,101,115 in that period, the same fold, object, root and seal). That machine was switched off the same evening and the lab moved to one of the pilot's own Hetzner machines (a miniONE 7.4 with LXC guests), where a timer has run one real VM lifecycle every five minutes since 23 Oct 22:13 UTC. Read on 25 Oct 09:25 UTC: 416 lifecycles, 835 state-change events through the hook, 835 booked by the provider's edge, 828 with a FINAL proof and all 828 verified strictly against the pinned keys, 7 inside the current period, 0 refused. Two package findings are recorded on the way: the hook speaks OTLP/JSON while the edge takes protobuf (a small bridge on the machine closes that), and one edge books one provider, so a machine with three provider clusters needs three edges. Our own VMs and identities; nothing agreed with the OpenNebula project yet.
On a second German machine the pilot runs the ApeiroRA audit-logging collector exactly as the 122 twin edges do (the same published image, by digest, with strict signature verification) in front of the same server edge on the same route; a generator feeds it one record a minute in the shape of ApeiroRA's audit SDK, signed with the collector's key. Over 24 hours from 23 Oct 11:50 UTC: the collector verified every record it was given (1,569 verified, 0 refused), the edge booked 1,416 and every one of them reached FINAL; the first two were verified by the edge and, independently, against the rail's own seal (records 6,533,648 and 12,052,529 of 60,101,204 in that period). What this does and does not show: the collector that a platform operator would run passes its records through unchanged into sealed, offline-verifiable proofs; the signal here is synthetic, not a platform's own events.
For the executive. An insured fleet operator, its insurer and a driving-system supplier, each with its own ledger on its own machine. When a driverless ride ends in a loss, the operator's claim, the insurer's acceptance under the policy's limits, the insurer's recovery notice to the supplier, the supplier's objection, the ruling and the settlement all become records that each party holds and that anyone can verify, so that no party has to trust another's log. The machine decides only what has a yes-or-no answer: does the proof verify, did both parties record the same event, is the claim inside the policy. People decide liability, under rules accepted in advance, and a party's honesty is never judged by whether it lost. First cycle, 25 Oct 12:06–14:03 UTC: six incidents, five scenarios, each ending where the rules say: a clean claim accepted and paid; a software-version dispute decided once for the insurer and once for the supplier, each with a written reason; a tampered proof rejected; a claim above the policy limit stopped before any work; a recovery notice without the counterparty's own record rejected. About fifteen minutes from an incident to its sealed proof, under a minute from the proof to an accepted claim; two settlements on a test network. It runs on the same market, Chamber rules and rail as the labs above, one incident every twenty minutes. Synthetic incidents in the shape of ACCORD 22; lab identities, no insurer, vehicle or software company involved; test units, no money; the rulings in the lab are a person's, by the Chamber's rules.
Six edges on the pilot's own iron (four Hvar VMs, two Hetzner boxes), one record a minute each for 24 hours: 8,640 submitted, 8,640 booked, 8,640 FINAL, 8,640 verified strictly by the edges with the pinned keys; 0 refused, 0 verification failures, 0 read errors, 0 timeouts. From booking to FINAL: median 1,111–1,151 s per edge, 90th percentile 1,387–1,427 s, 99th 1,588–1,694 s; 90 % of records sealed in the DLT period right after their cell period and 10 % one period later, which is the rail's cadence. Three records in all, one each on three edges, took 46–54 minutes: the door rejected a relay stream once and the edge re-sent them; nothing was lost and nothing was retried by the driver. The tunnels reconnected only when our own ingress reloaded. Offline analysis, counters and the six event files: evidence e3-hvar-sample24-20261023 in the pilot's PR.
fed8ra is a proposal by HashNET for cooperation across the 8ra federation. The pilot brings together reference integrations, resource accounting and evidence-based clearing. A shared customer portal and the federation’s governing body are proposed next steps.
A possible customer experience: find resources, configure a service and review a request in one workspace. The separate interactive concept shows that direction with fictional offers; it is not a connected marketplace.
The reference trail follows an order through agreement, delivery and measurement. The netting demonstration then explores how mutual resource claims can be offset and connected to a signed settlement record.
A member-led non-profit could define participation, contribution, clearing and dispute rules. Its governance, fees and billing responsibilities still need to be agreed; the web demonstration does not establish them.
ACTIVE: the public read-only viewer and historical-review connection on the dedicated Telemach FED8RA LAB. VERIFIED: historical NEO inclusion of the synthetic €100 case, plus a separate strict final rail proof for its hosted review after interruption and recovery.
PENDING: Revolut sandbox access, a matching bank confirmation and the main company portal connection. Historical inclusion is not a final proof on the current rail or proof of payment. Dated status: 15 October 2026; no live bank feed.
What members accept: the five proofs in every case file, a deadline of one month from a summons booked in the recipient's own book, the dispute rule (no receipt, no evidence or silence loses), fees (both pay, the loser pays all), tiers by value, originals kept under their hash, consequences through the passport, and the process from claim to signed decision.
The roster groups 20 provider entries by resource family. Use “View example” to replay the same historical reference flow with a selected label. These entries are not bookable offers or statements of available capacity.
Virtual machines, Kubernetes, GPU hours — the clusters the continuum runs on.
8 providersPrivate LLM inference, fine-tuning and chat, inside the EU, on the buyer's own data.
4 providersObject and block storage, backup and archive, with the proof of where the bytes sit.
4 providersInterconnection, private links and exchange points between the federation's sites.
2 providersIndustrial and on-site edge, next to the plant, the turbine, the hospital.
2 providersThe families reflect the pilot roster’s role mapping. Platform Mesh is the reference integration used by this demonstration; it does not imply that each named firm has published a service there. The providers are the 8ra consortium's — the public participant list on www.8ra.com, under the NEO names the twin uses (neoedgex deploy/neo8ra-twin/roster.py).
Six steps from the catalog to the invoice. Each step shows the record it leaves — the reference trail as booked at four real edges in the lab on 1 October 2026, in the names Platform Mesh itself uses.
The animation explains discover, agree, deliver, measure, clear and invoice using the recorded lab example. It does not submit an order or provision resources for the selected firm.
The trail: cotrugli.tech/demo/8ra/mesh/ — the Platform Mesh flow of a private LLM subscription (APIExport → Account → APIBinding → LLMInstance → the day measured → the week stated), 32 events in four books, booked at four real edges on neo-7 (core 116ad2c, 1 Oct 2026 14:13Z) with every hash as predicted. The clearing and the invoice are fed8ra's steps on top of that trail; in the pilot the Revolut Business sandbox stands in for SAP's billing (TRU-wallet, settled 18 Aug 2026, rail transaction 055746a9…).
This configuration sketch explores how a participant might combine a marketplace, billing, evidence and governance. Changing these options illustrates the proposed model; it does not configure a live integration.
HashNET's triple-entry bookkeeping is one tissue among several — FACIS and OpenNebula bring their own. fed8ra's clearing takes any party's measured usage that arrives with a verifiable head: a NEO edge's seal, a FACIS DCS Merkle head over HTTPS, the carrying marketplace's signed statement. A party without a NEO edge still clears.
fed8ra nets every member's position from the measurements both sides booked. The month on OpenNebula shows what netting through one body saves against settling pair by pair.
The clearing produces positions; an invoice and a payment are separate acts on a bank rail, by the marketplace's billing. The books count in CLU; money is euro. All three are shown apart, always.
The core attests and never decides, owns or settles. fed8ra clears and rules as the members' body, by rules they ratified, and every ruling and every clearing comes back as a new record — the book it settles is never edited.
The federation's 122 members as twins on the rail for a month — 92 deals in a day, one breach, ten rulings, the month cleared. The twin — its live page follows from 15 October.
The month: cotrugli.tech/demo/8ra/month/ — three providers, one customer, nine services, 31 records in four books; the figures above are its pack's (month-pack.json, settlement claims 10). The Guardians' fee and the members' shares are the body's to set; this historical example does not set resource prices.
A new fed8ra pilot demonstration: five members exchange compute, AI, data and network resources. Multilateral netting turns 300 million CLU of gross obligations into €40 million for four providers.
Reciprocal use and a three-member resource cycle cancel before settlement. Each provider keeps its net entitlement.
NEO Chamber Book connects the mandate, agreement, acceptance, allocation and simulator outcomes. Inspect the signed snapshot and recompute the netting.
GnuCOBOL provides the recorded calculation in integer cents with explicit rounding rules — a familiar technical component for banking audiences.
Explore resource netting ▸Inspect the evidence ▸
Separate synthetic scenario. Illustrative conversion: 1 CLU = €0.50. Four simulated settlements; no bank transfer or new NEO attestation. The percentage describes settlement volume, not resource-price savings. The original OpenNebula month above is unchanged.
Two owner books, the shared rail and the Chamber’s own small book. A decision returns through the same edge path and is checked by both parties.
The bounded qualification uses three operator-owned synthetic edges: an Ambiti8n 5 case first, then a FED8RA case using the same existing callbacks. Read the dated result and the exact checks. The scripted LAB decision is not human business approval or a payable award.
Inspect the shared process and results ▸
Separate from the scored ten-day fleet. No historical verdict is replaced. Partner onboarding, host activation and real reviewer authority remain explicit prerequisites; no payment or live revenue allocation is claimed.
The pilot explores cooperation between European providers and a record of where services run, who authorises their use and how contributions are settled. Service availability, data-residency commitments and customer assurances would need to be established for each production offering.
122 entries by country from the pilot roster. The roster is a reference map, not a list of onboarded customers or a certification of service readiness. The evidence demonstrations show technical records; production assurance is further work.
Publish and subscribe through kcp's APIExport and APIBinding; the pilot's four real edges live on the Telemach cluster since 29 September; the flow with its 32 booked events. The flow · the pilot, live.
Nine services across three provider clusters, one rule — German data stays in Germany — a host failure survived, the month settled from the records alone. The month.
Its own connective tissue meets fed8ra at the seam: a DCS Merkle head (ADR-16) over HTTPS is a verifiable head the clearing accepts. The door is open; the trail is the next round.
Every marketplace and initiative of the federation enters with the modules it accepts — its catalog in a future portal, its orders on its own door, its measurements in the clearing.