A little while ago we introduced Birdbrain — a shared memory for the Kusama flock, built around on-chain membership rather than passive readership. We said something in passing there that this post picks up: joining Birdbrain requires KSM, because a membership is a real item on Kreivo, not an account bolted onto a website.
That raises an obvious question — who should pay that KSM? — and it turns out to generalise into a treasury argument worth putting to the room. So here’s our first RFC.
The idea in one line: instead of spending the Kusama treasury down into dollars — grants sold for fiat, the money gone, nothing left that keeps earning — spend it into memberships. Kreivo can now sign a real person, or a whole collective, up as an on-chain member in one passkey tap, no seed phrase, no tokens in their pocket. Each sign-up has a small, known KSM cost (~0.3 KSM). A KSM spent this way doesn’t leave for fiat; it moves sideways and leaves behind a member with a reason to keep using and holding KSM.
Three things we’d want to know first, so we’ll say them up front:
- The ~0.3 KSM is not revenue to anyone. The open membership pool is owned by the Kreivo Treasury, so the payment moves KSM from one public on-chain account to another — it stays in-ecosystem, it isn’t a vendor invoice.
- Execution would be a bounty, not a blank cheque. The mechanism is Kusama’s own standing-envelope pattern —
pallet-bounties+ child-bounties, the same shape the Vision bounties (Proof of Personhood, ZK, Art) already run. Governance approves a rule-bound envelope once; payouts happen by a fixed published formula, no per-payout vote, no curator discretion over amounts. - We custody nothing — not the funds, not the keys. The KSM never passes through us (it moves to the Kreivo Treasury, as above), and members hold their own keys via self-custodied passkeys — we hold no balances and no signing rights on anyone’s behalf. We are a proponent, of course: Decent Partners runs part of this stack. So the design is deliberately stablecoin- and team-agnostic — anything one team can do here, another should be able to copy. If it only works when we run it, it’s the wrong design, and we’d want to know.
The honest crux isn’t affordability — the whole headline target fits inside a third of the fund. It’s retention, and genuine vs. recycled demand: treasury KSM moved to a community account is not new demand, and the argument only holds if a subsidised member base produces a recurring external inflow that a one-off grant never does. The RFC works hard not to cheat on that distinction, and lays the numbers out so you can check them.
Where we actually are: this isn’t a thought experiment. We have a pipeline of collectives lined up to onboard, and we’ve already started buying KSM ourselves to subsidise their memberships — so the mechanism is live, just running on our own balance sheet for now. That’s what turns this from a would-it-work question into a scaling one: at what point, and at what size, should the treasury co-fund what we’re currently bootstrapping by hand?
Read the full RFC and argue back on the record:
Should Kusama Spend Its Treasury Onboarding Members Instead of Selling KSM? · Birdbrain RFC
It’s a layered read — one sentence at the top, then a plain-language version, the economics, the objections, and the on-chain mechanics for whoever wants to go deep. Comments and suggested edits there are signed and kept on the record; that’s where the real debate lives.
And here’s the recursion: taking part in this RFC is the onboarding it describes. When you comment on the RFC page, a single passkey tap enrols you as a self-custodied member of the Birdbrain collective on Kreivo — the signing key stays on your device, we hold none of it — and every contribution (comment, reply, endorsement) accrues to your own evolving seed: a self-owned, on-chain participation graph. So the page doubles as a live demonstration of exactly the mechanism this RFC proposes — no seed phrase, no tokens in your pocket, one gesture.
The main thing we’d put to the room:
- What should the initial bounty request be for? Given a real, growing pipeline and members already being onboarded, what’s a sensible size and scope for a first rule-bound envelope — enough to prove retention at scale, without over-committing the treasury before the numbers are in?
And two narrower ones, if you’re going deep:
- What retention rate would make this clearly worth it — the threshold the pilot should be judged against?
- Should
pallet-paymentsfees route a slice back to the network, and if so, how much?
Where this sits in the process. This is deliberately the first of three steps, in order:
- RFC — Request for Comment (now). This post and the live doc. Pressure-test the logic, the numbers, the design. No ask, no vote.
- WFC — Wish for Change. If the idea survives contact, an on-chain referendum on the Wish for Change track to establish a mandate — does Kusama actually want to direct treasury this way? — without yet moving any funds.
- Bounty proposal. Only with that mandate do we bring a concrete, rule-bound bounty for a specific figure — the “how big” question above.
We’re at step 1. Nothing here commits anyone to anything — it’s a discussion document, and every figure in it is meant to be checkable. Tell us where it’s wrong.