Favour Bucks Manifesto

Abstract

What this document is, and isn't.

This manifesto makes the public case for Favour Bucks — a way to make favours visible, witnessed, accountable, and durable without turning ordinary mutual help into another extractive platform.

The protocol is built around a single atomic unit: the Logistic — an origin, a destination, a time constraint, and a Rider specifying what skills, capital, equipment, and willingness are needed to complete it. Everything else in the system, from a bag of frozen breastmilk hand-delivered to a struggling mother to a coordinated global response to a regional flood, composes from Logistics.

This is not a crypto whitepaper. There is no pre-mine, no speculative token, no promise of price appreciation. The FavourBuck is designed as accounting for mobilised human capacity, not a store of value. Its defining property is that it carries no compound interest — by structural choice, not regulatory accident. At launch, FavourBucks are seeded by real capital. At scale, borrowed favour credit becomes real FavourBucks only when the recipient gives verified value back to the network.

The system is designed to be, in order of priority: safe for the people who use it, useful for the communities who build it, defensible under the regulatory regimes of the jurisdictions it operates in, and durable against the failure modes that have ended every prior attempt at a favour economy.

This document exists to be read closely by the people who will build, fund, operate, regulate, and participate in the system — and to serve as the canonical reference against which all subsequent implementations, pages, use-case documents, and community protocols are measured.

PART I

First Principles

What a favour is. Why the existing economy cannot price it. And why that failure matters.

§ 1.1

What a favour is.

A favour is a transfer of value between people that the market cannot efficiently price. It may carry a cash-equivalent somewhere inside it — an hour of labour, a litre of milk, a ride across town — but its defining property is that the act of giving is part of what is being given. A paid courier delivering frozen milk is performing a service. A friend-of-a-friend making the same delivery, at the same hour, in the same car, is performing a favour. The milk is identical. The delivery is identical. What differs is the social fact.

This is not sentimentality. It is an observation with structural consequences. Favours carry information about relationship, trust, and availability that cash transactions strip out. In a functioning society, most of the coordination that keeps daily life running — childcare swaps, airport pickups, hand-me-down equipment, neighbour-on-neighbour help — happens through favours, not through priced exchanges. When these systems break down, the result is not that cash transactions expand to fill the gap. The result is that the coordination stops happening at all, and people suffer in ways that no amount of money can buy them out of.

Favour, n.

A voluntary transfer of capability, time, skill, material, or capital from one party to another or from a group to a party, carried out under social rather than purely commercial terms, and generating a record of relationship that outlasts the transaction itself.

Every human society has had favour networks. What varies is whether those networks are formalised — and if so, how.

§ 1.2

The mobilisation gap.

At any given moment in any modern city there exists an enormous reservoir of latent capacity: people with spare time, unused equipment, underutilised skills, and small amounts of discretionary capital who would willingly contribute to a worthwhile favour if the right one were offered to them on the right terms. And at the same moment, there exists a parallel reservoir of unmet need: people who require a very specific favour — breastmilk, a ride, a trade skill, coordinated help — and cannot find it within their immediate network.

These two reservoirs are close to each other, physically and socially. They are separated by a failure of mobilisation. The market does not match them because the transactions are too small, too specific, too context-dependent, or too freighted with social meaning to be priced efficiently. Charity does not match them because the coordination overhead is too high for any individual act. Friendship networks do not match them because the relevant parties are friends-of-friends-of-friends, and the social graph does not reach.

Favour Bucks exists to close this gap. It is not a charity, though it shares some properties with one. It is not a marketplace, though it has some market mechanics. It is a coordination protocol for mobilising favour capacity at scales that exceed any individual's social graph.

The gap between those who need and those who can give has always been the system. We are building a different system.

§ 1.3

The Logistic — the atomic unit.

The protocol is built around a single primitive: the Logistic. A Logistic is the smallest well-formed unit of favour activity. It can be composed into larger favours; it can be decomposed into its constituent elements; but it cannot be meaningfully reduced further without losing the thing that makes it operable.

Logistic, n.

A proposed transfer defined by four elements: an Origin (where the transfer begins), a Destination (where it completes), a Time constraint (when it must happen), and a Rider (the full specification of what capabilities, skills, equipment, capital, and willingness are required to fulfil it).

The Rider is the most important of the four elements, and the most easily misunderstood. It is not a person. It is the specification — the "spec sheet" attached to the Logistic that says, in effect: to fulfil this favour, the network requires someone with these capabilities, in this place, at this time, with this equipment, willing to do this work. The Rider is how the protocol expresses what a favour actually needs. A matching engine then finds the people (the Surfaces) whose capabilities intersect the Rider's requirements.

A breastmilk delivery is a Logistic: origin is the donor's freezer, destination is the recipient's freezer, time is "within six hours of donor's availability," Rider specifies "insulated transport, discretion, willingness to handle human bodily fluid, no known illness, brief verbal confirmation on delivery." A barn-raising is a stack of Logistics: dozens of small origin-to-destination transfers (tools, lumber, bodies, meals, coordination) converging on a shared destination under a shared time window, each with its own Rider. A co-ordinated disaster response is thousands of Logistics composed in real time.

Every favour in the network — from a cup of sugar to a continental disaster response — composes from Logistics of this form.

The four-element structure is deliberately minimal. It is sufficient to describe any transfer, it is computable, and it maps cleanly onto both digital matching and physical routing. The Rider does the heavy lifting: by making the requirements explicit, it lets the network find candidates algorithmically, and it lets humans assess whether a given favour is within their means before they commit.

§ 1.4

The Surface Layer.

If the Logistic is the unit of demand, the Surface is the unit of supply. A Surface is the intersection of a willing person, their available time, their skills, their capital, and their location — one thin slice of useful work, published to the network in a form the matching engine can reason about.

Surface, n.

A machine-readable declaration of a person's availability to contribute to favours, consisting of willingness (what kinds of favours they will do), time (when they are available), skills (what they can do well), capital (what material resources they can contribute), and location (where they can do it from). A Surface is valid for a declared window; expired Surfaces are not matched.

No single Surface is sufficient to fulfil a non-trivial favour. A ride to the airport might require one Surface (a driver with a car and two free hours). A breastmilk delivery requires at least two (a donor and a transporter). A community response to a flooded basement might require fifteen (bodies, pumps, trucks, coordination, food, childcare-for-the-responders). The protocol's matching engine stacks Surfaces — finding combinations that jointly satisfy a Rider — and this stacking is the system's most distinctive capability.

Traditional labour markets match one worker to one job. Traditional charities match one volunteer to one task. Favour Bucks matches compositions of people to compositions of need. Most of what communities actually require is the latter, and most of what existing systems fail to deliver is the latter, and this is why most favour-like attempts at coordination fail: they treat favours as one-to-one transactions when favours are intrinsically many-to-one or many-to-many.

Three Surfaces — donor, transporter, coordinator — stack to satisfy a single Logistic. No participant could have completed the favour alone.

A person with a broad declared Surface — many skills, wide availability, generous willingness — participates in many Logistics and accumulates reputation quickly. A person with a narrow Surface participates in fewer but often more specialised Logistics. Both are valuable. The network prizes accuracy of Surface declaration above breadth: a narrow Surface that reliably delivers is worth more than a broad one that over-promises, because the protocol's value depends on the honesty of its availability signals. This design choice is load-bearing, and we return to it in §2.6.

§ 1.5

The Group.

Above the individual Surface sits the Group — a formal collective of members who pool a small share of every favour they transact to build shared wealth, shared assets, and shared protection. A Group can be a neighbourhood, a trade guild, a friend circle, a religious community, or a family. Its only requirement is that its members choose to be accounted together.

Group, n.

A collective of Favour Bucks members who pool a defined percentage of their transaction flow into a shared fund, used to acquire shared assets, underwrite mutual insurance, issue need-based grants or earned rebates, and fund Group-scale favours that exceed any individual member's capacity.

The Group is the structural answer to the oldest failure mode of mutual-aid economies: the burnout of high-contributors. In a pure peer-to-peer favour network, the 10% of participants who give most end up subsidising the other 90%, and eventually leave. In a Group-mediated network, individual contributions aggregate into collective capacity, so no single giver carries a disproportionate load, and every contribution visibly builds the common wealth of a community the giver is part of.

