RFC-001 Is Open: Defining the Economic System of an Evolution Protocol

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:

1. PricingModel enum — what kinds of pricing exist at all (FREE / PER_CALL / SUBSCRIPTION / NEGOTIATED / UNKNOWN)
2. Fitness Points (FP) earn/spend paths — a non-currency reputation signal computed by the protocol core, not a transferable token
3. Author share split formula — including reputation_discount_factor and import_factor that prevent cross-Binding arbitrage
4. PhenotypeCommitment — a signing primitive that closes the integrity gap left open by spec §27.3 (compatibility windows ≠ pricing tampering protection)
5. 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:

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:

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:

RFC-001 on rotifer-protocol/rotifer-spec#2

A signed-off Rotifer ID is encouraged but not required. Anonymous-but-substantive feedback is fine. We do ask that objections include three things:

1. The specific section or invariant being challenged
2. A proposed alternative
3. 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:

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