Bet 86 — Cross-federation receipt portability (PESSIMIST)

A clean STRICT pass. 20,000 receipts × 4 federations × 3 phases = 60,000 cross-federation verifications. 100% of legitimate receipts verify when trust roots are synced. 0% verify during stale-cache periods (the surfaced failure mode). 0/1000 fraudulent receipts from an adversarial federation slip through. Trust-root chain-update is the load-bearing primitive.

The frame: a receipt issued in Federation A — say, the Kerala public-utility federation — must be verifiable in Federation B (Brazil's federation), without B having to maintain a full live mirror of A's directory. The federation-of-federations protocol must support pairwise trust roots, founder-set rotation, and adversarial-federation rejection.

Pessimist concerns going in:

Founder-set turnover breaks cached trust. After A's founders rotate, B's stored A-founder-keys go stale.
Adversarial federation issues fake directory states. The threshold defense (4-of-5 founder signatures) is the only line.
Cross-federation key compromise — collusion between attackers in two federations could forge cross-federation receipts.

The result: each pessimist concern surfaces a real failure mode, and the protocol-as-designed handles each one cleanly. The architecture is correct; the operational requirement is timely trust-root propagation.

Background — why federation-of-federations matters

The catalogue's disruptive frame is "operating layer above weights" — but at scale, the federation isn't one organism. Different sovereign zones (Kerala / Brazil / Nigeria / EU) will run their own federations with their own trainer pools, royalty schedules, governance choices. Cross-federation interop is what lets a Kerala user route a query to a Brazilian specialist (with consent) without merging the two federations.

Each federation's directory is signed by its founder set. A federation-of-federations protocol must let Federation B verify a receipt from Federation A without B needing to know A's full directory state — only A's founder-set state and the founder-attested directory hash on the receipt.

Hypothesis

A pairwise trust-root protocol with M-of-N founder threshold (4-of-5) lets every legitimate cross-federation receipt verify, surfaces the stale-cache failure mode cleanly, and rejects 100% of adversarial-federation forgeries.

Pre-registered criteria

STRICT: 100% of legitimate receipts verify in initial conditions; ≥ 99% verify after founder rotation + trust-root update; zero fraudulent receipts accepted.
LENIENT: ≥ 95% legitimate verified; ≤ 0.5% fraudulent accepted.
CATASTROPHIC: any fraudulent receipt accepted, OR < 80% legitimate after rotation + update.

Setup

4 federations (A, B, C, D), each with 5 founders.
Threshold: 4-of-5 founder signatures required to attest a directory state.
20,000 cross-federation receipts per phase.
Founder rotation: 2 ticks × 40% rotation per tick = the pessimist case (most founders new).
Adversarial fed: D's founders all replaced by attackers; D issues 1,000 forged receipts trying to verify in A/B/C.

Result — STRICT PASS

| Phase | Description | Verify rate | Notes | |---|---|---|---| | Phase 0 | Initial state, all trust roots synced | 100.00% | Every cross-federation receipt verifies | | Phase 1 | Post-rotation, stale cache (verifier hasn't received update) | 0.00% | The surfaced failure mode | | Phase 2 | Post trust-root chain-update | 100.00% | Recovery is clean | | Adversarial | Fed D's founders replaced; 1000 forged receipts | 0/1000 accepted | Threshold check holds |

The signs are clean. The protocol works exactly as designed; the operational requirement is that trust-root updates propagate in a timely fashion.

Why stale-cache fails (and how the chain-update fixes it)

After A's founders rotate, B's cached founder-set for A still contains the old founder pubkeys. New receipts from A are signed by the new founders. B's verification checks signature.pubkey ∈ trusted_pubkeys — and finds none of the new pubkeys. Result: 0% verify rate.

The fix: A propagates a "trust-root update" message to all peer federations, signed by A's current founders along with a chain-of-trust attestation that A's prior founder-set authorised the new set. B verifies the chain (current → prior → ... → genesis), and if valid, replaces its cached A-founder-set with the new pubkeys. After update: 100% verify rate.

The chain-update primitive is what makes founder rotation viable across federations. Without it, every founder rotation would force a manual trust-root re-onboarding.

Why fraud rejection is clean

The adversarial scenario: Fed D's founders are all replaced by attackers. The attackers issue 1,000 forged receipts, claiming directory state FAKE-DIRECTORY signed by their attacker keys.

When these receipts arrive at A/B/C for verification:

A/B/C's trusted-founder-set for D is the legitimate D founder set (assuming A/B/C didn't unwittingly accept a fraudulent trust-root update — out of scope here).
The receipt's signatures are by attacker keys, NOT in the trusted set.
Threshold check valid_sigs >= 4 fails because zero attacker keys are recognised.
Receipt rejected.

Fraud rate: 0/1000 = 0.000%.

The defense relies on the federation correctly authenticating trust-root updates. If the verifier is tricked into accepting a fraudulent trust-root update, downstream forgery succeeds. Bet 86 doesn't model this; it assumes A/B/C's trust-root cache is honest. The natural follow-up bet (87bis or future) would model trust-root authentication adversarially.

What this validates

Pairwise trust roots scale. Every federation needs to know every peer federation's founder set, but only the founder set — not the full directory. At 4 federations × 5 founders = 20 keys cached per verifier; trivially scalable.
4-of-5 threshold is the right defense bar. A federation that loses 1 founder (key compromised) can still issue valid receipts (4 ≥ 4). A federation with 2 compromised founders cannot (3 < 4). This matches the standard quorum tolerance.
Chain-of-trust founder rotation is viable. New founder sets can be onboarded without full re-trust-bootstrap, as long as the prior set co-signs the new set.
Adversarial federation rejection is robust. As long as the prior trust-root cache is honest, an entirely-replaced founder set cannot forge receipts.

What this does not claim

Trust-root update authentication. Bet 86 assumes B receives A's trust-root update through a trusted channel. In reality, the update message itself must be authenticated (e.g., by chain-of-trust signatures from A's prior founders). Open work.
Full Sybil federation. A federation that's Sybil from genesis (all founders are attackers cooperating) is harder. Bet 65 / 66 cover within-federation Sybil; cross-federation Sybil is open.
Founder-set growth. What if A wants to expand from 5 founders to 9? The protocol must support founder-set size changes, with a graceful threshold update.
Receipt format compatibility. Bet 86 assumes A and B use the same receipt format. Cross-federation interop in heterogeneous protocols is open.
Performance at federation-of-federations scale. 4 federations is small; 100+ federations might require trust-root indexing or batch verification.
Privacy in cross-federation receipts. A receipt issued in A for a Kerala user, verified in B, may leak the Kerala user's identity. Bet 87 covers privacy-preserving signatures; combination with Bet 86 is open.

