Skip to content

Index of models

Mechanisms, with the maths attached

Seven models I maintain or co-authored. Two run in the browser on this page; the rest live in cadCAD notebooks or in the rSpace substrate.

Simulation work is done in cadCAD, the open modelling framework built at BlockScience. Implementations that run inside rSpace are TypeScript, tested against the same relations.

M1

Conviction voting

How long does support have to be held, by how many people, before a request of a given size is funded?

Each supporter has a conviction that grows toward a ceiling while support is held and decays once it is withdrawn. Total credit for a proposal aggregates supporters by square root, so a hundred small supporters count for more than one large one. The threshold a proposal must clear scales with the size of what it asks for, which is what keeps a small ask cheap and a treasury-draining ask expensive.

The parameter that matters is the half-life. It sets how quickly the system can change its mind, and choosing it is a governance decision rather than a technical one: fast enough to correct a mistake, slow enough that the treasury is not steered by a bad week.

Relations

c_i(t+1) = α · c_i(t) + s_i(t),   α = (1/2)^(Δt / halfLife)
c_i* = s_i / (1 − α)              steady state under constant support
C(t) = Σ_i √c_i(t)                sybil-resistant aggregation
threshold(F, Δ) = base · (1 + |Δ| / scale)
Runs on
cadCAD (Python) for the original release; TypeScript in rSpace for the live substrate
Day0
your tokens220 / 300

Keep the wiki archive online for a year

asks 2% of pool · threshold 617
0
120 you · 90 others

Six months of contributor stipends

asks 8% of pool · threshold 1,389
0
100 you · 140 others

Buy the building outright

asks 15% of pool · threshold 8,000
0unreachable
0 you · 60 others
Decay
0.90

conviction half-life ≈ 6.6 days

c(t+1) = α·c(t) + stake
max    = stake / (1 − α)
thresh = ρ·S / (1−α) / (β − r/f)²

Move a slider and watch what doesn’t happen. Support has to be held, so buying influence the day before a vote buys nothing — there is no vote to be the day before.

Pull your stake off a proposal and its conviction bleeds away at the half-life above. Attention is the cost.

The third proposal asks for 15% of the pool against a β of 20%. Its threshold is roughly 13× the first proposal’s for 8× the money. Large asks get expensive faster than they get large.

M2

Osmotic governance

What happens to voting power when delegation is partial, continuous, domain-specific and capped?

Delegated weight is treated as a solute crossing membranes rather than a proxy handed over whole. Weight flows along edges of the community graph, transitively, and only within the domain it was given for, so trusting someone on infrastructure does not hand them your say on grants. Streams are continuous: weight accrues per millisecond rather than in discrete grants.

Viscosity is the same conviction half-life used for funding, which is what makes the two mechanisms one system instead of two. A concentration cap limits any member's share of total power, and the model reports concentration each tick as a health signal — if power is pooling, you can see it happening rather than discovering it at a vote.

Relations

weight flows down the delegation gradient, per domain
viscosity = conviction half-life (response time of the graph)
concentration(G) ≤ cap   anti-plutocracy invariant
Runs on
TypeScript — the osmotic governance module in rSpace, with the governance router
M3

Augmented bonding curve

How much of a community's inflow can be diverted to shared work before joining stops being worth it?

Tokens are minted and burned against a reserve along a published price function, so supply absorbs part of any demand shock instead of price taking all of it. A tribute on each purchase is routed to a common pool the community governs, and an exit tax on sales makes short-term round-tripping unprofitable.

The design question is the split. Too small a tribute and the commons is not funded; too large and nobody joins. The model exists so that argument can be had over a curve rather than over opinions.

Relations

price = f(supply),  reserve = ∫ f  (invariant against mint and burn)
tribute θ of each buy → common pool
exit tax on sells → reserve retained by remaining holders
Runs on
cadCAD, with the interactive version on this site
fixed supply · 16.0× (off scale)1.84× price0pricetoken supply →reserve
US$300,000
2.0

price moves as reserve^(1−1/κ) — lower κ is flatter

20%

share of each buy routed to the common pool

State
Price
$1.84

1.84× open

Token supply
368,782
Reserve
US$340,000

redeemable at any time

Common pool
US$60,000

funds the commons, not the exit

Same capital, fixed supply
Price
$16.00

16.00× open