Groups are also the structural answer to the problem of favour scale. Most genuinely transformational favours — a community garden, a shared vehicle, mutual childcare, a disaster-response reserve, a cooperative tool library — exceed any individual's willingness or capacity. The Group is how the protocol expresses favours from a collective to its members, and from one collective to another. When the protocol says "mobilisation," this is most of what it means.

01 · SHARED ASSETS

Own together.

Tools, vehicles, equipment, spaces — held by the Group, used by members at cost, maintained from the common fund. Private ownership of rarely-used capital is a waste the Group architecturally prevents.

02 · MUTUAL INSURANCE

Underwrite together.

Child insurance, elder care, disability protection — underwritten by the Group's own reserve, paid out by the Group's own decision, at scales that make commercial insurance unnecessary for most events.

03 · EARNED REBATES

Earn together.

When the Group receives favour-payments or earns value from shared assets, surplus returns through earned rebates, grants, reserves, or new shared assets. Participation builds resilience without turning membership into passive yield.

Groups vary widely in size, focus, and governance. A street-block Group might have 25 members and a fund of a few thousand FavourBucks. A trade-guild Group might span a city, a region, or a continent. The protocol imposes no upper limit on membership or scope; it only requires that Groups be legally constituted entities (a co-operative, a charity, or an equivalent vehicle in the relevant jurisdiction) so that their fund can be held, accounted, and audited. See §4 for the regulatory structure.

A Group of friends. A city block. A trade collective. Any size. Any focus. Permanently owned by its members.

PART II

The Protocol

FavourBucks, escrow, pricing, reputation, and the mechanics that make the system self-consistent.

§ 2.1

FavourBucks.

The FavourBuck (FB) is the protocol's native unit of account. It is designed explicitly and exclusively as a medium of exchange for mobilising favours. It is not a store of value, not a speculative asset, and not a currency in the sovereign sense.

The defining design choice — the one that distinguishes FavourBucks from every speculative token and most local currencies that have preceded them — is that the FavourBuck carries no compound interest, ever. This is not a default setting that can be changed. It is a structural property of the protocol. Balances do not grow by being held. They grow by cash-primed acquisition, by receiving settled credit for witnessed useful work, or by converting provisional favour credit through reciprocal work.

· Design Principle ·

No compound interest. Provisional favour credit is an obligation to give value back, not a compounding debt product. Compound interest is the mechanism by which currency creates economic asymmetry over time. The FavourBuck refuses it by construction.

This choice has consequences. It means the FavourBuck is a poor vehicle for saving in the conventional sense — holding FBs does not make you richer, it only preserves the ability to request future favours. It means the protocol cannot offer yield to depositors, which rules out a large class of financial-product integrations. And it means hoarding is systemically discouraged without any need for demurrage: in a world where held FBs do not grow while the cash economy around them does, the rational actor spends FBs on favours rather than sitting on them.

The FavourBuck is, in this sense, an intentionally limited currency. Its power comes from what it refuses to do. It refuses to reward accumulation, refuses to carry compounding debt forward through generations, and refuses to accrue value while its holder sleeps. What it offers in exchange is liquidity of mobilisation — the ability to move human capacity quickly, at scale, without the distortions that compound finance introduces into every other measurement of value.

§ 2.2

Credit and circulation.

FavourBucks enter circulation in phases. The launch phase is cash-primed issuance, in which real capital seeds the system and flows into charitable escrow (§2.3) as reserve against FBs in circulation. The mature phase is reciprocal work conversion: a participant may receive a favour on provisional credit, but that credit becomes real FavourBucks only when the participant later completes verified useful work for someone else.

Cash-primed issuance. A user pays cash into the system and receives FBs at the published rate. The cash flows to the charitable escrow. New FBs are created in the user's account. The system's reserve and float both grow by the same amount. This path exists primarily to solve cold-start — new users need FBs immediately, before they have done any favours — and to fund Group favours requiring purchased materials.
Provisional favour credit. A user may request a favour before they hold enough FB. If the favour is accepted and witnessed, the recipient carries a bounded provisional credit obligation. The system has recorded value received, but has not yet treated that credit as permanent currency.
Reciprocal work conversion. When the recipient later completes a verified favour for another participant, the provisional credit is converted into real FB settlement. In plain language: you may receive before you give, but the currency becomes real when you give back.
Future regulated liquidity. Transfers, redemption, or cash-out are not launch mechanics. They require legal opinion, reserve policy, KYC thresholds, and a regulated boundary before they can exist safely. Until then, FavourBucks function as network accounting for useful work, not as a public cash-equivalent market.

Both issuance paths are bounded. Cash-primed issuance is bounded by the reserve policy — the charity does not issue more FBs than its reserves can notionally support, though the ratio is managed to allow reasonable expansion. Reciprocal work conversion is bounded by the witness layer, participant reputation, Group standing, and the requirement that provisional credit closes through value added back to the network. The system does not settle permanent FB merely because someone consumed a favour.

Capital seeds the reserve; borrowed favours create provisional credit; reciprocal verified work converts credit into real FavourBucks.

§ 2.3

The Escrow model.

Every FavourBuck transaction in the system flows through a charitable escrow. The escrow holds the funds for an instant — long enough to verify, split, and route — and then releases them. It is not a bank, in the sense that it does not lend, does not pay yield, and does not leverage deposits. It is a protocol-level clearinghouse whose sole job is to ensure that every transaction is properly split, properly recorded, and properly settled.

The standard split for recorded Favour Bucks transactions is 98% to the doer, 1% to the system, 1% to the doer's Group.

98% to the doer. The party who performed the favour receives 98% of the agreed price, denominated in FavourBucks, settled to their account when the witness layer closes the Logistic.
1% to the system. The protocol's operating cost — hosting, engineering, audit, dispute resolution, compliance work, offline receipts, mesh readiness, and mapping — is funded from a 1% fee on every recorded transaction.
1% to the Group. The doer's declared Group receives 1%, which builds shared assets, protection, grants, earned rebates, and reserves. Members who are not part of a Group have this 1% directed to a regional mutual-aid pool by default, which they can later redirect to a Group they join.

The 1%+1% friction is deliberately small. The protocol aims to be roughly an order of magnitude cheaper than conventional payment rails (which typically take 2-4% per transaction in fees alone, before currency conversion, cross-border surcharges, and platform margins). The small margin is viable because the protocol runs as a charity, not a shareholder-owned corporation, and does not need to generate returns for external capital.

· The Cash Corridor ·

Private or cash-side arrangements are not the core settlement path. Privacy is legitimate; evasion is not the goal. If the protocol later supports declared private settlement, it must still contribute to system and Group costs through a transparent policy. The exact surcharge, disclosure level, and compliance treatment remain open design questions, not constitutional rules.

The escrow is legally and operationally separate from the protocol's development entity. It is held by a registered charitable organisation whose purpose, governance, and fiduciary duties are scoped to the operation of Favour Bucks escrow and nothing else. The separation exists to protect the reserve from operational risk (the charity's assets are not the engineering team's, and vice versa) and to establish a clean governance boundary — the charity's board answers to its members and its regulator, not to the engineering team.

§ 2.4

Recorded and declared-private settlement.

The protocol distinguishes between recorded transactions (entered into the ledger, visible at the appropriate privacy level, subject to the standard 1%+1% split) and declared-private transactions (acknowledged by the parties with limited disclosure). Both may be legitimate. They serve different purposes.

Recorded transactions are the default and should be the overwhelming majority of system activity. They support reputation, audit, dispute resolution, provisional credit, reciprocal work conversion, Group funding, and learning. They are what lets the system see itself without pretending every detail must be public.

Declared-private settlement exists for cases where visibility would create unnecessary risk: a sensitive family matter, a delicate professional situation, a vulnerable-person interaction, or a jurisdictional concern. The policy has to balance privacy, safety, tax compliance, and the commons. A surcharge or contribution may be appropriate, but the exact number belongs in policy after legal review, not in the core constitution.

Recorded default. The protocol's UI, matching engine, witness layer, and reputation layer assume recorded settlement unless a private path is explicitly selected.
Private as exception. Declared-private settlement requires explicit election, mutual consent, safety review where needed, and a transparent contribution policy once legally settled.
Private but not evasive. The protocol does not build tax evasion or legal evasion into the system. Fully unreported cash arrangements are outside the protocol, not a protected protocol mode.

