Skip to content

RFC-0006 — Verifiable Contribution
RFC 0006
Title Verifiable Contribution
Slug verifiable-contribution
Status Draft · Phase 2 (Deferred)
Track Standards
Authors @AbdelStark
Created 2026-06-02
Target milestone Proof-ready disciplines: v0.1/v0.2; the proofs themselves: post-v1.0 (Stage D)
Area verify
Requires RFC-0001, RFC-0002, RFC-0003, RFC-0004, RFC-0014

Verifiability is Phase 2: prove the federated-JEPA science first (RFC-0002, RFC-0005). This RFC specifies the eventual cryptographic layer and — crucially — the small set of properties Phase 1 must satisfy so that adding proofs later requires no rework. The Phase-1 proof-ready disciplines (§3 below) are in scope for v0.1–v1.0 and are tested now; the proofs (Stage D) are out of v1.0 scope and tracked as future work per the conventions §12 milestone table.

Summary

This RFC specifies four provable claims and the mechanism that backs each (§ Proposed Design, item 2): aggregation correctness via a Circle-STARK over the outer-step circuit (Stwo); update-from-committed-data via the Merkle commitment $R_c$ (RFC-0014); frame-alignment correctness via free public recomputation of a deterministic function of the public probe and committed weights; and faithful inner-step execution via TEE attestation. The leverage is structural: the frame anchor of RFC-0002 keeps the aggregation step a near-linear operation (a weighted average plus a Nesterov update), whose arithmetic circuit is small enough to prove. The gauge fix is therefore also the verifiability enabler — the same design decision that makes the science well-posed makes the proof cheap.

The deliverable for v0.1–v1.0 is proof-readiness: deterministic aggregation, hash-committed model versions, Merkle-rooted episode commitments, a content-pinned public probe, and a reproducible outer step — five inexpensive disciplines that are the entire prerequisite for Phase 2. The proofs land in Stage D once prover capability and a STARK-friendly commitment hash are in place.

Motivation

A federation of mutually-distrusting sovereign participants needs a trust story stronger than "we ran it twice and the numbers matched." Three trust questions arise once raw data never leaves a boundary (INV-RESIDENCY, enforced in lensemble.data.residency):

  1. Did the coordinator aggregate honestly? A malicious or buggy coordinator could weight participants incorrectly, drop a participant's $\Delta_c$, or fabricate the committed global model. Under the Phase-1 honest-but-curious model this is assumed away; under a malicious-coordinator model it must be detectable.
  2. Did a participant compute its update from the data it claims? Without binding, a participant can submit an update derived from data it never committed to, breaking the claimed provenance link.
  3. Did the inner training step run faithfully? The data-touching computation is the most expensive thing to prove and the hardest to attest.

Phase 1 answers (1) and (3) by assumption and (2) by tamper-evidence (RFC-0004 §4). The purpose of this RFC is to (a) define the Phase-2 cryptographic answers, and (b) constrain Phase-1 engineering so those answers attach with no redesign. The cost of honoring the constraints now is low; the cost of retrofitting determinism, commitments, and a pinned probe after the fact is high. This is the connection between RFC-0002 (the anchored frame keeps aggregation near-linear) and verifiability: closing the gauge is what makes the aggregation circuit cheap to prove.

Goals

  • G1. Specify the four provable claims and the mechanism backing each, with the honest cost and trust assumption of each stated plainly (no overclaiming).
  • G2. Specify the Phase-1 proof-ready requirements precisely enough that a contributor implementing RFC-0003, RFC-0010, and RFC-0014 satisfies them without further coordination, and so that Phase 2 needs no rework.
  • G3. Specify the Phase-1 public recomputation surface as a concrete, testable API (recompute_alignment) that reproduces the coordinator's frame alignment from public inputs alone, deterministically.
  • G4. State the composed trust statement for each roadmap stage (2a–2d): which parts of a contribution are proven, which are attested, which are assumed.
  • G5. Define the boundary plainly: what verifiable contribution does not prove (not data quality, not gradient honesty), so the guarantee is not misread.
  • G6. Keep the Phase-2 commitment-hash migration path open (SHA-256 now; a STARK-friendly hash later) without breaking the Phase-1 commitment format.

