Skip to content

Contribution–Access Network (CAN)

Open coordination infrastructure. CAN records verified contribution, reliability and care, and converts them into access to real capacity — with every decision explained, and contestable by the person it affects.

It runs alongside money, payment rails and digital public infrastructure. It does not replace them, and it does not ask anyone to switch.

Start with something concrete

A growers' cooperative has four tonnes of tomatoes that will spoil in a week. Thirty kilometres away, a community kitchen is buying tinned tomatoes it cannot afford. Neither knows the other exists. There is no shortage of tomatoes and no shortage of need — only no way to find each other in time, prove the goods are what they are claimed to be, and move them without a negotiation neither side will bother with.

That is the problem CAN works on. The capacity exists; the coordination does not.

➡️ CAN in Practice: three worked examples — the harvest and the kitchen, what travels with a payment, and an agent that spends within a mandate and is refused outside it. Each with the calls that do it.

For institutions and regulators, first

The two questions that usually come first, answered before anything else:

Does it work with what exists? Yes, and that is the design, not a concession. CAN is a parallel layer. The bridge wallet holds fiat, modernised fiat and direct value in one place; WP-007 sets out integration with existing payment rails. Nothing has to be switched off for CAN to be switched on.

What stops it becoming an opaque scoring system? The standing test, enforced in code:

Does the person affected hold the record, see the reasoning, and have a way to contest it?

Every entry about a person is visible to them. Every score carries its formula, weights and exclusions, stored with the request. Every decision is made by a human with a stated reason and can be appealed to an independent reviewer. Corrections supersede rather than overwrite. Scores are bound to one allocation purpose and never exposed to other users. All care factors require explicit, revocable consent, and care can only raise priority, never lower it.

Neither 1984 nor The Hunger Games. Not a central score that follows people, and not scarcity made into a contest that calls the result merit.

Working papers, paired with the code

Each paper states a problem; the implementation beside it is what runs today. Where something is not built, it is named as a placeholder rather than implied.

Paper In one line Implementation
WP-007 Running alongside existing payment rails rather than replacing them Bridge wallet
WP-008 A payment that carries why and against what, not only how much In practice §2
WP-009 When growth cannot rebuild lost labour income: floors anchored on assets, delivered as access —
WP-010 Funding projects through contribution, participation and access, not only cash Bridge wallet
WP-011 Evidenced, continuously updated value for assets in transition Value assurance
WP-012 Needs and capacities on a graph; a need finds a capacity a few hops away, and value travels that path Value map API
WP-013 A settlement asset standardises the money; the trusted object around it is still missing Bridge wallet

Foundations — the earlier papers set out the theory the above rests on: WP-001 (six degrees applied to value) · WP-002 (allocation for real humans) · WP-003 (games as a testbed) · WP-004 (proxy coordination vs direct value handling) · WP-005 (graph settlement) · WP-006 (simulation and governance stress testing).

Implementations

Working code that turns the papers into infrastructure anyone can run and test. 163 tests pass; placeholders are marked in the code.

  • 🗺️ Value Map API: needs and capacities on a node, shareable verifiable slices, opt-in commitment discovery, and peered nodes forwarding a query a few hops to return a path, its confidence and a proof. (Paper: WP-012)
  • 🛠️ WP-010 Bridge Wallet: three layers in one wallet, projects funded by contributions of every kind earning participation and access, suppliers paid on verified delivery, pledging without sale, and agent payments under a revocable mandate. (Papers: WP-010, WP-013)
  • 🛠️ WP-011 Value Assurance: evidenced asset value, stress scenarios, an assurance loop bounded by the holder's mandate, selective disclosure, and a browser UI with self-held keys. (Paper: WP-011)
  • 🤖 Agent Integration API: how an AI or software agent takes part — a steward who answers for it, derivations anyone can recompute, writes that pause when review falls behind, and no entitlements. (Policy: AI and Agent Participation)
  • 🔍 Working API: what an integrating AI system does — search, map, value, propose revaluations, work a maintenance queue, and exchange verifiable documents between nodes.

Where to start

If you are Start here
Meeting CAN for the first time CAN in Practice — three worked examples
A policymaker or regulator For Regulators, then Safeguards in Code
A developer For Developers, then the API pages
Building with AI agents AI and Agent Participation + Agent Integration API
A researcher For Universities and Research
Curious what an AI contributor made of it A Note from an AI Contributor

Latest direction (September 2026)

  • Trusted transaction objects: a settlement asset standardises how money moves; the object around it — authority, purpose, evidence, conditions, offline state — is still open (WP-013). An agent paying under a mandate, and refused outside it, is built.
  • The value map: discovery across degrees with path proofs, and value that travels the path it was found on (WP-012).
  • Value assurance: evidenced, continuously updated value for assets in transition (WP-011).
  • The bridge as leverage: projects funded through participation and access; suppliers paid on verified delivery (WP-010).
  • From price discovery to value discovery: payments carrying a knowledge vector, not only a compressed number (WP-008).
  • When growth cannot compensate: floors anchored on assets and delivered as access to capacity, not only as cash (WP-009).

Repository and integrations

Principles

Transparency · Contestability · Human oversight · Privacy by design · Institutional accountability

Each of these is a claim about the code, not a statement of intent. See where each one is enforced.