· A Societal Imperative ·

Every economy has grey activity. Favour Bucks acknowledges this reality without making opacity the economically dominant path. Recorded settlement is cheapest, clearest, and best for the commons. Declared-private settlement is a narrow safety valve. Fully unreported cash activity is the old system, not ours.

§ 2.5

Pricing and negotiation.

Pricing in Favour Bucks is negotiated. The protocol does not set prices. It provides the infrastructure by which buyers and sellers can propose, counter, accept, or walk away from terms. In practice this produces three distinct patterns of price discovery, which the system supports natively.

Standard favours. For common, well-defined favour types (a ride to the airport, an hour of yard work, a delivery within a given radius), the protocol publishes reference prices derived from the moving median of recent completed transactions of the same type. These are not enforced prices — they are informational anchors that reduce negotiation overhead for routine favours.
Bespoke favours. For specific, situational, or unusual favours (the breastmilk case is bespoke), the seller posts an offer and the buyer responds. Either party may counter. A contract forms when both agree. The price is whatever the parties settle on, recorded in the ledger at the appropriate privacy level.
Group-funded favours. For large favours exceeding any individual's capacity, the system supports aggregate funding: many members contribute small amounts of FBs (or commit Surfaces) toward a proposed group favour, and the favour activates when the threshold is met. This is how the protocol expresses things like community tool purchases, disaster-response reserves, or scholarships.

The philosophical point: no party has privileged pricing power. The seller posts; the buyer decides by accepting, countering, or walking; both may negotiate. Price emerges from the meeting of offer and decision, which is the correct decentralised posture for a protocol that refuses to become an intermediary with an opinion about value.

No one dictates the price of a favour. Price emerges from the meeting of offer and decision.

§ 2.6

Reputation and availability.

Reputation is the protocol's primary non-monetary incentive. It is how the system distinguishes trustworthy participants from opportunistic ones, how it routes Riders to the Surfaces most likely to fulfil them, and how it gates access to higher-stakes favours. Because FavourBucks do not grow through accumulation, reputation is the quantity participants are incentivised to build.

Reputation is earned through:

Honoured availability. When a participant declares a Surface — "I am available for these kinds of favours, at these times, in this area" — and the network calls on them within that declaration, and they deliver, their reputation grows. When they decline or fail to deliver within a declared window, their reputation is reduced. This is the single most important reputation signal, because it measures the one thing the network most needs to know: can this declaration be trusted.
Accurate pricing. Participants whose favours complete at close to their proposed price, without renegotiation or dispute, earn reputation faster. Participants whose completions routinely differ from their proposals (up or down) earn more slowly.
Witness closures. Favours that close cleanly — all parties confirm completion, no dispute is raised — contribute to reputation. Favours that close with disputes, even if resolved in the participant's favour, contribute less.
Group standing. Members whose Groups endorse them (via Group vote or delegated reputation bond) inherit a portion of their Group's accumulated standing. This lets established Groups vouch for new members, accelerating onboarding.

Availability deserves its own treatment, because it is the mechanic that makes the protocol's mobilisation claims credible. A participant can be paid (in FBs) to declare availability — a "standby Surface" — in exchange for agreeing to be reachable within a stated window. If called on during that window for a favour within the scope of their declaration, they must either fulfil it or release the Surface with sufficient notice that the network can route to someone else.

Failure to honour a declared availability is the protocol's most serious reputation event. The design principle is simple and strong: if you were paid to be available and you weren't, you weren't actually available. The FBs earned against that declaration are clawed back — not as a penalty layered on top of the system, but as a correction to a record that was false. A participant who repeatedly over-declares availability and under-delivers loses, disproportionately, the FBs they earned from those declarations.

· The Availability Principle ·

Under-promise, over-deliver. The protocol rewards accurate declarations and punishes over-declaration more than under-declaration. A participant who claims availability for half the time they can actually cover, and delivers reliably within that window, accumulates reputation faster than one who claims availability for all their time and fails occasionally. This asymmetry is what makes the network's mobilisation capacity a truthful signal.

A crucial refinement: availability clawbacks are proportional to notice. A participant who declares availability for a month and fails on day two loses the FBs corresponding to the portion of the month they falsely claimed. A participant who updates their Surface to "unavailable" on day twenty, before any network call on them has occurred, forfeits only the days they declared but did not honour. This rewards honest updating of availability as much as initial accuracy, and it prevents the system from collapsing to short-horizon declarations only.

§ 2.7

The Witness layer.

A favour is not complete when one party says it is. A favour is complete when the network can verify — to an appropriate standard of proof for the favour's scale — that the agreed work was done. The Witness layer is the protocol's mechanism for this verification.

Different classes of favour require different classes of witness. The protocol defines four:

Self-witnessed. The lowest class. Small, low-stakes favours (small rides, minor errands, personal favours between known parties) close on a simple mutual confirmation between the two parties. The protocol takes the confirmation at face value; reputation systems handle any abuse.
Third-party witnessed. The middle class. Favours above a threshold value, or of a class where disputes are historically more common, require a third member of the network — the coordinator role — to confirm completion. The coordinator may be an individual member with sufficient reputation, or a Group representative.
Multi-party witnessed. Large or high-stakes favours — particularly group favours involving many Surfaces — require multiple witnesses, typically one per major Surface contributing to the favour. The protocol records the set of confirmations and closes the Logistic when a quorum of witnesses confirms.
Instrumentally witnessed. Favours with technical or safety implications may require instrumental verification in addition to human witness. A breastmilk delivery might call on a lab network node for a safety screen (see §3.4). A delivery of equipment might require a photographic confirmation. The instruments report to the Witness layer just as a human would.

The Witness layer is also the protocol's dispute-resolution substrate. A disputed favour is one where the witnesses disagree or where a party contests a closure. Disputes are resolved through a ladder: direct renegotiation between the parties first, Group arbitration second (if the parties share a Group or adjacent Groups), regional arbitration third (a small panel of high-reputation members), and charitable-entity arbitration only in the final case. Most disputes resolve at the first or second step; the system is designed to minimise the need for higher escalation.

PART III

Infrastructure Futures

How the network pays its contributors to build the substrate it runs on — and why early coverage is worth most.

§ 3.1

The mesh network.

Favour Bucks' matching, witnessing, and settlement functions can operate over the conventional internet. But the conventional internet is, by design, surveilled, centralised, rented, and fragile in ways that matter more as the protocol scales. A system whose purpose is to mobilise capacity when conventional systems fail cannot itself depend entirely on conventional systems.

The protocol's substrate is therefore a decentralised mesh network, built on Reticulum and compatible LoRa-class radio technology, operated by member-run nodes, and capable of carrying protocol traffic without any dependence on commercial internet infrastructure. The mesh is built incrementally, paid for out of system fees, and owned — in the most literal sense — by the people who run its nodes.

The Mesh, n.

Favour Bucks' native communications substrate. A federation of Reticulum-based mesh network nodes operated by member-participants, funded by the protocol's infrastructure budget, and used to carry favour-protocol traffic without dependence on commercial internet infrastructure. Operational offline, encrypted by default, censorship-resistant by design.

In practice, a node operator sets up a small radio node — a consumer-grade LoRa device, a Raspberry Pi with a radio hat, or a dedicated appliance — at their home, business, or another suitable location. The node joins the mesh, begins relaying packets for the network, and earns recurring FavourBucks proportional to its contribution. The contribution is measured by three quantities: coverage (how much previously-unserved geography this node reaches), reliability (uptime against declared availability), and traffic (how many packets the node relays for other members).

The mesh is not a commercial ISP replacement. Its throughput is low by consumer-internet standards — tens to hundreds of bits per second in the radio link layer, sufficient for favour-protocol messaging but not for video streaming or large file transfer. What it offers is not bandwidth but presence: a communications substrate that exists in places, times, and conditions where the conventional internet does not, and that belongs to its operators.

§ 3.2

The asymptotic payout curve.