Non-Goals

  • Proving a full 1.2 B training step in zero knowledge. Infeasible today; this RFC does not promise it. The inner step is covered by the weaker TEE assumption (item 2, claim 4), and full proof-of-training is research, deferred to roadmap 2d (Stage D).
  • Proving data quality or gradient honesty. Provenance proves origin, not goodness. No mechanism here certifies that a participant's data is useful or that its locally-computed gradient was the result of honest optimization.
  • Shipping any proof system in v0.1–v1.0. Only the proof-ready disciplines (§ Proposed Design, item 3) ship in that line. The Stwo prover, TEE attestation, and the STARK-friendly hash migration are Stage D, post-v1.0, captured as future work per conventions §12 (not filed as implementable issues against v1.0).
  • Replacing secure aggregation or DP. Verifiable contribution is orthogonal to confidentiality: target secure aggregation (RFC-0011) hides individual updates and effective DP (RFC-0012) bounds leakage; a future proof integration would establish that protected updates were aggregated correctly. The current plaintext/replay path supplies neither protection.

Proposed Design

1. Trust model

Phase Coordinator / aggregator Participants What protects raw data What gives integrity
Phase 1 target honest-but-curious honest, may drop out raw-data residency plus secure aggregation + effective DP for released updates (RFC-0011, RFC-0012); current runtime has residency only, with plaintext updates and replayable noise provenance commitments (RFC-0014) give tamper-evidence; aggregation integrity is assumed
Phase 2 may be malicious; misbehavior detectable may misreport; binding makes it detectable unchanged aggregation correctness proven (STARK); provenance binding proven (Merkle); committed-model alignment diagnostic publicly recomputable; participant-side backstop attested/proven or trusted-boundary executed; inner step TEE-attested

In Phase 1, honest contribution is assumed. In Phase 2, honest contribution becomes verifiable. The transition is additive: Phase-2 mechanisms attach to the Phase-1 commitments and determinism without changing the protocol of RFC-0003. The security spec consolidates the residual trust assumptions per phase (06-security.md).

2. The provable surface (and what stays cheap)

Each claim is backed by exactly one mechanism, with its honest cost and the residual assumption stated.

Claim Mechanism Cost / residual assumption
Aggregation computed correctly over the submitted deltas STARK over the outer-step circuit (Stwo / Circle-STARK) Tractable — and cheap because the anchored frame (RFC-0002 §4) keeps aggregation a plain weighted average / Nesterov step, i.e. a near-linear operation. This is the synergy: the gauge fix is also the verifiability enabler. Residual assumption: the STARK soundness (post-quantum, transparent setup).
Update derived from committed data Merkle commitment $R_c$ + binding to the update (RFC-0014 §3, INV-COMMIT-BINDING) Cheap. Proves provenance, not quality or honesty of the gradient. Residual assumption: collision resistance of the commitment hash (SHA-256 Phase 1; see item 6).
Committed global model's frame diagnostic correct Public recomputation — a deterministic function of the public probe + committed weights Free. Anyone recomputes the committed model's $Q^\star$/residual. This does not verify a participant-specific pre-release transform. Residual assumption: none beyond INV-PROBE-PIN and INV-CHECKPOINT-HASH.
Participant-specific backstop applied before release Participant attestation/proof, or execution inside the trusted/MPC aggregation boundary (INV-ALIGN-BEFORE-RELEASE) Not free: the action needs raw local weights that a secure sum intentionally hides. Until one mechanism is integrated, participant execution is assumed.
Inner training step executed faithfully TEE attestation (pragmatic proxy) Moderate; a weaker trust than a SNARK but far cheaper than proving training. Residual assumption: TEE hardware/firmware trust.

The claims compose into a single statement per round (item 5): the global model at round $t{+}1$ is the deterministic aggregate of $C$ updates, each bound to a committed dataset root and produced inside its declared attested/trusted boundary; the committed model's frame diagnostic is publicly recomputable. The strength of that statement is exactly the weakest link, which is why participant-side alignment is not collapsed into the public diagnostic.

