v4.0.0-rc.6-v2-bitset-submit-beta

v4.0.0-rc.6-v2-bitset-submit-beta

Prerelease candidate for Cathedral V2 PM-native bitset submit beta.

Code commit deployed to V2 beta: ed1b9ec Fix V2 bitset scoring review findings

Summary

This prerelease is preparation for the future V2 submit path. It is ready for miner testing on the V2 beta service, but it does not change current rewards, payouts, or V1 validator weights.

This release adds an isolated V2 submit path for PM SAT that avoids full DIMACS solution bodies in the hot path.

miner fetches V2 per-miner challenge + submit_token
miner solves CNF locally
miner submits tiny signed bitset assignment
V2 verifies token/signature/assignment cheaply
V2 records a verified shadow event
V2 shadow weights include the verified event

No current V1 rewards, payouts, or validator weights are affected.

Ready for testing

Miner-facing test note:

docs/V2_BITSET_READY_FOR_TESTING.md

Quick smoke:

python3 scripts/v2_bitset_miner_e2e.py \
  --base https://v2-beta.cathedral.computer \
  --limit 1

Expected success:

E2E_OK
status=verified
shadow_weight=1.0

This is a V2 shadow/beta protocol test only. It prepares miners and Cathedral for future V2 work submission, but it is not yet a production reward path.

New beta endpoints

POST /v2/agents/submit-bitset
GET  /v2/agents/submit-bitset/receipts/{receipt_id}

Existing V2 per-miner challenge endpoints now expose bitset-submit metadata when enabled:

GET /v2/synthetic-boolean/per-miner/challenges
GET /v2/synthetic-boolean/per-miner/cnf

New beta env vars

CATHEDRAL_V2_SUBMIT_BITSET_ENABLED=true
CATHEDRAL_V2_SUBMIT_TOKEN_SECRET=<secret>
CATHEDRAL_V2_SUBMIT_TOKEN_TTL_SECS=300

Keep V2 isolated as before:

CATHEDRAL_V2_ENABLED=true
CATHEDRAL_V2_DATABASE_URL=<separate-v2-db>
CATHEDRAL_V2_PERMINER_ENABLED=1

Anti-cheat properties

V2 bitset submit admits only cheap-valid submissions:

• submit token is HMAC-bound to hotkey, challenge, epoch, tier, seq, nvars, CNF hash, and expiry
• hotkey signs the canonical bitset submit body
• assignment must be bitset/v1 with exact byte size and zero trailing bits
• assignment is evaluated against the miner's deterministic CNF before a durable event is written
• payload is inline and signed, so there is no post-submit mutation path
• scoring time uses Cathedral receive time, not miner clock

Invalid shape/token/signature/witness submissions are rejected before a v2_submit_events row is written.

Review-fix notes:

• V2 shadow scoring dedupes by (miner_hotkey, challenge_id) across manifest and bitset sources, preferring bitset events so one PM challenge cannot double-count.
• V2 audit bundles include both manifest receipts and bitset events with source-tagged status counts.
• /v2/agents/submit-bitset is covered by the submit hot-path gate and has an explicit small body cap before JSON parsing.

Load-test finding carried forward

Earlier V2 live-adjacent probes found:

• full-body V1 shadow storage overloaded the beta target around ~1% sample
• metadata-only live shadow held at 100% live submit traffic

Conclusion: PM V2 should use tiny bitset submits, not full-body solution ingestion.

New scripts

scripts/v2_bitset_miner_e2e.py

Runs the miner-facing bitset flow against V2 beta and verifies shadow weights.

Verification

Review/fix loop completed for the reported scoring/audit/backpressure findings.

Local checks:

py_compile passed
65 passed

Live beta E2E after review fixes:

python3 scripts/v2_bitset_miner_e2e.py --base https://v2-beta.cathedral.computer --limit 1 --solver cadical153

E2E_OK
receipt_id=5134b754-acce-4645-a73e-75d902e4ee80
status=verified
shadow_weight=1.0
raw_score=1.0
admit_ms=193.0

Live audit check:

/v2/audit/epochs/495232
count=1
status_counts={"bitset:verified": 1}
has_receipt=true

Live health after deploy:

V1 submit: 200
V1 api_ready: 200
V1 weights: 200
V2 live: 200
V2 shadow metadata probe: last_1m.count=0

Config verified on cathedral-v2-beta:

CATHEDRAL_V2_DATABASE_URL: set
CATHEDRAL_V2_SUBMIT_TOKEN_SECRET: set
CATHEDRAL_V2_SUBMIT_BITSET_ENABLED=true
CATHEDRAL_V2_SUBMIT_TOKEN_TTL_SECS=300

