Bet 68 — Royalty correctness at 10k specialists (CATASTROPHIC)

The fifth and most consequential operating-layer big bet. It is a clean catastrophic falsification of the unsigned-receipt royalty design, and it surfaces a load-bearing architectural finding: client-signed receipts are mandatory at federation scale.

Bet 14 validated the royalty math at 3 specialists × 3 servers in a clean environment. Frame B (cognitive-commons economics) requires the math to stay correct at federation scale (10,000+ specialists, 5,000+ servers) and under adversarial server claims. Bet 68 ran 200,000 operations across that scale with 5% Byzantine servers attempting two attack patterns (manifest-hash swap and ghost registration). The result: 99.902% of fraud attempts rejected — but four swap-attacks slipped through, capturing royalty for trainers whose specialist was never served.

Four out of 4068 is a 0.098% leak rate. Production-acceptable rates for fraud rejection in financial systems are typically 99.99%+ ; this design lands two nines short. The bet's catastrophic flag fires correctly. The fix is unambiguous: receipts must be cryptographically signed by the requesting client, binding the manifest_hash to the client's intent.

Background — what royalty correctness means at scale

Bet 14 established the royalty model: every inference produces a Receipt(receipt_id, manifest_hash, server_id, fee_units). The ledger pays 30% of the fee to the specialist's trainer (the royalty share) and 70% to the server. Conservation holds: for any receipt, the issuer's fee equals the trainer's royalty plus the server's earnings.

The math is correct in isolation. The question Bet 68 poses is: what happens when a server lies about which specialist they served?

A Byzantine server has incentive to manipulate the manifest_hash field on receipts. Two attack patterns:

Swap attack. Server S serves a query for specialist A. Before reporting the receipt, S changes the manifest_hash to specialist B (one S also legitimately serves). The trainer of B is paid; the trainer of A is not. S's royalty goes to the wrong trainer. If trainer B happens to be S's accomplice, the attack extracts value through a colluding pair.
Ghost attack. Server S submits a receipt for a specialist S has never registered for. The directory check rejects this — if the (manifest_hash, server_id) pair isn't in the registered set, the receipt is invalid. Ghost attacks are easy to defend against because the directory state is known.

The bet runs both attacks at scale and measures the rejection rate plus the silent-loss rate (legitimate trainers who never receive royalty due to Byzantine receipt manipulation).

Hypothesis

The royalty ledger's earnings calculation is correct to within 0.1% drift across 10,000 specialists × 5,000 servers under adversarial conditions (5% Byzantine servers attempting swap + ghost attacks). All fraudulent claims are rejected by directory and signature checks. No legitimate trainer with > 100 served operations receives zero royalty.

Pre-registered criteria

STRICT: trainer-earnings drift < 0.1%; 100% of fraudulent claims rejected; zero silent-loss trainers.
LENIENT: drift < 0.5%; ≥ 99% fraud rejection; zero silent-loss trainers.
CATASTROPHIC: drift > 2%, OR any fraudulent claim accepted, OR ≥ 1 trainer with > 100 served ops receiving zero royalty.

The catastrophic threshold "any fraudulent claim accepted" is the security-critical one. A federation that accepts even 1 in 10,000 fraudulent claims has a measurable attack surface: a coordinated adversary at scale extracts non-trivial value over time.

Setup

Simulation parameters:

10,000 specialists, each owned by one of 2,000 trainers (average 5 specialists per trainer).
5,000 servers, each registered to host 30 randomly-chosen specialists.
5% of servers (250) are Byzantine. With 40% probability per operation, a Byzantine server attempts one of two attacks:
- Swap (50%): the server changes the manifest_hash on a legitimate receipt to a different specialist (any specialist other than the one actually served).
- Ghost (50%): the server fabricates a receipt for a specialist it is not registered for.
200,000 operations. Each operation: pick a specialist, pick a server that legitimately serves it, generate a receipt with fee = 100 micro-units.
Royalty share: 30% to trainer, 70% to server.

The directory check enforces: receipts must reference a (manifest_hash, server_id) pair that is in the registered set. Receipts that don't match are rejected.

Result — CATASTROPHIC

| Metric | Value | |---|---| | Operations attempted | 200,000 | | Operations accepted (legitimate + fraud-success) | 195,932 | | Byzantine swap attempts | 2,036 | | Byzantine ghost attempts | 2,036 | | Total fraud attempts | 4,072 | | Swaps rejected | 2,032 | | Ghosts rejected | 2,036 | | Frauds rejected total | 4,068 (99.902%) | | Frauds accepted (swap leakage) | 4 | | Trainer earnings drift | 0.0000% | | Server earnings drift | 0.0000% | | Silent-loss trainers (≥ 100 ops, zero royalty) | 0 | | STRICT | FAIL (4 frauds accepted) | | LENIENT | PASS (≥ 99% rejection) | | CATASTROPHIC | TRIGGERED (any frauds accepted) |

Ghost attacks fail 100% — the directory check correctly rejects every (manifest_hash, server_id) pair the server hasn't registered for. Swap attacks fail 99.80% — but four of them succeed.

How the swap attack succeeds