2.1 The synergy with the gauge (why aggregation stays provable)

The outer step (RFC-0002 §8, step 5) is

$$(\theta_{t+1}, \phi_{t+1}) \leftarrow (\theta_t, \phi_t) - \eta_{\text{out}} \cdot \mathrm{OuterOpt}\big(\mathrm{mean}_c\,\Delta_c\big),$$

a weighted average of committed deltas followed by a fixed Nesterov update. Were participants in mutually-rotated coordinate frames (the $O(d)$ gauge of RFC-0002 §2), averaging requires a participant-specific orthogonal alignment $Q_c$ before clip/noise/quantization/masking. A sum-only circuit cannot apply that transform afterward. If the Layer-3 backstop binds, its participant-local execution must be attested/proven or performed inside the trusted/MPC boundary and bound to the submitted aligned delta. The outer-step STARK may still prove only the near-linear sum + Nesterov step; it then proves correct aggregation of submitted aligned releases, not that participants aligned honestly. Keeping the backstop quiet via warm-start + anchor therefore keeps both computation and the integrity statement cheap. Closing the gauge keeps the proof cheap without pretending the hidden participant action is public.

3. Phase-1 proof-ready requirements (cheap to honor now)

Phase 1 MUST bake in the following five disciplines. Each maps to an existing RFC and an INV-* invariant (conventions §7), so the requirement is enforced and tested as part of normal Phase-1 work, not as Phase-2 speculation.

  1. Deterministic aggregation. The outer step (RFC-0003 §7) is a fixed, bitwise-reproducible function of (committed deltas, round seed, prior global params): fixed reduction order, fp32 with fixed summation order (or fp64), no atomics, no nondeterministic reductions on the aggregation path (INV-AGG-DETERMINISM, conventions §9). A determinism self-check runs each outer step in lensemble.aggregation; on mismatch it raises NonDeterministicAggregation (never swallowed; conventions §6) and the round aborts to the ABORTED path of the runtime state machine (RFC-0013), to be recomputed.
  2. Committed model versions. Every $(\theta_t, \phi_t)$ artifact is hash-committed: its content hash equals the hash in the Commitment / RoundClose message (INV-CHECKPOINT-HASH), with a parent_hash chain (RFC-0010 § Proposed Design). The canonical Phase-1 hash is SHA-256 over a canonical byte serialization (conventions §11). On mismatch the artifact loader raises CheckpointIntegrityError; an unknown/too-new schema raises SchemaVersionMismatch.
  3. Episode hashing + Merkle roots from day one. Each participant content-hashes its episodes and commits a Merkle root $R_c$ (RFC-0014, DatasetCommitment) even before proofs exist. Every released $\Delta_c$ is bound to exactly one $R_c$ (INV-COMMIT-BINDING); a mismatch raises CommitmentMismatch (never swallowed) and the update is rejected (RFC-0003 §9).
  4. Pinned public probe. The probe content hash and landmark targets are pinned (RFC-0004 §3, INV-PROBE-PIN); landmark targets $t_i$ derive only from the round-0 reference encoder $f_{\text{ref}}$. The probe hash a participant uses must equal the hash committed in RoundOpen; a mismatch raises ProbeError. Committed-model alignment diagnostics must be recomputable from public inputs; participant-specific pre-release execution is a separate integrity claim.
  5. Reproducible outer step. Fixed seeds and fixed order so a verifier can recompute the claimed aggregation. The round sketch seed is derived deterministically, $s_t = \mathrm{derive}(\text{root_seed}, t)$ (conventions §9), and recorded in the RunManifest (RFC-0009); all participants in round $t$ use the identical projection matrix $A$ from $s_t$ (INV-SKETCH-CONSISTENCY). The warm-start is hash-identical across participants at round 0 (INV-WARMSTART-T0), closing the gauge at $t{=}0$.

These five are inexpensive engineering disciplines in Phase 1 and are the entire prerequisite for Phase 2. They are tested now (item § Testing Strategy); none is deferred.

