Skip to content

Controlled v0 launch lanes and secure compute intake#270

Merged
wallscaler merged 1 commit into
mainfrom
feat/tee-gpu-capacity
Jun 22, 2026
Merged

Controlled v0 launch lanes and secure compute intake#270
wallscaler merged 1 commit into
mainfrom
feat/tee-gpu-capacity

Conversation

@wallscaler

@wallscaler wallscaler commented Jun 19, 2026

Copy link
Copy Markdown
Contributor

Summary

Adds a controlled Cathedral v0 launch path across three lanes:

  • Audit Arena: SAT-backed miner witnesses, explicit submission schema, deterministic replay, provenance binding, and private distillation trace capture.
  • Secure Compute: default-off TEE/GPU intake with signed consent, evidence requests, cryptographic verifier hook, GPU claim matching, provider/health/usage receipts, and strict separation from validator emissions.
  • Distillation: private-by-default verifier traces with public export redaction/disclosure gates.

This PR intentionally separates two launch profiles:

  • controlled-v0: launchable at 91/100 with real secure-compute proof gates deferred. Secure Compute is intake/waitlist/operator-gated only.
  • full: not ready until a real TEE GPU machine completes verifier acceptance plus bad-evidence rejection, provider listing, health, and usage/revenue receipts.

Important boundary

Do not ask miners broadly to buy or rent hardware from this PR alone.

The controlled v0 can launch without the real GPU proof loop only because the missing gates are explicit and deferred:

  • compute_real_verifier_tested
  • compute_provider_listing_verified
  • compute_health_and_revenue_verified

The miner-facing announcement says Secure Compute is controlled only and that miners should not buy/rent compute unless Cathedral publishes an exact accepted profile and opens the lane.

Main changes

  • Adds scaffold/launch_readiness.py plus launch_readiness_report.py and launch_readiness_verify.py.
  • Adds CATHEDRAL_TEE_GPU_REAL_VERIFIER_DIGESTS; fixture verifier receipts do not count as production launch evidence unless the command digest is allowlisted.
  • Passes capacity.json into the TEE/GPU verifier and requires gpu_claims_match or equivalent GPU model/count checks.
  • Records verifier command digests in success/failure evidence events.
  • Adds provider, health, and usage/revenue receipt gates before capacity can be treated as production-ready.
  • Keeps compute rows out of eval_runs, lane_challenge_solves, per_miner_solves, and emissions.
  • Adds row_score_recent with an explicit task-type allowlist and visible proportional fallback metadata.
  • Adds Audit Arena schema/provenance/replay docs and tests.
  • Adds distillation redaction and disclosure gates.
  • Adds launch docs, scorecard, runbook, checklist, risk register, and announcement draft.

Claude review

Claude reviewed the branch for launch blockers and found no critical/high/medium issues. Four low hardening notes were addressed:

  • route smoke tests now fail visibly instead of silently skipping when FastAPI is unavailable
  • provider-status row update and event recording are atomic
  • attestation verify now binds the authenticated hotkey to the issued nonce owner
  • DCAP collateral seam documents that production verifiers must fetch or pin their own Intel trust roots

Validation

Passed locally:

  • python3 launch_readiness_verify.py — 19 checks
  • python3 launch_readiness_report.py --profile controlled-v0 --require-ready — READY, 91/100, three compute gates deferred
  • python3 launch_readiness_report.py --require-ready — expected nonzero, full profile NOT READY at 91/100
  • python3 weights_verify.py — 16 checks
  • python3 tee_gpu_verify.py
  • python3 attest_verify.py
  • python3 audit_arena_verify.py — 27 checks
  • python3 distillation_verify.py — 15 checks
  • python3 arena_runner_verify.py — 8 checks
  • python3 rc_verify.py — 37 checks, one expected skip for missing real solver
  • python3 -m py_compile scaffold/publisher/app.py scaffold/publisher/attest.py scaffold/publisher/tee_gpu.py scaffold/publisher/weights.py scaffold/launch_readiness.py scaffold/distillation.py scaffold/lanes/audit_arena.py launch_readiness_report.py
  • git diff --check
  • changed-file secret scan; only fake test bearer tokens and placeholder docs matched

Attempted but environment-blocked:

  • python3 publisher_verify.py fails because bittensor_wallet is not installed in this local WSL runtime.
  • python3 postgres_verify.py requires a real DATABASE_URL.

Operator launch command

Controlled v0 readiness:

python3 launch_readiness_report.py --profile controlled-v0 --require-ready

Full hardware launch readiness:

CATHEDRAL_TEE_GPU_REAL_VERIFIER_DIGESTS=<approved-real-verifier-digest> \
python3 launch_readiness_report.py --db <publisher.db> --require-ready

Hardening update after Claude review loop

