The Rotifer Protocol's L0 kernel and L1–L2 evaluation layers have shipped formal specifications. There has been one stubborn hole in the architecture from day one: how does economic value flow through an evolution protocol that lives across Cloud, Web3, and Local Bindings simultaneously?
Today that hole gets a draft proposal, and that proposal becomes our first formal RFC.
RFC-001 — Rotifer Protocol Economic System is open for community review through 2026-06-05 UTC. After 14 days with no unresolved objections, the RFC moves into the spec change backlog for v1.x integration. Any blocking objection — on [M] mechanism choice or [S] structural primitive — pauses that path and forces revision.
This post is a reading guide. The RFC itself is 428 lines of fairly dense protocol design. If you only have ten minutes, read this first to figure out which sections deserve your attention.
Why an evolution protocol needs an economic layer at all
It would be cleaner if the protocol just stayed out of money. The L0 kernel doesn't care about money. Arena fitness scoring doesn't care about money. The IR compiler that turns a Gene's TypeScript into deterministic WASM does not, in any honest reading, care about money.
The reason the protocol cannot stay neutral is interoperability across Bindings. A Gene published on Cloud Binding (Stripe-settled fiat) will eventually be invoked from a Web3 Binding (Base L2-settled crypto). Author payment must flow back uniformly. Cross-Binding arbitrage — "publish where it's cheap, monetize where it's expensive" — must be neutralized at the protocol layer, not the marketplace layer, because the marketplace can be replaced and the protocol cannot.
So the protocol has to define five things that the Bindings and marketplaces don't get to override:
-
PricingModelenum — what kinds of pricing exist at all (FREE / PER_CALL / SUBSCRIPTION / NEGOTIATED / UNKNOWN) - Fitness Points (FP) earn/spend paths — a non-currency reputation signal computed by the protocol core, not a transferable token
-
Author share split formula — including
reputation_discount_factorandimport_factorthat prevent cross-Binding arbitrage -
PhenotypeCommitment— a signing primitive that closes the integrity gap left open by spec §27.3 (compatibility windows ≠ pricing tampering protection) -
Two-dimensional
trust_tier—lifecycle_state×certification, replacing the previous flat enum
Everything else — UI, pricing pages, Stripe integration details, smart contract addresses on Web3 Binding — stays out of the protocol. That's by design and the boundary is one of the questions we want feedback on.
What "lazy consensus" means in practice
The Rotifer Foundation's RFC process follows lazy consensus. After publication:
- Day 0–7: open period. Comments on the GitHub issue are categorized into
[N]numerical,[M]mechanism,[S]structural, or off-topic. - Day 7: mid-period status update posted on the issue.
- Day 14: decision point. Three paths:
- Path A — no unresolved objections → accepted, moves to spec change backlog Tier 1.
-
Path B —
[M]or[S]objection requiring revision → revised body posted, period extended 7–14 days. - Path C — fundamental objection requiring redesign → closed, returns to design phase as RFC-001-v2.
The four expected response times for community engagement:
| Action | Channel | SLA |
|---|---|---|
| Formal feedback | The issue thread | 7 days |
| Propose alternative formula | Comment with PR link | 14 days |
| Request clarification | Comment on issue | 3 days |
| Object on safety/security grounds |
dev@rotifer.dev with [RFC-economic-system] subject |
5 days |
If none of these channels work for you, please open the issue and tell us what's missing. RFC-001 is the first formal RFC the Rotifer Foundation has run — the process itself is also being calibrated.
How the questions are tagged, and which ones matter most
Every discussion question in §8 of the RFC carries one of three tags:
-
[N]Numerical — value calibrated by ABM simulation, modifiable per-season at low cost. Defaults are starting points, not frozen. -
[M]Mechanism — structural choice, modifiable via new RFC. Once accepted, expected to remain stable through v1.x. -
[S]Structural — primitive shape, modifiable only at major version boundaries (v2.0+) with 12-month deprecation window.
The triage is deliberate. [M] and [S] decisions cost the most to revisit, so they deserve the most scrutiny. [N] defaults will be recalibrated against ABM simulation output every ~90 days regardless — pushing back on whether 30% is the right F(g) improvement threshold for disruption_bonus is a real conversation, but a less load-bearing one than pushing back on whether binding_share belongs at the protocol layer or the Binding layer.
The nine questions, ranked by what we think deserves the highest scrutiny:
| Q | Tag | What it asks | Why it matters |
|---|---|---|---|
| Q1 | [M] |
Should binding_share be set at the protocol layer (uniform discount) or the Binding layer (per-Binding negotiation)? |
Determines whether Bindings can compete on author take-rate or only on settlement rail features. |
| Q3 | [M] |
PhenotypeCommitment vs. existing spec §27.3 — separate, merged, or read-only fallback? | Affects every Gene migrating to PER_CALL. |
| Q6 | [M] |
Should Coalition reputation_discount_factor suspension be opt-in vs. automatic? |
Fairness question between cold-start authors and existing reputation-rich authors. |
| Q9 | [M] |
Per-season recalibration vs. semi-annual vs. triggered-only vs. mixed? | Determines governance load and adaptation speed for the next 5 years. |
| Q4 | [N] |
Is the 30% F(g) improvement threshold for disruption_bonus calibrated correctly? |
One of the easier [N] questions to validate against existing Gene data. |
| Q5 | [N] |
Is 6 months caller lock-in (I-Migrate-3) sufficient for production systems with regulatory dependencies? | May surface a per-caller-class extension mechanism we have not yet designed. |
| Q2 | [N] |
Is the 0.5 lower bound on reputation_discount_factor too punitive for newly-published Genes? |
Newcomer immunity vs. cold-start Coalition is the trade-off. |
| Q7 | [N] |
Is the [0.5, 1.0] range for cross-Binding import_factor calibrated correctly? |
Easier to defer to ABM simulation than to debate analytically. |
| Q8 | [N] |
Are the cold-start economic graduation criteria (sandbox adoption ≥ 30%, author switch rate ≥ 10%, R(g) median > 0.5) too strict? | Hardest to evaluate without running v1.0 in production. |
If you read nothing else in the RFC, read §8 Q1, Q3, Q6, and Q9.
What's out of scope for RFC-001
To keep the discussion focused, four things are explicitly out of scope:
- Specific currency exchange rates between fiat and FP
- UI/UX details of pricing pages on the marketplace front-ends
- Smart contract addresses on Web3 Binding
- Foundation member admission criteria (governed separately)
These are real questions but they belong in subsequent RFCs (or are governed outside the RFC process entirely). Comments on them are welcome but will be tracked as follow-ups, not as blocking objections.
How to participate
The single canonical channel is the GitHub issue:
A signed-off Rotifer ID is encouraged but not required. Anonymous-but-substantive feedback is fine. We do ask that objections include three things:
- The specific section or invariant being challenged
- A proposed alternative
- Rationale for why the alternative is better
That format isn't bureaucratic — it's how lazy consensus actually closes. An objection without an alternative is hard to resolve, and an objection without rationale is impossible to weigh against the existing draft.
We expect to publish a Day-7 status update on the issue summarizing comments received. If you've left a comment we'll read it before then. If you have something substantive but not yet polished, please go ahead and post the rough version — comment editing is supported and we'd rather catch the substance early than wait for the polished version.
Where this fits in the v0.9 → v1.0 path
RFC-001 is the design freeze for v0.9 and the implementation gate for v1.0. The three-stage timeline:
| Stage | Version | Duration | Goal |
|---|---|---|---|
| Design freeze | v0.9 | now | This RFC + ABM calibration + spec change backlog entries |
| Implementation | v1.0 | Q3 2026 | Cloud Binding live with Stripe; PER_CALL available; FP query API |
| Full adoption | v1.x | Q4 2026+ | Web3 Binding live; cross-Binding FP transfer; certified tier marketplace |
Everything in v1.0 implementation depends on this RFC clearing community review. If we get a [S] objection at day 14, the v1.0 timeline shifts. We've designed the protocol around the assumption that this kind of slip is the right outcome of an RFC process — better to revise design than ship a sticky primitive.
A short note on what we want to hear
We've drafted RFC-001 inside the team for ~3 weeks. We're at the stage where additional internal review costs more than it gains. The questions in §8 are the ones we genuinely don't know the right answer to — not rhetorical questions designed to anchor discussion in a preferred direction.
If you read the RFC and think a question we didn't ask deserves to be in §8, tell us. The most useful feedback we've received on past designs has been in the form: "the question you should be asking is X, not Y."
The discussion period closes 2026-06-05 UTC. See you on the issue.
RFC link: https://github.com/rotifer-protocol/rotifer-spec/issues/2
Discussion deadline: 2026-06-05 UTC (14 days after publication)
Process model: lazy consensus
Top comments (0)