4. Public recomputation (Phase-1, free, in scope now)

The free Phase-1 surface is public recomputation of the committed global model's frame diagnostic. It is a deterministic, side-effect-free function of public data and committed weights, exposed under lensemble.verify. It deliberately does not verify whether each participant applied the Layer-3 backstop before release:

# lensemble/verify/recompute.py — Phase 1, shipped in v0.1/v0.2.

from pathlib import Path
from lensemble.gauge import FrameDriftReport  # ([conventions §5](../spec/conventions.md#5-public-api-surface))

def recompute_alignment(
    checkpoint: Path,          # committed (θ_t, φ_t) artifact; hash-verified on load (INV-CHECKPOINT-HASH)
    probe: Path,               # pinned public probe P; content-hash checked vs round commitment (INV-PROBE-PIN)
    *,
    reference: Path,           # round-0 reference encoder f_ref (for landmark targets / E_ref)
    expected: "AlignmentClaim | None" = None,  # the coordinator's claimed alignment, if checking
) -> "AlignmentRecomputation": ...

# Result schema (pydantic v2 on-disk record; schema_version: int).

class AlignmentClaim(BaseModel):           # what the coordinator published for round t, per participant pair
    schema_version: int
    round_index: int
    participant_a: str
    participant_b: str
    procrustes_q_hash: str                 # SHA-256 of canonical bytes of Q* (the claimed O(d) alignment)
    procrustes_residual: float             # ‖f_θ(P)·Q* − E_ref‖_F, the residual (RFC-0002 §5)
    rotation_angle_deg: float              # mean principal rotation angle of Q* on P

class AlignmentRecomputation(BaseModel):
    schema_version: int
    round_index: int
    probe_hash: str                        # must equal the RoundOpen commitment, else ProbeError
    recomputed: AlignmentClaim             # locally recomputed from public inputs alone
    matches_expected: bool | None          # None if `expected` was not supplied
    max_abs_residual_delta: float | None   # |recomputed.residual − expected.residual|, within tolerance?

Semantics and contract: - Determinism. recompute_alignment is bitwise-deterministic given (committed weights, pinned probe, reference encoder). It runs the same closed-form Procrustes alignment $Q^\star = VU^\top$ from the SVD $E_{\text{ref}}^\top f_\theta(\mathcal{P}) = U\Sigma V^\top$ (RFC-0002 §4 Variant B / §5) on the fp32 / fp64 path (conventions §9). Anyone with the public probe and committed global weights reproduces this diagnostic; no ZK proof is required for the diagnostic. A participant-specific pre-release transform still requires attestation/proof or a trusted execution boundary (INV-ALIGN-BEFORE-RELEASE). - Preconditions. The checkpoint hash is verified on load (INV-CHECKPOINT-HASH); the probe content hash is checked against the round commitment (INV-PROBE-PIN). A near-degenerate SVD raises DegenerateProcrustes; the routine clamps/conditions singular values per RFC-0002 §4 before reporting. - Errors raised (conventions §6): CheckpointIntegrityError (hash mismatch on the committed weights), ProbeError (probe hash mismatch / under-coverage), DegenerateProcrustes (ill-conditioned alignment), SchemaVersionMismatch (unknown/too-new claim record). - CLI surface. lensemble verify recompute --checkpoint <path> --probe <path> --reference <path> [--expected <claim.json>] emits an AlignmentRecomputation JSON and exits non-zero if matches_expected is False. The companion lensemble verify prove is a Phase-2 stub that raises NotImplementedError with a remediation string pointing to Stage D (conventions §5).

5. The composed trust statement (per roadmap stage)

Each Stage-D substage adds one mechanism and tightens the composed statement. State which parts are proven (P), attested (A), or assumed (Z):