The economic design of mesh compensation is the protocol's most carefully calibrated incentive structure. It must reward node operators sufficiently to motivate coverage in underserved areas, while avoiding the failure mode of rewarding redundant coverage in already-saturated areas. The design is an asymptotic per-node payout: the first node in a previously-uncovered area earns the most; the second, less; the third, less still; and the curve asymptotes toward zero as the area saturates.

Per-node reward as a function of local node count. Early operators in sparse areas earn most; saturated areas approach zero marginal reward.

A simplified mathematical form for the per-node reward is:

// Per-node reward R as a function of local node count n R(n) = R_max × reliability(node) / (1 + α × n) // Where: R_max = maximum reward for a first node in a coverage gap reliability = 0.0–1.0, based on uptime vs declared availability n = number of nodes currently covering this area α = saturation coefficient (tuned per region)

The reliability multiplier is critical. A first node in an uncovered area that claims availability but is offline half the time provides a false signal of coverage, which is worse than no node. The multiplier ensures that compensation tracks actual usefulness. Unreliable nodes see their rewards drop sharply, which naturally starves them out of the system — not as a penalty, but as the economic consequence of unreliability.

The saturation coefficient α is tuned by region to reflect local coverage needs. Dense urban areas saturate quickly (low α tolerates few nodes before rewards drop). Rural or disaster-prone areas saturate slowly (higher α rewards many nodes, because redundancy is valuable where infrastructure is fragile). The coefficient is set by the charity's infrastructure committee and published openly; it is an auditable parameter, not a proprietary secret.

The overall effect: the mesh grows toward coverage gaps. Node operators are economically motivated to set up in places with unmet need rather than to pile into already-served areas. Over time, the network fills in, reward-per-node asymptotes toward zero in saturated regions, and the system self-stabilises at a coverage level that reflects actual mobilisation demand.

§ 3.3

Pay to map.

Related to the mesh is the protocol's geographic substrate: a community-owned map of the world, built by members, updated continuously, and used by the matching engine to route Logistics efficiently. The Pay-to-Map programme compensates members in FavourBucks for contributing mapping data — streets, addresses, accessibility details, local landmarks, route times, seasonal variations, disaster-relevant geography — that improves the network's routing quality.

Mapping contributions are compensated on a per-area basis, with the same asymptotic curve as the mesh: the first accurate map of a given square kilometre earns most, and subsequent updates (corrections, refinements, seasonal data) earn smaller recurring amounts. As the map matures, the per-contribution reward approaches zero in well-mapped areas, and the economic incentive shifts to maintaining freshness and filling gaps.

The map produced by this programme is owned by the protocol's charitable entity and is available to members for routing at no additional cost. It is not licensed to external commercial parties, and it is not sold. It is a commons — built by members, for members — and its persistence is a direct function of member participation.

§ 3.4

Verification and lab networks.

Some favours carry technical, safety, or health-adjacent considerations that benefit from instrumental verification beyond what a human witness can provide. Breastmilk, as in Part V's worked example, can carry pathogens and medication traces that a visual inspection cannot detect. Home-preserved food can harbour botulism. Water from an unfamiliar well can carry heavy metals or coliforms. A favour involving transfer of such materials between parties who are not otherwise intimate benefits from — and sometimes requires — a small, fast, inexpensive verification step.

The protocol supports the development of a lab network: member-affiliated laboratories (a clinic, a university lab, a municipal testing facility, a certified home lab) that perform small-sample screens for favours that request or require them. A requesting party pays the lab fee in FBs; the lab returns a pass-or-flag result to the Witness layer; the favour either closes or is held pending resolution. Lab nodes, like mesh nodes, are compensated per result and accumulate reputation proportional to their accuracy and turnaround time.

The lab network is also the gateway for a broader capability the protocol anticipates: distributed citizen science and safety infrastructure. A community that can screen its own breastmilk shares, verify its own well water, test its own soil for lead, and confirm its own food preservation is a community with concrete material autonomy. This is a significant long-term capability, and Favour Bucks' lab-network primitives are designed to enable it.

· Health-Adjacent Favours ·

Favours involving bodily fluids, food, water, medications, or other substances with non-obvious safety profiles are marked in the protocol with a health-adjacent flag. The flag triggers an informed-consent checklist between parties (disclosure of relevant health history, medications, conditions) and may require routing the favour through a lab-network node before full settlement. The goal is not gatekeeping but informed participation.

§ 3.5

Group commons and insurance.

Returning to the Group structure introduced in §1.5: each Group holds a fund that accumulates from the 1% share of every member transaction, plus any additional contributions members choose to make. The fund is deployed by the Group's governance — members vote on allocations, with voting power proportional to contribution history — across three general categories.

Shared assets. The Group uses fund capital to acquire physical assets that members collectively use — a truck, a set of power tools, a laundry machine, a community kitchen, a van, a chainsaw collection, a commercial-grade espresso machine. Members book assets against the Group's calendar, pay a nominal use fee (in FBs) that funds maintenance, and the Group's per-member cost of capital drops dramatically relative to private ownership of rarely-used equipment.
Mutual insurance. The Group pools a reserve against predictable member-level catastrophes — child-raising costs, elder care, disability, emergency expenses — and pays out according to its own charter. Group Insurance also names responsibility before a favour runs: what is covered, what is excluded, who reviews an incident, and when the Group can decline a favour because the risk is not worth carrying. This is insurance at the scale where trust is possible; it is not a commercial insurance replacement for very-large-loss events.
Earned rebates. When the Group's fund generates surplus — through asset use fees, favour-matching work the Group performs, or productive deployments of its reserve — members can receive earned rebates tied to completed contribution and need. Passive dividends are avoided because passive membership must not become a compounding asset.

Groups are legally constituted. In Canadian practice this would typically be a registered co-operative corporation, a non-share capital corporation, or — for Groups operating within a larger registered charity — a sub-fund with defined governance. The protocol's central charitable entity supports Groups with templates, governance tooling, and audit infrastructure, but does not operate Groups directly. Each Group is self-governing, member-owned, and member-responsible.

A Group of friends. A city block. A trade collective. Ownership spreads, benefits multiply, and no one single member carries the load of the whole.

PART IV

Governance and Regulation

A protocol that intends to last must first be legal, then be legitimate, and only then be clever.

§ 4.1

The charity structure.

Favour Bucks is operated by a registered charitable organisation whose mission is explicitly and exclusively the mobilisation of favour capacity for public benefit. The charity holds the escrow reserve, issues and redeems FavourBucks, operates the matching and witness infrastructure, manages provisional-credit policy, funds mesh and mapping nodes through the infrastructure budget, and provides the governance and audit functions the protocol requires.

The choice of a charitable vehicle — rather than a for-profit corporation, a decentralised autonomous organisation with no legal personhood, or a loose federation of participants — is deliberate and foundational. It is the single most important structural decision the protocol makes, because it determines how every other question about governance, taxation, user protection, and durability gets answered.

Mission lock. A charity's governing documents bind it to its charitable purpose. Favour Bucks charity cannot pivot to a surveillance-advertising business model, cannot be acquired by a private buyer and redirected, and cannot be quietly converted into an extractive platform. Mission drift, the most common failure mode of well-intentioned networks, is prevented by legal instrument.
Regulatory standing. A registered charity has a defined relationship with tax and regulatory authorities. This clarity is valuable precisely because it removes ambiguity — the charity knows what rules it operates under, the authorities know what they are looking at, and members can rely on both.
Fiduciary duty. The charity's board owes duties to its members and its public-benefit purpose. Not to shareholders. Not to capital markets. The incentives of the governing body are aligned with the protocol's users by legal construction.
Transparent accounting. Charitable organisations file public accounts. Members, regulators, and researchers can verify that the protocol's reserve is intact, its fees are as stated, and its infrastructure budget is deployed as described.

In Canadian context, this is a federally registered charitable corporation with objects scoped to the operation of Favour Bucks. Equivalent structures exist in most jurisdictions: U.S. 501(c)(3), UK registered charity, Australian registered charity with the ACNC, and similar. The protocol's governance model is designed to be replicable across jurisdictions, with the understanding that each regional charity operates under its own legal framework and co-operates with others under a federated agreement (see §6.3).

· On Why Not a DAO ·