The swap attack has a subtle preconditional success path. The Byzantine server S is registered for 30 specialists. When a client requests specialist A (one of S's registered set), S receives a legitimate receipt. The attack changes manifest_hash from A to B.

The directory check verifies: is (B, S) in the registered set? If S happens to also be registered for B — which is the case with probability 29/9999 ≈ 0.29% (S is registered for 30 of 10,000 specialists, so any random other specialist is registered for S with probability 29/9999) — the directory check passes. The receipt is accepted as legitimate. Trainer B is paid; trainer A is not.

Out of 2,036 swap attempts, the expected number landing on a co-registered specialist is 2,036 × 0.29% ≈ 5.9. Observed: 4. Within statistical noise. The mechanism is fully understood.

Why this falsifies the unsigned-receipt design

The directory check alone is insufficient. The check verifies that the server can serve B, but not that the client requested B. A Byzantine server who is legitimately registered for both A and B can swap any receipt between them with no detection at the directory layer.

The attack value at scale: 4 in 4,072 = 0.098% successful swap rate. Over 1 million operations with 5% Byzantine servers, the expected fraud value is 1M × 5% × 40% (attack rate) × 50% (swap pattern) × 0.29% (co-registration probability) = ~290 successful swaps. At 30 micro-units royalty per fraud, that's ~8,700 micro-units of misdirected royalty per million operations.

Per million ops, 8,700 micro-units is small. But it's systematic — it accumulates over time, and a coordinated adversary (multiple Byzantine servers + the colluding trainer they swap to) can extract continuous value. The federation cannot ship this.

The fix

Each receipt must include a client-signed binding of manifest_hash to the client's request. The signature is over (client_pubkey, manifest_hash, server_id, fee_units, request_id). The server cannot tamper with the signed payload because they don't have the client's private key.

When the receipt reaches the ledger, the verification adds one step:

Directory check: (manifest_hash, server_id) is registered. (Existing.)
Signature check: the client's signature over the receipt's payload is valid.

A swap attack now fails at step 2: the original signed payload had manifest_hash = A. Tampering changes the bytes the signature was computed over; the signature no longer verifies. The receipt is rejected.

Cost: each receipt grows by ~64 bytes (Ed25519 signature). Each verification costs ~100 µs (Ed25519 verify). For 1M operations / hour at the federation's projected scale, signature verification is ~30 seconds of CPU per hour. Negligible.

The federation's RFC-0006 specification can be amended to mandate client-signed receipts. The amendment is small; the implementation is standard cryptography. Bet 68 surfaces this as load-bearing.

What this validates

Even though the bet is catastrophic on the headline metric, it validates several adjacent properties:

Ghost attacks are fully rejected. The directory state is authoritative for "this server can serve this specialist," and Byzantine servers cannot fabricate registrations.
Drift is zero (modulo fraud). When fraudulent acceptances are accounted for in expected earnings, the books balance to the byte. The math is correct; the security perimeter is what fails.
Silent-loss is zero. No trainer with > 100 legitimate operations receives zero royalty. The receipts that reach the ledger are correctly attributed to the right trainer.
At-scale economics. The bet handles 10,000 specialists × 5,000 servers × 200,000 ops without numerical or structural issues. The royalty model scales.

The catalogue's lesson: a falsification that surfaces a fixable architectural requirement is more valuable than a strict-pass result that ducks the test. Bet 14 (clean environment) was a strict pass; Bet 68 (adversarial scale) is catastrophic. Together they tell the federation: "the model works correctly; the protocol needs client signatures to be safe."

What this does not claim

Quantum-resistant signatures. Ed25519 is conjectured to fall to a sufficiently-large quantum computer. Post-quantum signatures (e.g. SPHINCS+, Dilithium) are open work for the federation's long-term cryptographic story.
Cross-federation receipt portability. A receipt signed by client X in federation A must be verifiable in federation B. The signature scheme and the federation-membership attestation must compose. Open work.
Privacy-preserving signatures. Ed25519 signatures bind the receipt to the client's public key, which leaks the client's identity. Privacy-preserving alternatives (group signatures, zk-SNARKs) are the next research step. Out of scope here.
Wall-clock signature-verification overhead at full federation scale. The bet uses unsigned receipts because the goal is to surface the design gap, not to benchmark the fix. Performance benchmarks for the signed design are open work.

Run command

PYTHONPATH=src python -m experiments.bets.68_royalty_at_scale

Output: experiments/bets/results/68_royalty_at_scale.json records the full operation count, per-attack-vector rejection counts, fraudulent-acceptance count, drift fractions, and silent-loss accounting.

Bet 14: royalty ledger (clean environment). The math-correctness bet that Bet 68 stresses.
Bet 65: gossip fork-safety. The directory-layer Sybil-resistance which Bet 68 finds insufficient on its own.
Bet 67: ledger durability. The complementary ledger-at-scale falsification (one-sided drops).
Bet 64: audit-trail non-repudiation. The cryptographic-commitment primitive that should compose with signed receipts.
Bet 11: pay-with-bandwidth ledger. The bandwidth-side counterpart of the royalty ledger.

Why it matters

This is the most consequential big bet so far because it produces a concrete architectural mandate: the federation's RFC-0006 must require client-signed receipts. Without the signature, a Byzantine server with co-registration can swap manifest_hashes and capture royalty for trainers they conspire with. With the signature, the attack vector closes at a small cost (~64 bytes/receipt, ~100 µs/verification).

The catalogue exists precisely for this kind of surface. A specification that says "receipts include a manifest_hash field" is a design choice. A specification that says "receipts MUST include a client-signed binding of manifest_hash to the client's request, verified before ledger acceptance, with rejection rate ≥ 99.99% under co-registered Byzantine adversaries" is a load-bearing requirement. The catalogue's discipline is what produces the second statement, not the first.

The methodological lesson: catastrophic falsifications are the most valuable result-class the catalogue produces. They're the data points that turn loose architectural assumptions into mandatory protocol requirements. Bet 68 cost a few minutes of compute and produced a clear, fixable, load-bearing finding. The simpler unsigned-receipt design would have shipped to production under the radar; the signed design will ship with empirical justification. That's the catalogue's contribution: not "we have receipts," but "we have receipts that pass this measured Byzantine-resistance bar."