The same US$300,000 moves a fixed-supply market 8.7× further. When supply can't respond, price absorbs everything — which is the volatility, and the incentive to exit early.

M4

Flow funding (rFlows)

Where does money actually go when funding is modelled as a flow with conservation enforced at every step?

Funding is drawn as sources, funnels and outcomes on a canvas. Each tick, the simulator moves value along the graph and checks that everything in equals everything out — a funnel that fills past its overflow threshold spills to the next one down rather than quietly absorbing the difference.

Drain rates and overflow thresholds are the policy, and changing them is itself a proposal gated by conviction, so nobody adjusts the shape of the flow unilaterally. Outcomes settle against attestations rather than self-reporting. It is flow funding in the old sense — money passed onward by the people closest to the need — with the accounting made explicit.

Relations

Σ inflow = Σ outflow + Σ Δstorage   (checked every tick)
funnel spills when fill > overflowThreshold
rate changes require conviction ≥ threshold(Δ)
Runs on
TypeScript — modules/rflows in rSpace, with a conservation auditor in the test suite
M5

The issuance spectrum

Can cash, debt, equity, mutual credit, prediction shares, options, insurance and reputation be minted by one layer?

Instead of treating each financial instrument as its own product, this models them as coordinates in a basis-axis space: eight curves — par, residual, contingent-binary, mutual credit, bonding, LMSR, parimutuel, scalar — composed with a set of morphs, and settled by attestation engines ranging from a peer signature to a zero-knowledge ring proof.

A route planner finds multi-hop paths across the space, so a claim denominated in one instrument can be settled through another, and a conservation auditor checks the books afterwards. The point is not financial novelty. It is that a community should be able to issue the instrument its situation calls for without adopting a different platform each time.

Runs on
TypeScript — the issuance and settlement modules in rSpace, exposed over HTTP and to agents
M6

Holonic data interoperability

What has to be true for a peer to render a kind of document it has never seen before?

Every item is a small content-addressed document — a holon — that can carry a reference to its own definition. When a peer receives a kind it does not recognise, it resolves that definition and installs what it needs to interpret the thing, rather than falling back to a generic placeholder. Ceptr stated this as a requirement years ago; closing the loop is mostly a matter of refusing to special-case any one document type.

The structural payoff is that dozens of unlike collections reduce to one store plus an axis, links and a lens: order is a position on an axis, relations are edges rather than tables, and a view is a projection. Time, geography, capability and identity are all just axes. That is what makes exit credible — your data is not shaped by the application that happened to create it.

Runs on
TypeScript — the holon and substrate modules in rSpace; content-addressed storage over IPFS or R2
M7

Living Waters supply model

Can five towns be supplied by a distributed system with storage and redundancy, instead of one 57 km pipe?

Four strategies drawn from how a forest handles drought — local collection, subsurface storage, living filtration and a network that can flow in either direction — sized against the demand the Georgian Bay pipeline was scoped to meet. Each strategy has a working precedent and a named pilot site, and the permitting path stays inside Ontario's existing framework.

The model is a supply-and-buffer balance rather than a hydraulic simulation: what each strategy contributes, what it costs, and how much of the shortfall remains. It won the 2026 Biomimicry Commons B-Prize, which funds the next stage of it.

Runs on
In the browser on this site, against published figures
ALLISTON SAND PLAIN · seasonal storageGeorgian BayCollingwood0 kmStayner18 kmAngus38 kmAlliston57 km
Four integrated strategies
  • Modular ultrafiltration + UV trains at existing well sites in Stayner, Angus and Alliston, 4,500–9,000 m³/d each. Like every tree relying on its own root system: an intake icing event or algae bloom at one site stops cascading across five communities.

    Capacity
    13,500–27,000 m³/d
    Pilot
    $3.5–5.6M
    Angus — 1,500 m³/d UF+UV
Against the 2031 gap
13,500m³/day

of 27,000 m³/day needed

02031 gap · 27,000

13,500 m³/day residual — covered by retaining partial capacity at the Collingwood plant rather than the full $270M build.

Supply paths
N = 4
Cost to prove it
$3.5–5.6M
Full corridor
Centralised expansion$270M
Living Waters build$118–170M
Saved$100–150M · 37–56%

The centralised proposal went from $121M to $270M in eighteen months. Levelised cost of water lands roughly 40% lower distributed, at $5.5K per m³/d of capex against $10K centralised.