Decentralised Autonomous Organisations were seriously considered and deliberately rejected as the primary legal vehicle. Their appeal is real — member-owned governance, code-enforced rules, transparent operations — but their legal standing in most jurisdictions is unclear, and unclear legal standing means every participant bears legal risk the protocol cannot help them carry. A registered charity with DAO-style member governance mechanisms inside it captures the benefits of both. The protocol may adopt DAO primitives for specific functions (Group governance, infrastructure allocation votes, witness arbitration) while preserving a legal shell that regulators, banks, and members can work with.

§ 4.2

Regulatory posture.

The protocol's regulatory posture is clean, conservative, and cooperative. Favour Bucks intends to be legal in every jurisdiction in which it operates, and intends to earn that legality through structural design rather than through opacity.

Several specific questions deserve direct treatment.

Are FavourBucks a currency, a security, or a voucher?

The FavourBuck is designed first as a non-interest-bearing network accounting unit for useful work. One possible legal posture is a charitable voucher — a claim on future favour-capacity within a defined network, issued inside a public-benefit programme and redeemable for services rather than cash. This characterisation requires jurisdiction-specific legal review before any public cash-in, cash-out, or redemption programme.

In many jurisdictions, a voucher issued for use within a bounded programme is not a security if it represents no ownership interest, no expectation of profit, and no dividend claim. It is typically not sovereign currency because it has no legal-tender status, no sovereign issuer, and narrow acceptance. The launch plan therefore treats FavourBuck as pilot accounting first. Any donation-with-network-credit, voucher, redemption, or transfer model has to be designed with counsel before it is offered publicly.

The protocol will seek advance legal opinion and, where available, regulatory pre-clearance (a "no-action letter" equivalent, a CRA advance ruling, or similar) before launch in each jurisdiction. Where pre-clearance is not available, it will publish its legal analysis and invite regulatory engagement. The goal is to make the protocol's regulatory status a matter of record, not of interpretation.

Are favour transactions taxable?

This question has a layered answer. Pure peer-to-peer mutual aid — favours exchanged between individuals within a community context, of reasonable value, not conducted as a commercial business — is generally not taxable income in most jurisdictions, following well-established precedents for time-banks and mutual-aid networks. Favour Bucks' default operating mode fits this pattern.

However, some activity in the network will be commercial in character — a professional performing their trade, a business offering services through the protocol, a Group operating at a scale that makes its activity economically material. Commercial activity is taxable. The protocol does not claim otherwise and does not structure itself to evade commercial tax obligations. On-chain records are available to participants for their own tax compliance, and the charity will issue whatever receipts and reports are required by regulators.

The protocol's posture is: the law applies, we help members comply, we do not structure for evasion. Members who use the protocol for clearly commercial activity bear ordinary commercial tax obligations. Members using it for genuine mutual-aid activity bear no obligation beyond what they would in any other mutual-aid context. The distinction is familiar to any jurisdiction that has regulated charitable mutual-aid before.

Is the charity itself subject to specific oversight?

Yes. A registered charity in Canada is supervised by the Canada Revenue Agency's Charities Directorate, is subject to the Income Tax Act's charitable provisions, files a T3010 annual information return, and must meet public-benefit and governance requirements to maintain its registration. Favour Bucks' charitable operator will meet all applicable requirements and will publish its T3010 (or jurisdictional equivalent) openly.

The charity will also be subject to anti-money-laundering and counter-terrorism-financing regulations applicable to financial-service-like activities. The protocol's architecture supports this: transaction records are auditable, identity verification is available for transactions above defined thresholds, and the charity maintains the reporting relationships with FINTRAC (or jurisdictional equivalent) that its activities require.

· The Regulatory Commitment ·

Favour Bucks chooses legitimacy over cleverness. Every design decision that trades legal clarity for short-term convenience is rejected. Every design decision that strengthens the protocol's legal standing — even at the cost of complexity — is accepted. This is not a constraint. It is the condition that allows the protocol to be durable.

§ 4.3

Privacy by design.

The protocol distinguishes sharply between privacy and evasion. Privacy is a legitimate user expectation: participants should be able to conduct ordinary favours without those favours being exposed to the general public, to data brokers, or to adversaries. Evasion is the use of technical opacity to conceal legally reportable activity from the authorities that have lawful jurisdiction over it. Favour Bucks embraces privacy and refuses evasion.

Several architectural choices implement this distinction.

Encrypted by default. All protocol traffic is encrypted end-to-end. Only the parties to a transaction, and the witnesses they designate, can read its content. The charity's servers handle ciphertext routing and metadata but cannot decrypt transaction bodies. This protects participants from commercial surveillance, from data breaches, and from casual observation by unaffiliated parties.
Public ledger, private detail. On-chain transactions record the existence, value, and participants of a transaction — the minimum needed for reputation, audit, and dispute resolution — but not the content or details of the underlying favour. "FBs transferred from Alice to Bob, 50 FB, closed" is public. "What Alice and Bob specifically did" is not.
Minimal identity linkage. Participants operate under protocol-level identifiers that are not required to be tied to legal identity for most transactions. For small-scale favours, pseudonymity is the default. For larger-scale, commercial-character, or regulated transactions, legal-identity verification is triggered by defined thresholds, following standard know-your-customer practice.
Lawful compliance. When the charity receives a lawful order from a competent authority — a court order, a regulatory demand within the authority's scope — it complies with that order to the extent required by law, and only to that extent. Participants affected are notified where law permits. The protocol does not build back-doors for authorities, and does not build evasion mechanisms against them. It meets its legal obligations and defends its users within them.

The declared-private settlement path discussed in §2.4 is the protocol's possible mechanism for parties who require privacy above the default level. It is not a mechanism for evading taxation. The contribution policy for declared-private settlement remains unresolved until legal review. Unreported cash transactions between individuals, outside the protocol entirely, are — in any economy — subject to the jurisdiction's existing tax laws, and Favour Bucks makes no claim to exempt them.

§ 4.4

The cash corridor.

If the protocol accepts cash at the priming step, allows cash-out, enables redemption, or supports cash-equivalent secondary transfers, some operations may be treated as money-services activity in some jurisdictions. Those functions require a regulated boundary before launch: registration where required, reporting thresholds, record-retention policies, KYC gates, and professional legal review. The pilot does not need those functions to prove the favour layer.

This is not a burden to be minimised; it is a feature of operating legitimately in a regulated space. It is also why the protocol does not attempt to be a full banking substitute. FavourBuck must not be presented as a deposit product, passive investment, or promise of appreciation. If a reserve-backed voucher model is adopted, the reserve, charity, protocol operator, ledger operator, Group treasury, and any regulated money-services partner may need clear legal separation.

§ 4.5

Dispute resolution.

Most favours in the protocol complete cleanly. When they do not — when one party claims completion the other disputes, when witnesses disagree, when a favour was partially fulfilled in an ambiguous way — the protocol provides a four-step ladder for resolution.

Direct renegotiation. The parties to the Logistic attempt to resolve the disagreement between themselves, with the witness's confirmation or any instrumental evidence available as input. Most disputes close here. The protocol provides structured messaging and offers mediated conversation templates, but does not intervene unless invited.
Group arbitration. If both parties share a Group, or belong to closely adjacent Groups, Group-level arbitration is available: a small panel of senior members hears the dispute and renders a decision. Group arbitration is fast, contextual, and binding within the Group's charter. It is the right mechanism for most community-scale disputes.
Regional arbitration. If Group arbitration is not applicable or yields no resolution, a regional panel — drawn from high-reputation members across multiple Groups in a region, rotated to avoid capture — hears the case. Regional arbitration is slower, more formal, and produces a reasoned written decision that is added to the protocol's case-law archive.
Charitable-entity arbitration. As a final step, and only in cases of unusual scale, precedent-setting importance, or Group-level conflict of interest, the charity's own dispute committee hears the case. These cases are rare and are expected to be the basis on which the protocol's case law evolves.

Arbitration decisions at any level can affect reputation, redistribute FavourBucks, enforce clawbacks, or (in severe cases) suspend accounts. They do not affect legal rights that exist outside the protocol: participants retain all ordinary legal remedies, and the protocol's own decisions do not preclude court action in cases where the underlying facts involve violations of law. The protocol is a coordination layer, not a legal system.

PART V