Non-goals

• No V1 reward changes
• No V1 validator weight changes
• No live chain RPC in submit admission
• No full DIMACS body storage in the PM V2 hot path

Rotation reminder

Cloudflare/Railway/Hippius tokens pasted during development should be rotated.

Cathedral v4.0.0-rc.5 V2 Manifest Beta

Cathedral v4.0.0-rc.5-v2-beta

This is a V2 manifest beta prerelease for miner E2E testing.

V2 is isolated and shadow-only: it does not affect current V1 production validator weights, rewards, emissions, or payout state.

What changed

• Added isolated V2 blob-backed solution manifest lane.
• Added V2 per-miner challenge/CNF endpoints.
• Added optional beta blob upload endpoint so miners do not need Hippius accounts for testing.
• Added async verifier path for signed manifests.
• Added V2 verified receipts, shadow weights, and epoch audit bundles.
• Added V2-prefixed environment configuration to avoid mixing with current production lane.
• Added miner E2E helper script and public guide.

Miner beta endpoint

Preferred clean beta URL:

https://v2-beta.cathedral.computer

Operators should verify DNS is active before announcing the beta URL broadly.

Miner E2E quick start

python3 -m pip install requests bittensor-wallet python-sat
python3 scripts/v2_miner_e2e.py --base https://v2-beta.cathedral.computer

Wallet-file style:

python3 scripts/v2_miner_e2e.py \
  --base https://v2-beta.cathedral.computer \
  --wallet-name <wallet> \
  --hotkey <hotkey>

Expected final line:

E2E_OK ... "status":"verified", "weight":1.0

Guide:

docs/V2_MINER_E2E_GUIDE.md

Do miners need Hippius accounts?

No. For this beta, miners can upload solution bytes to:

POST /v2/blobs/solutions

Cathedral returns a local://solution/... CID that can be used in the signed manifest.

Future modes can support miner-hosted Hippius/IPFS/R2/HTTPS blobs, but the protocol only requires a fetchable solution_cid plus matching solution_sha256.

V2 endpoints

GET  /v2/synthetic-boolean/per-miner/challenges
GET  /v2/synthetic-boolean/per-miner/cnf
POST /v2/blobs/solutions
POST /v2/agents/submit-manifest
GET  /v2/agents/submit-manifest/receipts/{receipt_id}
GET  /v2/validator/weights/next
GET  /v2/audit/epochs/{epoch}

Verified beta smoke

A live V2 E2E smoke succeeded against the beta Railway service:

• fetched V2 PM challenge
• fetched V2 CNF
• solved locally
• uploaded bitset/v1 solution blob
• submitted signed manifest
• receipt became verified
• V2 shadow weights included test hotkey with weight=1.0
• V2 audit bundle included the receipt

Example receipts from smoke tests:

0fdf891c-696e-4fb8-ad63-acf1c0b3f64d  # ephemeral key
bdb65013-9ca2-451e-ad07-d1657961c08a  # local wallet-file hotkey

Safety notes

• This is a prerelease beta.
• V2 weights are shadow-only under /v2/validator/weights/next.
• V1 /v1/validator/weights/next is unchanged.
• Current production submit path is unchanged.
• Current rewards/payout DB mutation is not part of this release.
• Rotate any development tokens used during beta setup before production use.

v4.0.0-rc.4 — a leaner, fairer engine for verifiable compute

Cathedral v4 — a leaner, fairer engine for verifiable compute

Cathedral rewards one thing almost nothing else in crypto can: computation you don't have to trust. Every answer the network pays for is checked against the problem itself — a certificate, not a promise. The monolith proved that model live and at scale. v4 takes the next step: it distills everything we learned into a smaller, more flexible engine, and rearchitects scoring to reward live work more fairly.

Distilled — a tenth the size

The monolith proved the model in production. v4 distills it: ~46,000 lines become ~5,000, with no loss of capability. Fewer moving parts, a codebase one engineer can hold in their head and evolve in an afternoon — exactly what you want on a subnet securing real value.

Four lanes, one substrate

SAT is the substrate of formal verification — the same class of problem used to prove chips correct, protocols secure, and safety-critical systems sound. v4 turns it into a live, competitive, independently-checkable market:

