DEFONEOS · Federation Discovery Protocol

1. Purpose

The Federation Discovery Protocol defines how MCP servers in the DEFONEOS ecosystem find each other, establish trust, exchange capabilities, and maintain federation state. It replaces centralised service registries with a peer-to-peer, cryptographically-verifiable discovery model.

Design principle: No central broker. No single point of failure. Every MCP server publishes its own manifest at a well-known endpoint. Discovery is pull-based, signed, and SIGIL-attested. Trust is derived from the BFT council, not from a central authority.

2. The Manifest Endpoint

Every MCP server in the federation publishes a machine-readable manifest at a standardised well-known path:

GET /.well-known/defoneos-manifest.json

2.1 Manifest Structure

{ "manifest_version": "1.0", "mcp_id": "sentinel-hub-mcp", "display_name": "Sentinel Hub Satellite Imagery", "version": "2.1.0", "ring": 1, "trust_level": "defence-sensor", "ed25519_identity": "ed25519:0x4a2b...c8f1", "capabilities": [ "get_satellite_image", "list_collections", "search_catalog", "get_metadata" ], "data_classification": "OSINT", "data_flow": "inbound-only", "external_apis": [ { "name": "Sentinel Hub Process API", "jurisdiction": "EU", "data_sent": "bounding box, date range, collection ID", "data_received": "satellite imagery tiles", "pii_risk": "none" } ], "health_endpoint": "/health", "sigil_enabled": true, "red_line_compliance": { "kinetic_targeting": "not-capable", "personal_surveillance": "not-capable", "bulk_collection": "not-capable" }, "admission_date": "2026-07-09T14:00:00Z", "bft_vote": "28/33 approved", "signature": "ed25519:0x9f3a...e7b2", "manifest_hash": "sha256:0x1c4d...88ab" }

3. Discovery Flow

3.1 Initial Discovery

When a new MCP joins the federation or an existing MCP needs to discover peers, the following sequence executes:

Step 1: MCP server starts → publishes /.well-known/defoneos-manifest.json Step 2: Federation seed nodes (Ring 0 MCPs) fetch manifest Step 3: Manifest signature verified (Ed25519) Step 4: Manifest hash compared to BFT council registry Step 5: If new: Admission Control Checklist executed (9-point) Step 6: If existing: Manifest hash compared to last known (change detection) Step 7: Capabilities indexed in federation catalogue Step 8: SIGIL receipt: federation_discover event logged Step 9: Health check initiated (GET /health) Step 10: MCP marked ACTIVE in federation state

3.2 Continuous Discovery (Heartbeat)

Interval	Action	SIGIL Event
Every 15 seconds	Health check (GET /health)	`federation_heartbeat` (batch)
Every 5 minutes	Manifest re-fetch + hash compare	`federation_manifest_check`
Every 15 minutes	SIGIL receipt batch submission	`federation_sigil_sync`
Every 1 hour	Capability re-index	`federation_reindex`
On manifest change	Immediate re-admission check	`federation_manifest_changed`
On health failure	Quarantine after 3 consecutive failures	`federation_quarantine`

4. Trust Ring Assignment

Every MCP is assigned to one of three trust rings at admission time. Ring assignment determines data access, secret access, and federation privileges. See MCP Admission Control Checklist for the full assignment criteria.

Ring	Label	MCPs	Data Flow	Discovery Scope
Ring 0	Core Sovereign	7	UK-sovereign-only, zero external API	Full federation visibility
Ring 1	Defence Sensors	11	Inbound-only from external sensors	Ring 0 + Ring 1 peers
Ring 2	Civil Services	12	Public data, unrestricted	Ring 0 + Ring 2 peers

Cross-ring visibility rule: Ring 1 and Ring 2 MCPs cannot discover each other directly. All cross-ring communication flows through Ring 0, which acts as the sovereign intermediary. This prevents defence sensor data from leaking to civil service MCPs and vice versa.

5. Federation State Machine

Each MCP in the federation transitions through these states:

State	Description	Entry Condition	Exit Condition
DISCOVERED	Manifest fetched and signature verified	Initial discovery or re-discovery	Admission check initiated
PENDING_ADMISSION	Under 9-point admission control review	Manifest verified, not yet admitted	BFT vote (23/33 quorum)
ACTIVE	Fully operational, healthy, federated	BFT approval + health check pass	Health failure or manifest change
DEGRADED	Health issues but still responding	1-2 consecutive health failures	Recovery (→ ACTIVE) or 3rd failure (→ QUARANTINED)
QUARANTINED	Isolated, not trusted for data flow	3 health failures or red-line alert	Manual review + BFT vote to restore
RETIRED	Removed from federation	BFT vote (23/33) or human owner decision	Terminal state

6. Federation Events (SIGIL)

Every federation state transition generates a SIGIL receipt. The complete event taxonomy:

Event Type	Trigger	Critical Fields
`federation_discover`	New MCP manifest discovered	mcp_id, manifest_hash, ring
`federation_admit`	BFT vote approves admission	mcp_id, vote_tally, quorum_met
`federation_activate`	MCP transitions to ACTIVE	mcp_id, health_status, capabilities
`federation_degrade`	Health check fails	mcp_id, failure_count, error
`federation_quarantine`	MCP isolated	mcp_id, reason, trigger_type
`federation_restore`	Quarantined MCP restored	mcp_id, bft_vote, review_id
`federation_retire`	MCP permanently removed	mcp_id, bft_vote, reason
`federation_manifest_changed`	Manifest hash differs from cached	mcp_id, old_hash, new_hash
`federation_capability_added`	New tool discovered in manifest	mcp_id, tool_name, ring
`federation_red_line_alert`	Red-line compliance check failed	mcp_id, violation_type, auto_quarantine

7. Federation Catalogue

The federation maintains a live catalogue of all 30 MCPs and their 150+ tools. The catalogue is derived from manifest data and updated on every discovery cycle:

7.1 Catalogue Structure

GET /api/federation/catalogue { "total_mcps": 30, "total_tools": 156, "active": 30, "degraded": 0, "quarantined": 0, "by_ring": { "ring_0": 7, "ring_1": 11, "ring_2": 12 }, "mcps": [ { "id": "sigil-mcp", "ring": 0, "tools": 8, "state": "ACTIVE", "health": "100%" }, ... ] }

8. Failover & Resilience

Scenario	Detection	Response	Recovery
MCP health failure	3 consecutive /health timeouts	Auto-quarantine, reroute to fallback	BFT vote to restore
Manifest tampering	Hash mismatch on re-fetch	Immediate quarantine + SIGIL red-line alert	Manual investigation + re-admission
Network partition	Heartbeat batch failure	Degraded mode: local SIGIL buffering	Auto-sync on reconnect
Seed node failure	Multiple Ring 0 MCPs unreachable	Promote backup seed from Ring 0	BFT consensus on new seed set
Red-line violation	Admission check or runtime scan	Instant quarantine, no quorum needed	Terminal — requires code fix + re-admission

9. Security Properties

Zero central broker: Discovery is peer-to-peer via well-known manifests. No single point of failure.
Cryptographic identity: Every MCP has an Ed25519 key pair. Manifests are signed. Identity is verified on every interaction.
Tamper-evident: Manifest hashes are compared each cycle. Any change triggers re-admission review.
SIGIL-attested: Every federation event is permanently logged with Ed25519 + RFC3161 + Bitcoin OTS anchoring.
Ring isolation: Cross-ring discovery is mediated by Ring 0. Defence and civil data never mix.
Red-line enforced: Red-line compliance is checked at admission and continuously. Violations trigger instant quarantine.

10. Current Federation State

Metric	Value
Total MCPs federated	30
Total tools discoverable	156
Active	30 (100%)
Quarantined	0
Red-line violations (all-time)	0
Avg discovery latency	47ms (LAN) / 230ms (WAN)
SIGIL receipts (federation events)	3,892
Manifest integrity checks	14,567 (0 tamper detected)