Substage Aggregation Provenance binding Frame alignment Inner step Composed statement
Phase 1 (v0.1–v1.0) Z (deterministic + recomputable) Z (tamper-evident) Z for participant action; P only for committed-model diagnostic Z "Honest if the coordinator and participants are honest; the committed-model diagnostic is detectable, but participant pre-release alignment is assumed."
2a P (STARK) Z Z/P as above Z "Aggregation provably correct over submitted deltas; participant alignment, provenance, and inner step assumed."
2b P P (Merkle binding) Z/P as above Z "Each update provably bound to a committed dataset root; aggregation provably correct; participant alignment and inner step assumed."
2c P P A when included in the attested participant/TEE boundary; P for diagnostic A (TEE) "Inner step and pre-release alignment attested by the declared boundary; aggregation and binding proven; committed-model diagnostic recomputable."
2d (research) P P toward P for participant action toward P "Push participant computation from attested toward proven as prover capability improves."

6. Commitment-hash migration (open, deferred)

The canonical Phase-1 commitment hash is SHA-256 (conservative, interoperable; conventions §11). A Circle-STARK over the aggregation circuit (substage 2a) is far cheaper when commitments use a STARK-friendly hash (e.g. Poseidon2). The Phase-1 commitment format (RFC-0014, RFC-0010) records the hash function as a versioned choice so the migration is a schema_version bump rather than a format break; readers reject an unknown hash id with SchemaVersionMismatch. The migration itself is an Open Question (below), owned by @AbdelStark, resolved in Stage D.

7. Roadmap

  • 2a — aggregation-correctness STARK (Stwo) over the committed deltas → committed global model.
  • 2b — provenance binding: tie each update to its dataset Merkle root (RFC-0014).
  • 2c — TEE attestation for the inner step; define the composed trust statement (item 5) over which parts are proven vs attested vs assumed.
  • 2d (research) — push toward heavier proof-of-training / proof-of-learning as prover capability improves; benchmark prover cost (Stwo) against circuit size as the model scales from ViT-L toward the 1.2 B target.

8. Failure modes (Phase-1 surface)

Trigger Detection Error raised (conventions §6) System response
Outer step not bitwise reproducible per-step determinism self-check (RFC-0003 §7) NonDeterministicAggregation abort round to ABORTED; recompute; never swallowed (security-critical)
Recomputed committed-model diagnostic ≠ published claim recompute_alignment(..., expected=...) returns matches_expected=False none (returns a record) CLI exits non-zero; the diagnostic claim is rejected; this says nothing about participant-side backstop execution
Participant-specific backstop cannot be verified across a secure-sum-only boundary information-flow preflight (INV-ALIGN-BEFORE-RELEASE) ConfigError in the current coordinator harness require participant attestation/proof or execute alignment inside the trusted/MPC boundary
Probe hash ≠ RoundOpen commitment INV-PROBE-PIN check on load ProbeError reject; recomputation aborts
Committed weights hash mismatch INV-CHECKPOINT-HASH check on load CheckpointIntegrityError reject artifact; do not aggregate
$\Delta_c$ not bound to a single $R_c$ binding check (RFC-0014) CommitmentMismatch reject update; never swallowed (security-critical)
Near-degenerate SVD in alignment conditioning check (RFC-0002 §4) DegenerateProcrustes clamp/condition; report; if still ill-conditioned, fail closed
lensemble verify prove invoked in Phase 1 stub guard NotImplementedError (remediation → Stage D) exit non-zero with a clear message

Alternatives Considered

SNARK vs Circle-STARK (Stwo) for the aggregation proof. What it is: a succinct proof of the outer-step circuit; SNARKs (pairing-based, trusted setup) vs transparent STARKs (FRI/Circle-STARK, no trusted setup, post-quantum). Why considered: SNARKs have smaller proofs and faster verification. Why rejected (for now): SNARKs require a trusted setup (a trust assumption Lensemble is trying to remove) and are not post-quantum; the "Half-Life of Trust" argument favors transparent, post-quantum proofs for a long-lived federation. Circle-STARK (Stwo) is transparent and post-quantum, and the near-linear aggregation circuit (item 2.1) is exactly the regime where a STARK is practical. The choice is revisited in 2d if prover cost dominates.

