Example: Independent Sovereigns Proof

This example proves the operational gap called out after the v0.9 through v0.12 trust-roadmap releases: the same direct-recognition and revocation protocol works across two different cloud VMs.

The proof uses one Network Authority on Azure as Sovereign A and one Network Authority on DigitalOcean as Sovereign B:

Sovereign	Provider	Network name	Endpoint
Sovereign A	Azure	USG	https://na.genesismesh.connectorzzz.com
Sovereign B	DigitalOcean	USG-NB	http://164.92.250.135:8443

        sequenceDiagram
    participant NB as Sovereign B: USG-NB (DigitalOcean)
    participant AZ as Sovereign A: USG (Azure)
    participant F as Signed NB Revocation Feed
    participant C as Azure Connectome

    NB->>NB: Issue MembershipAttestation
    AZ->>AZ: Issue RecognitionTreaty for USG-NB
    NB-->>AZ: Present attestation
    AZ-->>NB: accepted through treaty
    NB->>NB: Revoke attestation
    NB->>F: Publish signed feed sequence 1
    AZ->>AZ: Import NB feed under treaty subject key
    NB-->>AZ: Present same attestation
    AZ-->>NB: rejected: attestation_locally_revoked
    AZ->>C: GET /connectome.json
    C-->>AZ: USG -> USG-NB edge and revocation blast radius
    

What This Proves

• Sovereign identities are independent: Azure advertises USG, while DigitalOcean advertises USG-NB.

• Direct recognition crosses a real network boundary between cloud providers.

• Azure accepts an NB-issued membership attestation only after signing a treaty for NB’s public Network Authority key.

• NB controls withdrawal of its own attestation through a signed revocation feed.

• Azure imports that feed and rejects the same attestation without revoking the broader treaty.

• Azure’s Connectome explains the trust path and imported revocation blast radius from the persisted graph state.

Live Recording

Static screenshot:

Verified Evidence

The clean proof was run from a pristine Connectome state on both authorities.

Azure: USG
DigitalOcean NB: USG-NB
Attestation: 3ee9bc08-9685-461b-8b00-ed4ff05a8c16
Treaty: 3b11b22d-a888-4c09-b6a0-f55a4161ba40
Revocation feed: aeee77fb-1d76-4334-aa1a-4b0602969567
Feed sequence: 1
Before revocation: accepted=true / accepted
After revocation import: accepted=false / attestation_locally_revoked
Trust path: USG -> USG-NB / active_treaty_path

Final Azure Connectome summary:

{
  "sovereign_count": 2,
  "recognition_edge_count": 1,
  "active_edge_count": 1,
  "imported_revocation_count": 1,
  "revoked_trust_material_count": 1
}

Run

To regenerate the documentation assets from the captured transcript:

python docs\examples\assets\scripts\independent-sovereigns-demo.py

The default command is non-mutating. It renders the verified transcript into PNG and GIF assets.

To run the live proof again against the two VMs, pass --live from a machine that has the operator key configured:

python docs\examples\assets\scripts\independent-sovereigns-demo.py `
  --live `
  --operator-key .genesis-mesh\keys\operator.key

Live mode creates a new NB attestation, a new Azure recognition treaty, imports a new NB revocation feed, and leaves those proof artifacts in Azure’s Connectome until cleaned.

For operator workflows, the supported CLI proof runner performs the same live flow and writes a redacted proof bundle:

genesis-mesh proof remote `
  --acceptor https://na.genesismesh.connectorzzz.com `
  --issuer http://164.92.250.135:8443 `
  --operator-key .genesis-mesh\keys\operator.key `
  --operator-key-id operator-local `
  --claim proof=independent-sovereigns `
  --proof-bundle .\independent-sovereigns-proof.json

Clean State

Before capturing a clean proof, the proof tables should be empty on both authorities. Use the cleanup command while the NA service is stopped; it backs up the database first and removes only proof artifacts:

sudo systemctl stop genesis-mesh-na
genesis-mesh proof cleanup \
  --db-path /var/lib/genesis-mesh/na.db \
  --backup-dir /var/lib/genesis-mesh \
  --yes
sudo systemctl start genesis-mesh-na

The cleanup command uses Python’s SQLite library instead of the sqlite3 CLI because minimal Ubuntu VMs do not always have the SQLite command-line tool installed.

Expected clean Connectome:

{
  "active_treaties": [],
  "recognition_edges": [],
  "revocation_blast_radius": [],
  "revoked_trust_material": [],
  "sovereigns": [],
  "summary": {
    "active_edge_count": 0,
    "imported_revocation_count": 0,
    "recognition_edge_count": 0,
    "revoked_edge_count": 0,
    "revoked_trust_material_count": 0,
    "sovereign_count": 0
  }
}

Operational Meaning

The roadmap releases proved the protocol in maintainer-operated demos. This independent-sovereign proof shows the same mechanism crossing from protocol proof to operational proof: separate VMs, separate databases, separate genesis identities, separate Network Authority keys, and a real cloud-provider network boundary.

This is still not multi-cloud operation proof. Adoption begins when external operators run their own sovereigns and create recognition edges that do not depend on the maintainer operating both sides.