68e057209c
Lock alpha scope, tracker auth, TOPLOC fraud verification, and deferred multi-tracker money-path work; supersede legacy fraud issues with ADR-0018. Co-authored-by: Cursor <cursoragent@cursor.com>
3.4 KiB
ADR-0016: Alpha scope and known limitations
Status: Accepted
Context
Pre-release audits found the routing layer is solid (ADR-0013) but the money and trust paths are not alpha-ready: unauthenticated gossip, free starting credit, node-reported accounting, ephemeral strike/ban state, and plaintext tracker HTTP undermine release. The owner locked an alpha scope that ships real inference and devnet settlement while explicitly deferring multi-tracker trustlessness and cryptographic verification.
Decisions
1. Single settlement tracker
One operator-designated tracker holds the treasury keypair and runs the settlement loop (ADR-0015). Third-party trackers may join the hive for routing and state replication but never sign payouts. Raft elects a leader for shard-assignment commands only; settlement leadership is operator-configured, not democratic.
2. Open node join
Any wallet may register a node without invite, stake deposit, or hardware attestation. Anti-sybil cost comes from probation (first N jobs unpaid), carried-forward reputation, and fraud penalties — not from closed admission.
3. Devnet mock-USDT
Development and alpha target Solana devnet with a self-created mock-USDT SPL mint (ADR-0015). Mainnet USDT is a config change, not an architecture change. TAI settlement (ADR-0002) remains deferred; the 10% protocol cut accumulates as future TAI liquidity.
4. Reputation carries forward
Strike count, ban status, graduated reputation, and audit history persist across tracker restarts and are intended to survive alpha → mainnet cutover. A banned operator cannot evade penalties by restarting the tracker or re-registering under a fresh node id with the same wallet.
5. Known alpha limitations (explicit, not bugs)
| Limitation | Alpha posture | Post-alpha path |
|---|---|---|
| Tracker is trusted referee for audits and blame | Acceptable — see ADR-0018 | Decentralized verifier market; Verde-style on-chain games |
| Plaintext HTTP on tracker/node paths | Acceptable on LAN/dev; relay TLS only (ADR-0010 amended) | Full TLS + cert pinning per ADR-0010 intent |
| Unauthenticated gossip replication | Blocker — fix before alpha (ADR-0017) | HMAC/mTLS between hive members |
| zkML / GPU TEE verification | Roadmap-only | ADR-0018 §9; re-evaluate yearly |
| Multi-tracker money-path safety | Design now (ADR-0019), implement later | Consensus-gated settlement, idempotent payouts |
| Bitwise output equality across GPUs | Not required — logit/activation tolerance (TOPLOC) | Optional Gensyn RepOps tier for referee |
6. Fraud must be bounded
Because reputation carries forward, correctness fraud (bad outputs) and accounting fraud (inflated tokens/shard spans) must be economically irrational at the locked ~5% audit budget. Detection, blame, and penalty design are ADR-0018; implementation is Bucket 1 in .scratch/alpha-hardening/.
Consequences
- Alpha release criteria are Bucket 1 blockers in
.scratch/alpha-hardening/README.md, not "all 35 user stories done." - Documentation and runbooks must state trust assumptions plainly — custodial treasury, trusted tracker, devnet funds.
- Bucket 2 (multi-tracker) issues are tracked but not alpha-blocking.
Related
- Supersedes the spirit of prototype-only trust in ADR-0003 for production alpha behavior — see ADR-0018.
- Settlement mechanics: ADR-0015.
- Research grounding:
.scratch/alpha-hardening/research-verifiable-inference.md.