Protocol RFCs
The ten RFCs below define every on-chain type, extrinsic, and protocol contract that the chain, the runtime, and the off-chain services agree on. They are versioned: a breaking change requires lead-of-leads sign-off and a compatibility-test bump per plan §4.
In this section
The "Source" column points at the canonical specification in the monorepo; the per-RFC pages below summarise it for readers without duplicating it.
| RFC | Topic | Status (May 2026) | Owner | Source |
|---|---|---|---|---|
| RFC-0001 | Signed response receipt format | Draft · ratify end Q3 2026 | Verification Lead | spec |
| RFC-0002 | Multi-vendor attestation report | Draft · ratify end Q3 2026 | Security Lead | spec |
| RFC-0003 | Heartbeat schema | Draft | Serving Lead | spec |
| RFC-0004 | Batch settlement format | Draft | Pallet Lead | spec |
| RFC-0005 | Slashing extrinsic ABI | Draft | Pallet Lead + Verification Lead | spec |
| RFC-0006 | Sampling randomness | Draft | Verification Lead | spec |
| RFC-0007 | Customer nonce protocol | Draft | Gateway Lead + DevEx | spec |
| RFC-0008 | Oracle feed | Draft | Tokenomics Lead | spec |
| RFC-0009 | Operator registration | Draft | Pallet Lead + Security Lead | spec |
| RFC-0010 | RPC endpoint contract | Draft | DevOps + Foundation | spec |
Planned RFCs (not yet authored)
These are referenced from the monorepo README and the marketing brief but are not yet drafted. They are listed here so the gap is explicit, not so the gap is hidden.
| Planned RFC | Topic | TBA |
|---|---|---|
| RFC-0011 | Adapter / LoRA publishing and royalty contract | Adapter Lead, Q3 2026 |
| RFC-0012 | opML challenge window extension to slashing | Verification Lead, Q4 2026 |
| RFC-0013 | zkML small-head proof attachment to receipt | Verification Lead, Q4 2026 |
| RFC-0014 | cuPOW kernel and proof submission | Pallet Lead, Q4 2028 (deferred) |
| RFC-0015 | Cross-chain bridge ABI (Snowbridge fork) | Bridge Lead, post-TGE |
If you need a contract that isn't listed, open a discussion on the monorepo; the foundation tracks RFC requests in DECISIONS.md.
Versioning and breaking changes
- Backwards-compatible changes (new optional fields, additive extrinsics): patch-version bump on the RFC, no chain upgrade required.
- Backwards-incompatible changes (renamed field, type change, removed extrinsic): minor-version bump on the RFC, runtime upgrade required, audit gate triggered if the change touches
pallet-bme,pallet-slashing, orpallet-attestation-registry. - Major versions (v2.0+): require pre-announced deprecation of v1 endpoints with a minimum 90-day overlap so SDKs and integrators can migrate.