The First Favour

A worked example. Told first as it would be told. Then shown as the protocol sees it.

§ 5.1

The breastmilk, told straight.

· Peterborough, Ontario. A Tuesday in October. ·

There is a mother who cannot produce enough breastmilk for her infant. She has tried everything. The pediatrician has been kind. The formula is fine. But the baby is not thriving on it, and the mother is in a kind of despair she will not recognise for what it is until much later.

She posts in a community forum, late on a Tuesday night, not really asking for help. Just saying it out loud.

A woman three neighbourhoods over, reading the forum while her own infant sleeps, has a freezer full of milk she has been pumping beyond need. She has been meaning to donate it but the formal milk-bank process is slow and requires the baby to be hospitalised. This mother's baby is not hospitalised. This mother just needs milk.

The second woman messages the first. They do not know each other. They live ten minutes apart.

Between them — through a favour network that one of them has used before and the other has just joined — a transporter is found: a man who drives past both houses on his way home from work, has an insulated cooler in the back of his car from a camping trip the previous weekend, and does not mind adding twelve minutes to his commute.

A coordinator — a woman who knows both mothers from a prenatal group she helped run years ago — volunteers to verify the handoff, because the donor mother wants to know the milk is getting to a real baby and the receiving mother wants to know the milk is actually what was offered.

There is a brief call. Consent forms are exchanged — this is a bodily fluid, and the donor discloses her medication history, her health, her recent diet. The receiving mother confirms she has read and understood, and accepts the milk on its terms. A small sample is dropped at a local clinic for a next-day screen, a safety precaution the receiving mother requests and the donor appreciates.

The transporter arrives at the donor's house at 5:47 PM. The cooler goes from freezer to cooler to car in under three minutes. He drives. He arrives at the receiving mother's house at 6:11 PM. The receiving mother is crying when she opens the door. The transporter hands her the cooler. He does not stay. He does not need to.

There is a note inside, written by the donor, in handwriting. It says: from one mother to another. I am glad you asked.

The baby feeds that night. The mother sleeps, briefly, for the first time in three days.

This favour cost, in total, about ninety minutes of four people's time, one slightly-longer commute, one insulated cooler, and the willingness of four strangers to trust each other over the course of a single afternoon. It is not a transaction that any amount of money could have produced, because the thing being transferred is not just milk.

It is also exactly the kind of thing Favour Bucks exists to make possible at scale.

§ 5.2

The breastmilk, annotated.

The same favour, observed from inside the protocol:

· As the protocol sees it ·