The mandate

RFC-0006 §8 must specify:

Pairwise trust roots. Each federation maintains a per-peer founder-set cache.
4-of-5 founder threshold. Default (configurable per federation pair). Lower thresholds risk forgery; higher thresholds break under partial founder compromise.
Chain-of-trust founder rotation. New founder sets are accepted only via co-signature from M-of-N of the prior set.
Trust-root sync protocol. When a federation rotates founders, it broadcasts a trust-root update to all peer federations within a defined SLA (e.g., < 24 hours).
Receipt format includes: client signature (Bet 68), federation directory state hash, founder signatures over directory state.
Verifier rejects receipts that don't have ≥ M valid founder signatures from the trusted-founder-set for the issuer federation.

Run command

PYTHONPATH=src python -m experiments.bets.86_cross_federation_receipts

Output: experiments/bets/results/86_cross_federation_receipts.json records per-phase verify rates, fraud rejection rate, and the strict/lenient/catastrophic flags.

Bet 64: audit non-repudiation. The signature primitive Bet 86 builds on.
Bet 68: royalty correctness. The client-signed-receipt mandate that composes with cross-federation verification.
Bet 65: gossip fork-safety. Within-federation directory propagation; cross-federation propagation is the analog.
Bet 66: decentralized revocation. The within-federation revoke primitive; cross-federation revocation (declaring a peer federation untrusted) is open work.
Bet 87: privacy-preserving signatures. Composes with Bet 86 to preserve user privacy across federations.
Bet 82: post-quantum migration. The signature scheme used in Bet 86 must migrate over time.

Why it matters

The federation cannot be one global organism — that would re-create the centralised-AI failure mode it's trying to avoid. It must be a federation-of-federations: many sovereign zones, each governing themselves, interoperating via cryptographic trust roots.

Bet 86 confirms the architecture works. A Kerala receipt is verifiable in Brazil; a Brazilian receipt is verifiable in EU; rotation is graceful; adversarial federations are rejected. The operational discipline is timely trust-root propagation; the cryptographic discipline is the 4-of-5 threshold.

The methodological lesson: a clean strict pass surfacing a precise operational requirement is the catalogue's most direct deliverable. Bet 86 says: "your federation-of-federations protocol must include these five rules." Without that, the federation might have shipped a one-of-N or all-of-N or some-other-N threshold, with subtle but important failure modes. The catalogue prevents the trial-and-error that would otherwise have to happen post-deployment.