Prove everything vs the layered model. What it is: a single end-to-end proof of the entire round (inner training + aggregation) vs the layered "TEE-attested inner step + commitment-bound provenance + STARK-proven aggregation." Why considered: a single proof would give the strongest statement. Why rejected: proving a full 1.2 B training step in zero knowledge is infeasible today (Non-Goals). The layered model puts the cheapest sufficient mechanism behind each claim — free recomputation for the committed-model diagnostic, a small STARK for near-linear aggregation, a Merkle binding for provenance, and a TEE/attestation for the heavy data-touching inner step including any participant alignment — and composes them into one honest statement (item 5).

TEE-only (attest the whole round) vs proof-backed aggregation. What it is: run the entire round inside an enclave and rely on remote attestation for everything. Why considered: simplest to deploy; one trust primitive. Why rejected (as the sole mechanism): a TEE is a weaker assumption than a STARK (it trusts hardware/firmware and is vulnerable to side channels), and attestation does not give a third party a transferable, post-quantum proof. Lensemble reserves the TEE for the inner step (where proof is infeasible) and uses a STARK for the aggregation (where proof is cheap), so the strongest available guarantee backs each claim.

Drawbacks

  • Proving full training in ZK is infeasible today. The inner step rests on the TEE assumption (substage 2c), which is strictly weaker than a SNARK/STARK. We state this rather than imply a proof-of-training that does not exist.
  • Provenance proves origin, not honesty. The Merkle binding attests which committed dataset an update came from — not that the data is good or the gradient was honestly computed. Stating this boundary is part of the design's integrity (RFC-0004 §4, RFC-0014).
  • TEE trust. TEE attestation depends on hardware and firmware trust and a current attestation root; it is a pragmatic proxy, not a cryptographic proof of computation.
  • Hash migration debt. SHA-256 is conservative but not STARK-friendly; the eventual migration to a STARK-friendly hash (item 6) is real work, deferred to Stage D, and could force re-commitment of historical roots if not designed as a versioned, additive change.
  • Phase-1 cost of discipline. Bitwise-deterministic aggregation forecloses some fast nondeterministic reductions on the aggregation path (conventions §9); the performance budget (08-performance-budget.md) accounts for this as a deliberate constraint, justified by proof-readiness.

Migration / Rollout