The receiving mother's forum post is, from the protocol's perspective, the initiation of a Logistic: a request for a transfer with an Origin (any donor's freezer), a Destination (her freezer), a Time constraint (as soon as possible, within 24 hours), and a Rider specifying breastmilk, transportability, willingness to disclose medication history, third-party lab screen, and preferred geographic radius.

Logistic initiation. The Logistic is created with a health-adjacent flag (§3.4), which triggers the disclosure protocol and routes candidate matches through the lab-network option. The Rider specifies the human witness layer (§2.7) because the favour is bespoke and high-trust.

The donor's freezer surplus is, in protocol terms, a Surface she has previously declared — "I have breastmilk available for donation, medication-free for 18 months, willing to transport within 30km, available within 24 hours of request." The matching engine identifies her as a candidate.

Surface match. The donor's declared Surface (§1.4) intersects the receiving mother's Rider on skills (lactation), material (breastmilk), willingness (donation), and location (within radius). Reputation from prior favours weights her ahead of other candidates.

The transporter is found by a second Surface match: drivers with insulated containers, available within the time window, willing to handle health-adjacent material. The engine identifies three candidates; the first to accept the contract secures it.

Surface stacking. Two Surfaces (donor + transporter) now compose against the single Rider. Neither could satisfy it alone. The protocol's matching engine is solving a composition problem, not a simple one-to-one match.

The coordinator is a member of the receiving mother's informal Group — a local parenting circle that has elected to be accounted as a Group within the protocol. Her offer to witness the handoff is recorded as a third Surface contribution, earning her reputation but no FavourBucks (she declines payment, as is her right).

Witness designation. The coordinator serves as the designated third-party witness (§2.7). Her participation triggers Group-level reputation weighting — because she and the receiving mother share a Group, the favour's clean completion will reinforce the Group's internal trust graph.

Pricing: the donor offers the milk at 0 FB. The transporter prices his contribution at 40 FB (the network's moving median for similar-distance transport is 35, he priced slightly above because of the health-adjacent category). The receiving mother accepts both terms. The lab screen is 60 FB, paid by the receiving mother directly to the lab node. The coordinator works for free, bankable as reputation.

Pricing. Each element is priced independently (§2.5). The donor's 0 FB offering is a pure gift — the protocol supports this natively as a favour of zero price, which still triggers all the protocol mechanics (witness, reputation, record) without FB settlement. This is an important capability: the protocol does not require monetisation to record and support pure gifts.

The handoff is witnessed (the coordinator confirms via a protocol message that she saw the cooler transfer, unopened, and confirms the receiving mother's identity). The lab screen returns clear the next morning. The Logistic closes.

Witness closure. Multi-party witness confirmation (§2.7) closes the Logistic. The health-adjacent flag escalates the closure to require the lab result before full settlement. When the screen returns clear, the FBs for the transporter (40 FB) and lab (60 FB) settle. The donor receives reputation; so do the coordinator and the transporter. The receiving mother's Group receives 1% of each settled transaction (1 FB, in this case — symbolic more than material, but recorded in the commons).

The note is not recorded. It never belonged to the protocol.

What the protocol does not see. The handwritten note, the tears at the door, the words at the handoff — these are the social residue of the favour, and they remain between the parties. The protocol's job is to make the coordination possible. What passes between the humans at the moment of contact is theirs.

§ 5.3

Why this case, first.

The breastmilk case is, deliberately, the first worked example in this document. It is not representative of the median favour — most favours will be rides, errands, deliveries, trades, meals, and small coordination tasks. It is, however, diagnostic. It exhibits every structural feature the protocol is built to handle, in a form that makes the features legible.

It cannot be priced by the market. Commercial milk sharing exists but is medicalised, slow, and scope-limited. The market does not reach this mother and this donor in this window. Favour Bucks is not competing with commerce; it is occupying a space commerce does not serve.
It is stackable. Four Surfaces compose to satisfy one Logistic. No one of them could have completed the favour alone. This is the composition primitive that distinguishes the protocol from one-to-one marketplaces and one-to-one volunteer platforms.
It is witnessable. The handoff is concrete, the recipient's confirmation is direct, the lab screen provides instrumental evidence. The protocol can close this Logistic cleanly.
It is health-adjacent. It exercises the informed-consent flag, the lab-network integration, and the multi-party witness escalation. A simpler favour would not test these.
It is Group-adjacent. The coordinator's Group membership triggers Group-level reputation effects. The receiving mother's 1% Group allocation, though tiny, establishes the mechanism.
It is emotionally gravitational. Every person who hears the story remembers it. The protocol's first demonstration favours should be the ones people want to tell each other about — and this is that kind of story.

Subsequent documents in Favour Bucks' public-facing suite will develop additional use-cases at lower emotional weight and more routine frequency: the Ryder earning recurring income, the Group acquiring shared tools, the mesh-node operator, the sliding-scale professional, the community disaster response. Each of these will use the same annotation structure — story first, protocol mechanics second — and each will build on the primitives established here.

Every protocol needs a creation story. Ours is a bag of milk, hand-delivered, with a note.

PART VI

Roadmap

What exists today, what is being built, and how to join.

§ 6.1

What exists today.

This manifesto is the protocol's first canonical document. As of its publication, the following are in place:

Protocol specification. The document you are reading. This is the source of truth against which every subsequent implementation, community resource, and public-facing page is measured.
Public-facing site. An editorial site presenting Favour Bucks' vision to general audiences, including a cinematic introduction and a framing document on the producer-vs-consumer inversion.
Community formation. A Discord community for builders, potential participants, and interested parties. Early discussion is scoped to implementation priorities, charter design, and pilot-favour selection.
Charitable entity formation. Legal work underway to constitute the protocol's operating charity in Canada, with provision for sister entities in additional jurisdictions as the protocol expands.

What does not yet exist: a production protocol implementation, a live escrow, a member-facing matching engine, or a mesh network operating at scale. These are the objects of the subsequent phases.

§ 6.2

Phase one — charter and pilot.

Phase one establishes the legal, governance, and pilot-implementation foundations. It has the following objectives:

Charity formation and registration. Incorporation of Favour Bucks Canadian charity, application for charitable status, establishment of the founding board, adoption of governing documents that encode the protocol's structural commitments (non-compound-interest, mission lock, public transparency, member governance).
Legal opinion on FavourBuck classification. Advance legal analysis — and where possible advance regulatory ruling — on the FavourBuck's status as a network accounting unit, possible voucher, non-security, or regulated money-services product in each jurisdiction of initial operation.
Manual pilot implementation. A minimum-viable operating system supporting the Logistic/Surface/Rider primitives, Need Layers, a simple witness layer, spreadsheet FavourBuck accounting, provisional credit notes, reciprocal work conversion, and recorded settlement. Scope limited to make the first ten to hundred favours possible, not to scale.
First demonstration favours. Execution of ten to twenty first-case favours — of the kind exemplified in Part V — in the protocol's first region of operation. These favours are documented carefully, published (with participant consent), and serve as the narrative foundation for broader onboarding.
Founding Groups. Formation of the first three to five Groups — community, trade, or affinity — each operating at pilot scale with the protocol's Group primitives. These become the governance and operational templates for Groups that follow.

§ 6.3

Phase two — regional mesh and scale.

Phase two extends the protocol from pilot to regional operation. Objectives:

Mesh network pilot. Deployment of the first mesh-node cohort — initially 50–200 nodes in a single region — implementing the asymptotic payout curve, reliability scoring, and protocol traffic routing. The mesh pilot is an engineering and economic validation, not yet a replacement for conventional internet carriage.
Multi-party witness layer. Completion of the multi-party and instrumental witnessing capabilities, enabling higher-stakes group favours and health-adjacent favours at production quality.
Lab network pilot. Onboarding of the first lab-network partners for health-adjacent verification, beginning with breastmilk and water-quality screens, expanding as demand and partnerships emerge.
Reciprocal work conversion. Activation of the provisional-credit-to-FB path (§2.2) once the witness layer is verified at scale. This is the transition from cash-primed-only issuance to organic circulation tied to real contribution.
Group governance tooling. Production-grade Group formation, fund management, voting, and insurance primitives. Groups operating at this phase can reach the hundreds of members and hold fund balances in the tens of thousands of FavourBucks.
Regulatory ratification. Any regulatory guidance, rulings, or adjustments emerging from Phase 1 are formalised in the protocol's operational procedures. Second-jurisdiction expansion planning begins.

§ 6.4

Phase three — federation.

Phase three establishes Favour Bucks as a federated system across multiple jurisdictions, with interoperable protocol implementations and cross-border favour flow. Objectives:

Sister charity formation. Registered charitable entities in additional jurisdictions (initial targets: U.S., U.K., select E.U. member states), each operating under its own legal framework, federating under a shared protocol charter.
Cross-border favour protocol. Protocol mechanisms for Logistics that cross jurisdictional boundaries, with appropriate regulatory handling (cash conversion, tax reporting, witness accreditation) at the boundary.
Global mesh expansion. Mesh network extension to support inter-regional traffic, including the provisioning of long-haul relays and backup terrestrial/satellite infrastructure where geographic coverage requires it.
Insurance federation. A cross-Group insurance reserve for large-scale events (regional disasters, wide-scale crises) underwritten by the federation of Groups, triggered by agreed criteria, and paid out across jurisdictions as needed.
Governance maturation. Transition of the protocol's governance from founder-led stewardship to member-elected leadership, with formal protocols for amendment, upgrade, and dispute resolution at the federation level.

Timelines are deliberately not specified in this document. The protocol is not on a deadline. Each phase completes when its objectives are demonstrably met, not when a calendar says so. A premature transition between phases is worse than a delayed one; durability is the governing virtue.

§ 6.5

How to participate.

The protocol is built by and for its participants. There are several distinct ways to engage, each appropriate to different backgrounds and stages of the system.

01 · BUILD

Engineers. Architects. Operators.

The protocol needs people who can write the matching engine, the witness layer, the mesh stack, the Group governance tools. If you build systems, the Discord's #build channel is the right entry point.

02 · FUND

Early supporters. Donors.

The charity accepts donations toward its operating costs — legal, engineering, infrastructure. Charitable gift status applies in Canada (and equivalents in other jurisdictions). Reach out through the site.

03 · JOIN

Members. Group-starters.

Form a Group. Declare a Surface. Ask for a favour. Offer one. As the pilot opens in your region, you become a founding member. The system's value grows with every person who does.

04 · OPERATE

Node operators. Lab partners.

Run a mesh node. Offer verification services as a lab partner. Map your city. Each of these is an infrastructure role that earns recurring FavourBucks and builds the substrate the network depends on.

05 · GOVERN

Arbiters. Witnesses.

Serve on regional arbitration panels. Become a trusted witness for health-adjacent or high-stakes favours. Contribute to the protocol's case law. Reputation, not wealth, is the qualification.

06 · ADVOCATE

Writers. Organisers. Translators.

The protocol's adoption depends as much on clarity of communication as on engineering quality. Write, translate, organise local gatherings. The document you are reading is one of many that will be needed.

Where to go next: the project's Discord server is the primary venue for builders, early members, and potential collaborators. Role-specific channels let you find the conversation most relevant to your contribution. Use-case pages on the site develop specific favour archetypes in more detail. Contact addresses for charitable gifts, media enquiries, and partnership discussions are published on the site's contact page.

PART VII

Appendices

Reference material for close readers, implementers, and auditors.

Appendix A

Glossary of terms.

Availability

The declared willingness of a member to fulfil favours matching a given Surface within a specified time window. Paid availability claims are subject to reputation clawback if not honoured (§2.6).

Charity (the)

The registered charitable organisation that operates the protocol's escrow, issues and redeems FavourBucks, and provides the governance, audit, and legal substrate for the system. Each jurisdiction has its own charity federated under a shared charter (§4.1).

Escrow

The protocol's transaction clearinghouse, operated by the Charity. Holds funds for an instant, splits per the standard formula, and releases to counterparties. Not a bank; does not lend or pay yield (§2.3).

FavourBuck (FB)

The protocol's native accounting unit for useful work. Non-interest-bearing, not a speculative asset, seeded through cash-primed issuance in the launch phase and, at maturity, created through reciprocal work conversion of provisional favour credit (§2.1–2.2). Voucher, redemption, and cash-out posture require legal review.

Group

A legally-constituted collective of members who pool a share of their transaction flow to acquire shared assets, underwrite mutual insurance, issue grants or earned rebates, and build a local commons. The structural answer to burnout in mutual-aid networks (§1.5).

Logistic

The protocol's atomic unit of favour activity. Defined by Origin, Destination, Time constraint, and Rider. All favours compose from Logistics (§1.3).

Mesh (the)

The protocol's native communications substrate, built on Reticulum and compatible LoRa-class radio technology, operated by member-run nodes, funded by protocol infrastructure fees (§3.1).

Rider

The specification attached to a Logistic describing what capabilities, skills, equipment, capital, and willingness are required to fulfil the favour. Not a person — the spec sheet a person must match to be selected (§1.3).

Surface

A member's declared availability to contribute to favours — their willingness, time, skills, capital, and location published in a form the matching engine can reason about. Surfaces stack to satisfy composite Riders (§1.4).

Witness (layer)

The protocol's verification mechanism for favour completion. Self-witnessed, third-party witnessed, multi-party witnessed, or instrumentally witnessed, depending on the favour's scale and class (§2.7).

Appendix B

Formulas and specifications.

B.1 — Recorded transaction split

// Standard recorded settlement doer_receives = transaction_value × 0.98 system_fee = transaction_value × 0.01 group_share = transaction_value × 0.01 // Where no Group is declared, group_share routes to // the regional mutual-aid pool pending member assignment.

B.2 — Declared-private settlement policy

// Policy option, not constitutional rule private_contribution = declared_value × policy_rate system_allocation = private_contribution × system_policy_share group_allocation = private_contribution × group_policy_share // Exact rate, disclosure, compliance treatment, and payment // path require legal review before public use.

B.3 — Mesh-node per-reward function

// Per-node reward as a function of local saturation R(node) = R_max × reliability(node) / (1 + α × n_local) // where: R_max = regional maximum, set by Charity infrastructure committee reliability = rolling 30-day uptime vs declared availability, [0.0, 1.0] α = saturation coefficient, tuned per region n_local = count of active nodes providing overlapping coverage // Computed hourly. Paid weekly in FBs.

B.4 — Reputation update on favour closure

// On clean closure (no dispute, witness confirms) rep_delta = base_gain × favour_stake × witness_class_multiplier // On disputed closure resolved in party's favour rep_delta = base_gain × favour_stake × 0.3 // On disputed closure resolved against rep_delta = -base_loss × favour_stake × dispute_severity // On availability clawback rep_delta = -base_loss × claimed_window × (1 - honoured_fraction)

B.5 — Cash-primed FB exchange rate

// Initial reference rate, subject to periodic review 1 FavourBuck ≈ 1 CAD (at protocol launch in Canada) // Rate is a reference, not a peg. Charity maintains reserve // sufficient to redeem a target fraction of circulating FBs // at the reference rate, adjusted as the system matures.

Appendix C

Precedents and prior art.

Favour Bucks is not without intellectual ancestry. Several prior traditions inform its design, and any serious reader should be acquainted with the following:

Time banking. Edgar Cahn's Time Dollar system (1980s onward) established the modern precedent for service-hour accounting as a mutual-aid currency. Favour Bucks departs from time-banking in that FavourBucks are not time-denominated — favours can be priced by negotiation, and hours are not the unit. Time Dollars remain useful precedent for thinking about bounded programme units, mutual aid, and possible voucher treatment.
LETS (Local Exchange Trading Systems). Michael Linton's 1980s LETS design pioneered mutual-credit accounting — members' balances can go negative, the system tracks debt rather than issuing a fixed supply. Favour Bucks borrows the insight that participants can receive before they give, but converts provisional favour credit into real FavourBucks only when reciprocal work is verified. This preserves balance integrity while acknowledging LETS as a precedent for community-scale alternative currency.
Wörgl Schwundgeld. The 1932 Austrian experiment with demurrage-based currency, inspired by Silvio Gesell, famously accelerated local economic activity during the Great Depression. Favour Bucks considered but rejected demurrage in favour of no-compound-interest; the effect is similar (discouraging hoarding) but the mechanism is structurally cleaner.
Ithaca HOURS, BerkShares, and modern local currencies. Various local-scrip currencies in the U.S. provide operational precedent for geographic-scope alternative money. Favour Bucks' regional-charity federation model draws on these implementations' lessons about the importance of legal-entity structure.
Freecycle, Buy Nothing groups. Large-scale demonstrations that non-monetary exchange at community scale is feasible, and that the limiting factor is not economic but coordinative. Favour Bucks takes from these a conviction about the scale of latent mutual-aid capacity, and attempts to provide the coordination layer they lack.
Holochain and mutual-credit distributed systems. Agent-centric distributed-ledger designs inform the protocol's approach to reputation and identity. Favour Bucks does not itself use Holochain as its implementation substrate (the choice of substrate is an engineering decision deferred to implementation), but acknowledges the design tradition.
The Reticulum Network Stack. Mark Qvist's Reticulum is the specific mesh-networking protocol on which Favour Bucks' mesh substrate is built. Reticulum's encrypted-by-default, identity-first, medium-independent design is a direct structural fit for the protocol's communications needs.

Appendix D

Known risks and open questions.

In the interest of honesty, the following are known risks, open design questions, and acknowledged limitations of the current protocol specification. A serious reader should weigh these alongside the proposal.

Cold-start risk. A favour network's utility scales with its membership. Below a critical mass, participants may join, find few matches, and leave. The protocol mitigates this with cash-primed FB issuance (so new members can participate immediately) and Group-driven onboarding (so members arrive in cohorts), but the risk is real and the first regions of operation must be selected with care.
Regulatory variability. Voucher, accounting-unit, charitable-programme, and money-services classifications vary across jurisdictions. Expansion requires jurisdiction-specific legal analysis and, in some cases, modified operational structures.
Scaling the witness layer. Human-in-the-loop witnessing scales linearly with favour volume. At sufficient scale, this becomes a constraint. Instrumental witnessing (photographs, geolocation, lab confirmation) can substitute for many cases, but the protocol must continue to develop witness-automation that preserves trust while reducing human overhead.
Governance capture. Any member-governed system carries a risk that well-resourced or highly-coordinated minorities will capture governance positions disproportionate to their actual contribution. The protocol mitigates this through rotation, reputation-weighted voting, and Group-level subsidiarity, but the risk is permanent and requires active management.
Mesh network reliability. Consumer-grade mesh networking has well-known limitations (weather, terrain, spectrum congestion). The protocol's dependence on the mesh for infrastructure-future incentives does not extend to dependence for core operations — the protocol can run over conventional internet — but the mesh's growth is contingent on consistent delivery, and failures in early node cohorts could discourage operators.
The price-stability question. The FavourBuck's reference rate to conventional currency is not a hard peg. If cash-primed issuance sees large volume while reciprocal work conversion lags, the FB's effective purchasing power may drift. The Charity manages the reserve ratio, provisional-credit limits, and Group standing rules to prevent extreme drift, but the protocol is not immune to monetary-policy-like challenges as it scales.
Mission drift in practice. Legal mission-lock is necessary but not sufficient. Organisations can formally serve their charter while operationally drifting toward easier-to-measure proxies (membership count, transaction volume) at the expense of harder-to-measure goals (genuine mobilisation, community formation). The protocol's publication commitments and member-governance mechanisms mitigate this, but ongoing vigilance is required.

This is not an exhaustive list. Subsequent versions of this document will evolve the risk register as the protocol is built and as real operational experience identifies issues the theoretical design did not anticipate.

Appendix E

Version history.

v0.1 · April 2026. Initial release. Defines the Logistic, Surface, Rider, Group, FavourBuck, Escrow, Witness layer, Mesh network, asymptotic payout curve, and governance structure. Publishes the breastmilk worked example and the phased roadmap. This is the canonical specification as of the document's publication date; all subsequent implementations and public materials should reference this version or its successors.

Future versions will be numbered according to the following convention: minor releases (0.1 → 0.2) for refinements, clarifications, and non-breaking additions; major releases (0.x → 1.0, 1.x → 2.0) for structural changes to the protocol's core primitives or governance. Each release is published with a full changelog and a summary of the rationale for any changes.

A mobilizationprotocol for thepost-consumer age.

What this document is, and isn't.

First Principles

The Protocol

Infrastructure Futures

Governance and Regulation

The First Favour

Roadmap

Appendices

First Principles

What a favour is.

The mobilisation gap.

The Logistic — the atomic unit.

The Surface Layer.

The Group.

The Protocol

FavourBucks.

Credit and circulation.

The Escrow model.

Recorded and declared-private settlement.

Pricing and negotiation.

Reputation and availability.

The Witness layer.

Infrastructure Futures

The mesh network.

The asymptotic payout curve.

Pay to map.

Verification and lab networks.

Group commons and insurance.

Governance and Regulation

The charity structure.

Regulatory posture.

Are FavourBucks a currency, a security, or a voucher?

Are favour transactions taxable?

Is the charity itself subject to specific oversight?

Privacy by design.

The cash corridor.

Dispute resolution.

The First Favour

The breastmilk, told straight.

The breastmilk, annotated.

Why this case, first.

Roadmap

What exists today.

Phase one — charter and pilot.

Phase two — regional mesh and scale.

Phase three — federation.

How to participate.

Appendices

Glossary of terms.

Formulas and specifications.

B.1 — Recorded transaction split

B.2 — Declared-private settlement policy

B.3 — Mesh-node per-reward function

B.4 — Reputation update on favour closure

B.5 — Cash-primed FB exchange rate

Precedents and prior art.

Known risks and open questions.

Version history.

A mobilisation protocol is not a promise.

A mobilization
protocol for the
post-consumer age.