conjectures

# conjectures.io — Bittensor Subnet 66 Validator

This is the complete validator repository for **conjectures.io**, **Bittensor Subnet 66**. Its
product is a paid proof-submission API: a miner pays **0.5 TAO**, submits a candidate Lean proof for
an eligible task, and receives a durable submission ID. The validator confirms the payment, checks
the proof with Lean, optionally holds a valid proof for manual reward review, and passes every
reward-eligible proof into the Subnet 66 reward pipeline.

Payment buys one proof-verification attempt. It never changes Lean's verdict and does not guarantee
a reward.

This repository is the system boundary for the entire validator, including:

- the miner-facing paid submission and status API;
- payment confirmation, idempotency, and reconciliation;
- durable submission, verification, review, and reward records;
- signed, opt-in public author/team credit snapshotted per submission;
- immutable proof artifacts and verifier reports;
- asynchronous verification workers and the hardened Lean verifier;
- the optional manual reward-review queue;
- reward eligibility, dynamic bounty pricing, and treasury-only Subnet 66 weight submission; and
- deployment, monitoring, backup, and recovery configuration.

Some of those validator components still need to be implemented. The current checkout already
contains the audited task pool, exact task commitments, service adapter, and hardened Lean
verification core.

| Validator component | Status |
| --- | --- |
| Audited Lean task generation and immutable task commitments | Implemented |
| Hostile-proof verification in an isolated container | Implemented |
| API-neutral proof handoff with exact task digest | Implemented |
| Hardened miner submission bundle format and archive admission | Implemented |
| Miner-facing paid submission and status API | Implemented |
| Website accounts, browser sessions, and coldkey linking | Implemented |
| CLI sessions: a linked coldkey mints a scoped bearer token | Implemented |
| Website submissions: a coldkey signs a readable message, one credit pays, one call | Implemented |
| Session submissions: one credit pays and no Bittensor key is needed at all | Implemented |
| Roles and the operator surface (`MINER`/`REVIEWER`/`ADMIN`) | Implemented |
| Shared durable schema and migrations | Implemented |
| Finalized transfer reader, wired into both funding paths | Implemented |
| Deposit watcher: TAO at the treasury becomes credits | Implemented |
| TMC PAY: credits bought at 0.5 TAO each through the payment processor | Implemented |
| Invitation links: free verification attempts granted without a wallet | Implemented |
| Asynchronous verification worker | Implemented |
| Manual reward-review decision service | To build |
| Automatic reward eligibility and one-reward-per-theorem-target constraint | Implemented |
| DB-driven Discord payout command notifications | Implemented |
| Best/finalized chain reconciliation for Paying/Paid payout status | Implemented |
| Subnet 66 treasury weight setter (100% to UID 121 every epoch) | Implemented |
| Proof-specific scoring and automated bounty payout | To build |
| Production launch and operating runbooks | To build |

The submission API captures the per-submission manual-review policy and records the review gate
decision, but the reviewer-facing decision service itself is still to build.

Miners should start at [`docs/MINER.md`](docs/MINER.md): what to do, in order, to get one proof
submitted, verified and paid. In short, install
[`conjectures-miner`](https://github.com/conjectures-io/conjectures-miner) — it does the whole
flow, including building this verifier locally so a proof can be checked before any TAO moves.
[`docs/API.md`](docs/API.md) documents the API surface and its
configuration, [`docs/SUBMISSION_BUNDLE.md`](docs/SUBMISSION_BUNDLE.md) the submission format,
[`deploy/README.md`](deploy/README.md) the database deployment,
[`docs/OBSERVABILITY.md`](docs/OBSERVABILITY.md) the structured events every process emits and how
to read them, and [`docs/SUBNET.md`](docs/SUBNET.md) the service contract, trust boundaries, and
remaining work.

## Validator flow

1. A miner chooses an eligible committed task — proving the conjecture, or refuting it with a
   counterexample — prepares one candidate Lean proof, checks its format with
   `verifier bundle scan`, then runs `verifier bundle verify` for the real Comparator and Lean
   kernel result: a rejected bundle costs nothing to fix.
2. The miner pays exactly **0.5 TAO** and submits the proof bundle through the validator API with
   its task ID and digest, the payment reference, miner identity, and an idempotency key.
3. The API admits the bundle, authenticates the coldkey signature, and confirms the transfer
   against finalized chain state. Intake is payment-gated: a refused request creates no
   submission and is recorded in `api_rejection_log` instead.
4. Once confirmed, the API durably records the proof bytes and the submission, and returns a
   submission ID together with its locked bounty amount. New submissions are priced from the
   treasury balance left after outstanding locks; this submission's amount no longer changes
   while verification or review is in flight. The submission is queued for verification by being
   `UNVERIFIED`.
5. A verification worker claims it under a lease and passes the exact proof bytes and task digest
   to the isolated verifier, in a container holding neither the database nor any key.
6. A proof rejected by policy, Comparator, or the Lean kernel is recorded as rejected and never
   reaches rewards. A run that failed for the validator's own reasons — no sandbox, a dead
   container — is not a rejection: the submission stays unverified and is retried, because the
   miner has already paid and their proof was never judged.
7. A Lean-valid proof and its immutable verification report are durably recorded.
8. If manual reward review is required, the valid submission remains hel