The rollout is the roadmap (item 7), gated stage by stage. The Phase-1 disciplines (item 3) land first and are non-negotiable for v0.1–v1.0:

  • v0.1 (Stage A) and v0.2 (Stage B): the five proof-ready requirements (deterministic aggregation, committed model versions, Merkle roots, pinned probe, reproducible outer step) ship and are tested. The free committed-model diagnostic (recompute_alignment, lensemble verify recompute) ships. lensemble verify prove is a stub that raises NotImplementedError.
  • v0.3 (Stage C): the disciplines operate over a real network boundary with real secure aggregation and DP; participant alignment moves before the release pipeline (INV-ALIGN-BEFORE-RELEASE), and the ContributionLedger (RFC-0014) is populated. No proofs yet; participant execution remains assumed.
  • v1.0: proof-ready guarantees verified end-to-end (this RFC's item 3, the conventions §12 v1.0 row): the determinism check, the public recomputation, the commitment binding, and the pinned probe are all exercised in the reproducibility package.
  • Post-v1.0 (Stage D, Phase 2): substages 2a → 2b → 2c → 2d, each additive and each gating the next. The commitment-hash migration (item 6) is sequenced before 2a so the STARK circuit is cheap. These are tracked as future work (conventions §12), not filed as v1.0 issues.

No Phase-2 substage changes the RFC-0003 protocol or the RFC-0014 commitment format beyond a versioned hash-id bump; that is the meaning of "no rework."

Testing Strategy

Phase-1 proof-readiness is in scope now; these tests run in CI (CPU, tiny synthetic fixtures — conventions §9):

  • Aggregation determinism (INV-AGG-DETERMINISM). Run the outer step twice on identical inputs (committed deltas, round seed, prior global params); assert bitwise-equal results. Inject a nondeterministic reduction and assert NonDeterministicAggregation is raised and the round aborts (RFC-0003, RFC-0011 interaction). Exact equality required.
  • Public committed-model alignment diagnostic. recompute_alignment reproduces the committed model's diagnostic from the public probe + committed weights to within fp32/fp64 tolerance; assert matches_expected=True for an honest claim and False for a perturbed claim. This test must not be described as verification of participant-side backstop execution.
  • Alignment information-flow guard. A coordinator-side participant-specific backstop rejects DP-enabled, quantized, or sum-only-backend configurations and release-transformed updates (INV-ALIGN-BEFORE-RELEASE).
  • Commitment binding (INV-COMMIT-BINDING). An update bound to the wrong root is rejected with CommitmentMismatch; the correct binding round-trips (RFC-0014).
  • Pinned-probe (INV-PROBE-PIN). A probe whose content hash differs from the RoundOpen commitment raises ProbeError; landmark targets derive only from $f_{\text{ref}}$.
  • Checkpoint integrity (INV-CHECKPOINT-HASH). Tampering with committed weights is detected as CheckpointIntegrityError on load before aggregation (RFC-0010).
  • Degenerate alignment. A synthetically rank-deficient probe embedding raises DegenerateProcrustes (or is clamped within tolerance), never silently producing a garbage $Q^\star$ (RFC-0002 §4).
  • Stub guard. lensemble verify prove raises NotImplementedError with a Stage-D remediation string; the CLI exits non-zero.
  • CLI exit-code contract. lensemble verify recompute exits zero on an honest claim, non-zero on a mismatched one (consumable by CI / a verifier).

Phase-2 proof tests (Stwo circuit correctness, TEE attestation round-trips, Poseidon2 hash equivalence) are Stage D and are not in the v0.1–v1.0 suite.

Open Questions

OPEN QUESTION: Migrate the Phase-1 commitments from SHA-256 to a STARK-friendly hash (e.g. Poseidon2) to keep the substage-2a proof circuit cheap, without breaking the Phase-1 commitment format. Owner: @AbdelStark. Resolution path: a versioned hash-id field in RFC-0014 / RFC-0010 commitment headers (shared with RFC-0014 and the conventions §11 open question); decided in Stage D before substage 2a.

OPEN QUESTION: Prover cost vs circuit size as the model scales from ViT-L toward the 1.2 B target — does the Stwo aggregation proof stay tractable when $\Delta_c$ grows, or must the aggregation be proven over a compressed/quantized delta (interacting with the int8 pseudo-gradient quantization of RFC-0003)? Owner: @AbdelStark. Resolution path: benchmarked in roadmap substage 2d (Stage D, research).

OPEN QUESTION: The TEE attestation root and the precise inner-step measurement to attest (whole inner loop vs a measured training kernel) for substage 2c — what is attested, and how is the attestation bound to the committed $(\theta_t, \phi_t)$ and $R_c$? Owner: @AbdelStark. Resolution path: follow-up RFC superseding this section's item 5, scoped in Stage D.

DECIDED DIRECTION: When the Layer-3 Procrustes backstop (RFC-0002 §5) binds, it must execute participant-side before clip/noise/quantization/masking or inside a trusted/MPC boundary. A secure sum cannot make that participant-specific action publicly recomputable. The remaining Stage-D choice is whether to attest the action with the inner step or prove it/bind it in a larger circuit; the near-linear outer STARK may continue to prove only aggregation of the already-aligned releases.

RISK: The Phase-2 design rests on the aggregation circuit staying near-linear (item 2.1), which in turn rests on the frame anchor keeping the Layer-3 backstop quiet. If the gauge proves hard to control at video-WM scale (RFC-0002 §7 and Open Questions), the aggregation circuit grows and the low-cost proof target weakens. Resolution plan: the Stage-B frame-drift sweep quantifies backstop frequency before any Stage-D proof work begins; if drift is severe, the Fork-A fallback (RFC-0002 — Fork A fallback) dissolves the gauge entirely and the aggregation is linear (a frozen-encoder predictor average), preserving the simpler proof target while narrowing the research scope to predictor federation.

References