Additional Claude review passes found and the branch now fixes:

  • row_score_recent now only consumes attested=1 rows and preserves coldkey-collapse splitting.
  • Naive ISO timestamps are treated as UTC in publisher clock-skew checks.
  • /v1/attest/nonce fails closed on missing/empty miner_pubkey_b64.
  • TEE offer signatures remain bound to node_id plus payload digest; unbound fallback shapes are not accepted for mutating compute intake.
  • Chutes/provider listing commands are not emitted unless evidence is cryptographically_verified.
  • Evidence verifier command template errors, including positional placeholders such as {0}, return structured 400s.
  • Provider CLI OSError paths become structured list_failed events instead of unhandled 500s.
  • Execute listing uses an atomic listing claim, and stale claims can only be reclaimed after provider CLI timeout plus margin.
  • Tier parsing is restricted to known Cathedral tiered lane prefixes (sat, audit, pm) so arbitrary ids containing -t2- do not change emissions.

Latest validation after hardening:

  • python3 tee_gpu_verify.py
  • python3 weights_verify.py — 18 checks
  • python3 attest_verify.py
  • python3 launch_readiness_verify.py — 19 checks
  • python3 launch_readiness_report.py --profile controlled-v0 --require-ready — READY, 91/100
  • python3 launch_readiness_report.py --require-ready — expected failure, full profile NOT READY
  • python3 audit_arena_verify.py — 27 checks
  • python3 distillation_verify.py — 15 checks
  • python3 arena_runner_verify.py — 8 checks
  • python3 rc_verify.py — 37 checks, one expected real-solver skip
  • python3 -m py_compile ...
  • git diff --check

Dashboard wording update

The operator dashboard copy now mirrors the stricter code gate: Cathedral preflights capacity, requires cryptographic TEE/GPU evidence, and only then emits provider handoff commands. Blocked, non-consented, or unverified rows are explicitly described as commandless.

Additional validation:

  • python3 tee_gpu_verify.py
  • python3 -m py_compile scaffold/publisher/tee_gpu.py
  • python3 launch_readiness_report.py --profile controlled-v0 --require-ready
  • git diff --check

No-hardware launch update

Latest commits add the explicit no-hardware-v0 / intake-v0 readiness path. It aliases to controlled-v0: Audit Arena and distillation can launch, while Secure Compute remains intake/waitlist/operator-gated until real verifier/provider/health/revenue evidence exists.

CI hardening added in this update:

  • httpx2>=2 is now included in the publisher extra for FastAPI/Starlette TestClient compatibility.
  • publisher_verify.py now starts tuple-cursor pagination from an explicit old cursor instead of asking the feed for newest-first rows.
  • postgres_verify.py now asserts provider listing is blocked before cryptographic evidence, then verifies the successful crypto-evidenced dry-run path on Postgres.

Current GitHub Actions status on da20f44:

  • launch-readiness / verify passed on the PR run.
  • launch-readiness / verify passed on the branch push run.

Required-checks update

The branch now includes .github/workflows/required-checks.yml so the repo ruleset-required contexts exist and run on PRs:

  • CodeQL
  • Analyze Python
  • leak-guard

Current merge state on 6a5553a: MERGEABLE / CLEAN; all required checks and launch-readiness checks pass.

Claude review loop update

Claude reviewed the current branch for no-hardware-v0 launch blockers. It raised one high concern that provider execution might run without cryptographic evidence. The cited path was rechecked against the code: list_capacity_on_chutes() starts with blockers from chutes_manifest_item(), and chutes_manifest_item() already adds cryptographic_attestation_required unless evidence is cryptographically_verified.

Follow-up changes from the review:

  • Strengthened tee_gpu_verify.py to prove that execute=True remains blocked without cryptographic evidence even when CATHEDRAL_TEE_GPU_CHUTES_EXECUTE_ENABLED=1 is set.
  • Added explicit doc language that listed candidate profiles are not open for purchase yet and are not purchase instructions.

Current status on a1ef2a3:

  • launch-readiness / verify passed.
  • CodeQL passed.
  • Analyze Python passed.
  • leak-guard passed.
  • PR merge state is expected to be clean after the latest checks settle.

@wallscaler wallscaler changed the title Add TEE GPU capacity intake lane Add TEE GPU capacity intake and Chutes listing pipeline Jun 19, 2026
@wallscaler wallscaler changed the title Add TEE GPU capacity intake and Chutes listing pipeline Add authorized TEE GPU capacity intake and provider listing pipeline Jun 19, 2026
@wallscaler wallscaler changed the title Add authorized TEE GPU capacity intake and provider listing pipeline Controlled v0 launch lanes and secure compute intake Jun 20, 2026
@wallscaler wallscaler marked this pull request as draft June 20, 2026 22:52
@wallscaler wallscaler marked this pull request as ready for review June 20, 2026 23:52
@wallscaler wallscaler force-pushed the feat/tee-gpu-capacity branch from a1ef2a3 to 93f3c4c Compare June 22, 2026 20:41
@wallscaler wallscaler merged commit a7feb93 into main Jun 22, 2026
9 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant