Multi-Operator Federation

What is Federation?

Anyone can run a DontGuess exchange. Each operator has its own campfire, its own inventory, and its own scrip ledger. By default, a buyer on Exchange A cannot find inventory on Exchange B — the marketplace is fragmented.

Federation lets two operators mutually agree to share inventory. A buyer on Exchange A searches both local inventory and federated inventory from Exchange B. Sellers on Exchange B get reach to Exchange A's buyers. Everyone gets a deeper pool without giving up autonomy.

What federation is NOT

• Not a unified ledger. Scrip stays local to each operator. No cross-operator scrip transfer — this avoids money transmission complications and prevents one operator from printing money on another's ledger.
• Not a unified reputation system. Each operator applies its own trust overlay before showing federated results to buyers.
• Not a global directory. Discovery is peer-to-peer via campfire beacons — there is no central registry of operators.
• Not mandatory. A standalone exchange works indefinitely without federating.

How It Works

Discovery via beacons

Operators discover each other via campfire beacons. An exchange publishes a beacon tagged dontguess:exchange on well-known beacon channels (DNS TXT, HTTP well-known). The beacon carries the operator's campfire public key, transport configuration, and exchange metadata.

Discovery is not trust. Knowing an operator's beacon proves who they are (the beacon is signed), not whether their claims are honest. Trust is earned through observed transaction outcomes.

Federation agreement

Two operators establish a federation relationship via a bilateral federation:propose / federation:accept handshake on a shared campfire. The agreement specifies:

The agreement is a campfire message signed by both operators. It is the root of trust for the relationship.

Inventory sharing

Once federated, operators share inventory by forwarding put metadata as federation:inventory-offer messages on the shared campfire. The offer contains description, content hash, token cost, seller reputation score, and the embedding vector (so the receiving operator can run similarity search).

Content itself is never shared. Only metadata travels. Content delivery happens after a cross-operator match, directly from the originating operator to the buyer.

Cross-operator match flow

Exchange A (buyer's)                Exchange B (seller's)
    |                                     |
    |  federation:match-request ------->  |
    |  <------- federation:match-confirm  |
    |                                     |
    |  scrip:buy-hold (local)             |
    |                                     |
    |  settle(preview-request) -------->  |
    |  <------- settle(preview)           |
    |                                     |
    |  settle(buyer-accept) ----------->  |
    |  <------- settle(deliver)           |
    |                                     |
    |  settle(complete) --------------->  |
    |                                     |
    |  scrip:settle (local)               |  scrip:settle (local — residual to seller)
    |                                     |
    |  inter-operator fee accrues         |  inter-operator fee credit accrues
    |                                     |
    |  [periodic] federation:reconcile    |

The buyer verifies the delivered content against the content_hash from the original put before sending settle(complete). A hash mismatch triggers a dispute, and the originating operator's cross-operator trust score drops. Post-hoc denial is cryptographically impossible — the hash is in signed messages.

Federation Node Profiles

Every sender the exchange has observed gets a FederationNodeProfile. The profile is derived from the campfire message log and updated by the slow loop every 4 hours.

Profiles are written by the slow loop and read by the new-node dual guard in the exchange engine. They are reset on replay and re-derived from the message log.

New-Node Dual Guard

The dual guard is a routing gate in the exchange engine. When FederationGuardEnabled=true, any sender whose TrustScore is below the threshold is forced to inline matching — bypassing the brokered-match path — regardless of the operator's BrokeredMatchMode setting.

Trust thresholds

Exiting new-node status

A sender exits new-node status when both conditions are satisfied:

1. TransactionCount ≥ 50 — at least 50 completed transactions traced to this sender
2. Age since FirstSeenAt ≥ 30 days — the node has been observed for at least a month

Until both conditions are met, the sender is treated as a new node regardless of trust score. This dual condition prevents an attacker from rushing through 50 fake transactions in a single day to bypass the guard.

Trust Propagation via Slow Loop

The slow loop runs every 4 hours and recomputes the TrustScore for every known sender using the tolerance function:

The computed score is clamped to [0.0, 1.0] and written to the sender's FederationNodeProfile. New nodes converge toward 1.0 but are capped below it until they exit new-node status.

Cross-Operator Discovery

When a buyer submits a buy request, the exchange searches both local inventory and federated inventory from all active partners. Federated results are presented with two reputation signals:

• Origin reputation — the seller's reputation score as assessed by the originating operator. Advisory.
• Cross-operator trust overlay — the local operator's own assessment of the originating operator, derived from observed match outcomes. Authoritative for this buyer.

The Layer 0 correctness gate is applied using local outcome data. An entry that has failed locally is excluded from results regardless of its remote reputation.

Convention operations

Federation adds seven operations under the federation: prefix:

Standalone vs. Federated

Federation adds liquidity but also adds operational surface. Here is a guide:

Adversarial Containment

The dual guard and trust overlay limit what a rogue operator can do to your exchange:

• Garbage inventory flooding — rate limits cap the volume; the trust floor in the federation agreement blocks low-reputation entries; cross-operator outcome tracking down-ranks spam sources over time.
• Reputation inflation — inflated remote scores are advisory only. The local cross-operator trust overlay is derived from outcomes you observed yourself.
• Dispute weaponization — disputes are local; cross-operator dispute rates feed into the trust overlay; the preview model reduces dispute surface.
• Content substitution — the content hash is in the signed federation:inventory-offer and federation:match-confirm. Buyers verify the hash on delivery. A mismatch triggers a dispute and trust penalty.

When a partner's cross-operator trust score drops below 0.2, the exchange auto-revokes federation. Revocation is instant — federated inventory from that operator is removed from match results immediately. In-flight transactions complete normally (escrow already committed). Outstanding inter-operator balances are still owed even after revocation.

Settlement

Scrip never crosses operator boundaries. The buyer spends local scrip on Exchange A. The seller earns local scrip on Exchange B. Operators settle the inter-operator fee out-of-band:

• Each operator maintains a running tally of fees owed to and from each federated partner
• Reconciliation happens periodically via x402 payments or bilateral credit
• If an operator's outstanding balance exceeds a threshold, the federation relationship is paused until settled
• Soft suspension at +12 hours overdue; automatic revocation at +48 hours

Next steps