• Lane A — community solve (live). Miners race certificate-checked SAT challenges; every accepted answer is re-verified clause-by-clause before it scores.
• Lane S — solver arena. King-of-the-hill: agents submit solver improvements that must beat the reigning champion on verified wall-clock.
• Lane I — breaker instances. Adversaries surface genuinely hard problems and keep the benchmark honest, paid only when hardness is proven.
• Lane F — frontier fleet (designed). Cubes of real open problems become premium challenges.

Scoring, rearchitected — fairer and more flexible

Scoring now lives in one place: the orchestrator composes each miner's final weight — recency, multi-challenge blend, burn — into a single signed number; validators verify the signature and apply it.

• Fairer. A trailing recency window means weight follows your live work.
• More flexible. Recency, burn rate, work-proportional pay, future challenge types — every scoring change ships orchestrator-side, with no validator release required.
• Auditable. The per-solve feed stays public and independently re-checkable — the receipt for every score.

For validator operators — same flow as always

Updating is the muscle memory you already have — pip install, migrate, serve:

git fetch && git checkout v4
pip install -e .
cathedral-validator migrate          # no-op in v4 (no local database)
cathedral-validator serve --config config/validator.toml --dry-run --once   # test
cathedral-validator serve --config config/validator.toml                    # go live

Pin Cathedral's signing key in your config (public_key_hex, verify it at /.well-known/cathedral-jwks.json). Same serve command and systemd unit you already run; the thin validator runs underneath. Same signing key as before — no identity change. Adoption is incremental; the network already converges as stake-weighted-majority validators relay the same signed vector. Full guide: VALIDATOR.md.

Maturity

The orchestrator is live in production on api.cathedral.computer. The validator is new — its verify / burn / rollback-fence logic is covered by the release gates (publisher_verify.py 83/83) and exercised against the live mainnet vector. Run it --dry-run, or alongside your current validator, until you've confirmed its output, then go live.

v2.1.0 — Omakase scoring foundation

v2.1.0 — Omakase

Honest, open SAT. Anyone who can solve, earns.

This release turns the SAT lane from a closed, winner-take-all board — where only an insider holding the planted witness could win — into an open, tier-aware competition scored on recent performance, with an auto-stocked supply pipeline and Sybil-resistant scoring.

+8,750 / −479 across 58 files, 17 commits since v2.0.1.

Scoring (the core rework)

• PAR-2 scoring core + submit hardening (#256, +1,450/−59) — rank-based, budget-split merit adapted from the SAT-competition metric. Sybil-resistant: ranking is over distinct operators (coldkeys), so splitting one miner into many hotkeys yields zero extra merit. Adds schema-v6 signed facts, extracts EvalSigner to a neutral module, and runs PAR-2 in shadow on the validator (divergence logged, not yet driving weights — the chain flip stays gated).
• Tier-aware, multi-active scoring (#247, with #236/#241) — multiple challenges live at once (one per tier), tier-weighted, with batch promotion.
• Recent-window weighting — SAT-only emissions scored on a rolling 1-day window, so stale/inactive miners decay off and current work is what pays.
• Local scoring is the default (Path A); the signed remote weight-vector is explicit opt-in.

Challenge supply & open-window board

• Generator client + import flow (#238) — the publisher leases CNF challenges from the Cathedral generator.
• Autopilot loop (#240) — keeps the board stocked to target depth automatically.
• Open-window scoring — every valid solver of a challenge is recorded and scored, not just the first.
• Auto-promote next pending after a win (#235) — slots refill instead of going dark.
• Recent-wins endpoint (#234) — solved-challenge visibility for miners.

Anti-gaming / hardening

• Per-hotkey submit rate limit + signature-replay dedup (#256) — blunts the tight-poll / proximity advantage and closes the skew-window replay hole.

Solutions & data

• Raw DIMACS solutions retained (#243, #242).

Umbrella & housekeeping

• Cathedral V3: Omakase integration umbrella (#254).
• cathedral-runtime image deprecated in docs (#219) · Releases link on masthead (#220) · CI bump (#163) · SAT miner-onboarding docs sharpened.

For validators

Update to v2.1.0 — this is the build Cathedral runs in production.

1. git fetch && git checkout v2.1.0
2. pip install -e .
3. cathedral-validator migrate, then restart serve

Default is local scoring (Path A) — no remote-weight config needed.

For miners

The board is open: solvable random_3sat challenges on tiers 1–2 (any competent CDCL solver can win), plus a standing SHA-256 preimage "prestige" tier 3. Every valid solve is recorded; you're scored on recent activity.

Included PRs

#163 · #219 · #220 · #234 · #235 · #236 · #238 · #240 · #241 · #242 · #243 · #244 · #247 · #254 · #256

Built on main @ 650dec6.

v2.0.1 - Apache-2.0 and 85% burn reserve

Date: 2026-05-27

This is the validator-policy patch after the v2.0.0 SAT cutover. It
keeps the SAT-only miner path live while making the repository license
more standard for commercial and research reuse and moving the mainnet
burn reserve to 85%.

What changed:

• The repository license changed from MIT to Apache-2.0.
• Cathedral validators stamp Bittensor set_weights calls with
  version_key=2000001.
• Mainnet config now sets forced_burn_percentage = 85.0.
• Publisher signed-weight defaults and env fallback now use
  CATHEDRAL_WEIGHT_POLICY_FORCED_BURN_PERCENTAGE=85.0.
• Documentation and validator guardrail tests now reflect the 85%
  burn reserve.

What did not change:

• SAT remains the live miner lane.
• Public challenge discovery remains available at
  GET /v1/synthetic-boolean/current-challenge,
  GET /v1/synthetic-boolean/current-challenge?tier=N, and
  GET /v1/synthetic-boolean/active-challenges.
• Public endpoints still do not expose tokenized CNF URLs, raw CNF, or
  local challenge paths.
• Remote signed weights remain opt-in for validators.

Operator action:

1. Pull and verify the signed v2.0.1 tag.
2. Restart validators and confirm the emitted chain version_key is
   2000001.
3. Managed PM2 operators should keep cathedral-updater running so the
   signed tag is picked up automatically.
4. Manual operators should fetch tags, check out v2.0.1, reinstall,
   run cathedral-validator migrate --config <mainnet config>, and
   restart the validator process.
5. Validators using remote signed weights should verify that the signed
   burn snapshot reports forced_burn_percentage=85.0.

v2.0.0 - SAT mining cutover

Date: 2026-05-27

This is the major SAT cutover release for Cathedral validators,
publishers, and miner-facing APIs. It moves the live mining path away
from card-era work and onto synthetic_boolean_v1 SAT challenges,
including concurrent active challenges by tier.

What changed:

• Cathedral validators stamp Bittensor set_weights calls with
  version_key=2000000.
• The SAT lane is the primary miner path.
• Public challenge discovery is available at GET /v1/synthetic-boolean/current-challenge without exposing CNF bodies, fetch tokens, internal paths, or signed challenge material.
• Tier-specific challenge discovery is available at GET /v1/synthetic-boolean/current-challenge?tier=N.
• Miners can discover every currently active SAT tier through GET /v1/synthetic-boolean/active-challenges; the response uses the same public-only projection as current-challenge.
• Miners submit SAT solutions directly through POST /v1/agents/submit with challenge_id and dimacs_solution.
• Valid solutions are checked synchronously, signed as schema-5 eval rows, and can rank immediately.
• Registrations without a submitted solution stay pending_solution; invalid or late solutions get signed zero-score attempts and are not SSH-probed.
• GET /v1/synthetic-boolean/active-cnf remains the private challenge-material route and requires a real hotkey signature plus X-Cathedral-Submitted-At.
• SSH/Hermes attestation is audit-only after a valid solve; it is not the payment gate for SAT.
• The challenge source can safely prepare one active SAT challenge per
  (family_id, tier) while existing callers keep one-active-per-family
  behavior by default.
• Tier-scoped lock-and-promote keeps a won tier moving by promoting the
  next pending challenge in that same tier.
• The private generator-to-publisher lease contract is documented for
  pre-generated CNF pools, lease TTLs, health/depth reporting,
  idempotent leases, and hash-confirmed imports.

What did not change:

• Public HTTP paths remain /v1/...; this is a release/protocol major,
  not an HTTP path rename.
• Public endpoints do not expose tokenized CNF URLs, raw CNF, or local challenge paths.
• The generator API is private Cathedral infrastructure. Miners and
  validators do not call it.
• The repo fallback config remains conservative, but the live v2.0.0
  publisher policy is signing a forced_burn_percentage=5.0 burn
  snapshot. Validators should verify the signed remote vector before
  relying on the reduced burn policy.

Operator action:

1. Pull and verify the signed v2.0.0 tag.
2. Restart validators and confirm the emitted chain version_key is
   2000000.
3. Managed PM2 operators should keep cathedral-updater running. It
   polls signed tags, verifies them with /opt/cathedral/allowed_signers,
   reinstalls Cathedral, migrates the validator DB, and reloads
   cathedral-validator.
4. Manual operators should fetch tags, check out v2.0.0, reinstall,
   run cathedral-validator migrate --config <mainnet config>, and
   restart the validator process.
5. Ensure remote signed-weight verification is configured with the
   Cathedral weight-policy public key before enabling remote mode, then
   verify that the signed burn snapshot reports
   forced_burn_percentage=5.0.
6. Validators that cannot verify the signed Cathedral policy should fail
   closed rather than emit stale local/card-era weights.
7. Keep the operator file-backed SAT challenge path available as the
   break-glass fallback while the generator pool is introduced.

v1.1.28 - Cathedral V4: Agentic SAT goes live

This is the SAT lane launch tag. Cathedral V4 turns the substrate that shipped over v1.1.22-27 into a live competitive market: agents build solvers, the publisher verifies math, validators sign weights.

Agentic. Miners run Hermes agents that use and build solver tools.

Deterministic. SAT solutions are clause-checkable. Scoring is math, not opinion.

Valuable. This work serves real verification markets: hardware design, protocol analysis, formal methods, and agent-built solvers.

What's in this tag

• Round timeout 60s -> 5 days. The 60s default was sized for the toy readiness probe and would expire every receipt before any real solver could finish. SHA-256 preimage class CNFs need days-scale wall-clock. Bumped DEFAULT_TIME_LIMIT_SECONDS to 432000 in src/cathedral/lanes/synthetic_boolean_v1/__init__.py:39 (#215).

• SAT-only emissions cutover. New publisher env CATHEDRAL_WEIGHT_POLICY_DISABLE_LEGACY_BASE_SCORES=true skips the legacy v1 agent_submissions ranked-score query in the signed weight vector. Only synthetic_boolean_v1 rows pay (#216).

Operator note

The publisher's signed vector now reads score_source: configured_task_family_rows and forced_burn_percentage: 5.0. Local validators on remote-weight mode pull the signed vector and apply it automatically; nothing to flip on the validator side.

For miners: cathedral-runtime image is deprecated (#219). Set up Hermes directly on a Linux SSH host per docs/miner/QUICKSTART.md.

Verification

After auto-puller picks up the tag, cathedral-validator --version reports 1.1.28. The fleet's vtrust converges within 1-2 weight cycles as validators sync to the new vector.

v1.1.27 - Remote weight validator opt-in config

Signed validator-ops release for Serge's remote signed-weight path. Validators still opt in explicitly, but the shipped config and provisioner now carry the public key pin needed for that path.

Changed:

• Remote weight config ships in mainnet and testnet templates as disabled remote_weight_source blocks.
• scripts/provision_validator.sh defaults CATHEDRAL_WEIGHT_POLICY_PUBLIC_KEY_HEX to the current Cathedral public pin.
• Validator docs name the concrete public pin.

Operator note:

• This release does not turn remote weights on by itself. Validators must still set remote_weight_source.enabled = true.
• The live publisher serves signed remote vectors under key id cathedral-weight-policy.
• The signed vector currently keeps synthetic_boolean_v1 = 0.0; this is not a scored SAT launch.

v1.1.25 - Managed remote weights and SAT readiness probe

Signed release for managed SN39 validators to follow Cathedral-signed remote weight policy by default while SAT emissions remain disabled.

Changed:

• Managed SN39 validators now default to the remote signed-weight source with a pinned public policy key.
• Existing managed SN39 configs migrate to remote signed weights on startup while preserving local wallet and hotkey settings.
• Validators fall back to the local configured burn policy only until the first signed remote vector is accepted.
• After a remote vector is accepted, stale or invalid remote vectors fail closed.
• Publisher exposes a zero-weight synthetic_boolean_v1 readiness probe using the cnf_url, cnf_sha256, and dimacs_solution protocol shape.

Operator note:

• Validators only need to update to signed tag v1.1.25.
• This release does not enable scored SAT emissions. synthetic_boolean_v1 remains 0.0 by default.

v1.1.24 - Public SAT readiness surfaces

Signed public release for validator fleet readiness ahead of SAT shadow cutover. SAT weight remains 0.0 by default.

Changed:

• API root index now returns stable operator and miner links for health, docs, skill.md, JWKS, eval-spec, recent signed evals, and agent submission.
• skill.md now includes the generic synthetic_boolean_v1 SAT contract without challenge material.
• Public SAT docs use authorized URL language and avoid transport internals, challenge construction details, corpus names, or private filenames.

Operator note:

• This release does not enable scored SAT emissions.
• config/mainnet.toml still keeps task_family_weights synthetic_boolean_v1 at 0.0 and forced_burn_percentage at 95.0.
• Tag-watching validators can update to this release through the signed-tag updater.