Cross-Chain Governance

01Executive Summary

JIL Sovereign introduces a cross-chain governance protocol that enables governance proposals to execute atomically across multiple blockchains. Voting occurs on the primary governance chain (JIL L1), and upon approval, the proposal's execution payload is propagated to each target chain via Merkle proofs. A two-phase commit protocol ensures that either all target chains execute the proposal successfully, or all chains automatically roll back to their pre-proposal state.

The protocol addresses the fundamental challenge of multi-chain governance: how to make coordinated changes across independent blockchain networks without risking partial execution states that leave the system in an inconsistent configuration. The two-phase commit - Prepare (lock state, validate preconditions) followed by Execute (state changes within a 2-block window) - provides the atomicity guarantee.

02Problem Statement

As protocols expand across multiple blockchains (Ethereum, Solana, L2 rollups, application-specific chains), governance becomes fragmented. A parameter change that should apply uniformly across all deployments requires separate governance votes or manual coordination on each chain, creating windows of inconsistency that can be exploited.

2.1 Multi-Chain Governance Failures

03Technical Architecture

3.1 Cross-Chain Proposal Structure

{
  "proposal_id": "gov-2026-0042",
  "title": "Update Settlement Fee to 4bps Across All Chains",
  "voting_chain": "jil-mainnet-1",
  "quorum": "14-of-20 validators",
  "approval_threshold": "66%",
  "target_chains": [
    {
      "chain": "jil-mainnet-1",
      "contract": "0xSettlement...abc",
      "action": "setFee(4)",
      "preconditions": ["current_fee != 4", "contract.paused == false"]
    },
    {
      "chain": "ethereum-mainnet",
      "contract": "0xJILBridge...def",
      "action": "updateSettlementFee(4)",
      "preconditions": ["bridge.active == true"]
    },
    {
      "chain": "solana-mainnet",
      "program": "JILBridge111...xyz",
      "instruction": "update_fee",
      "data": {"new_fee_bps": 4},
      "preconditions": ["program.initialized == true"]
    }
  ],
  "execution_window_blocks": 2,
  "rollback_timeout_blocks": 10
}

3.2 Two-Phase Commit Protocol

3.3 Merkle Proof Propagation

The governance vote result on the primary chain is committed to a Merkle tree. Each target chain receives a Merkle proof proving that the proposal was approved with the required quorum. The proof is verified by the governance receiver contract on each target chain against the known root hash. This eliminates trust in relay infrastructure - the proof is self-verifying.

04Implementation

4.1 Execution State Machine

PROPOSED -> VOTING -> APPROVED -> PREPARING -> PREPARED -> EXECUTING -> EXECUTED
                  |                    |                        |
                  v                    v                        v
               REJECTED            ABORTED                  ROLLED_BACK

1. PROPOSED: Proposal submitted to governance chain with target chain payloads.
2. VOTING: Validators vote during the governance window (default: 72 hours).
3. APPROVED: Quorum reached (14-of-20 validators, 66% approval). Merkle proof generated.
4. PREPARING: Merkle proofs transmitted to all target chains. Each chain validates preconditions and locks state.
5. PREPARED: All target chains report PREPARED. Timeout: 10 blocks. If any chain fails to prepare, transition to ABORTED.
6. EXECUTING: EXECUTE signal broadcast. Each chain applies state changes within 2-block window.
7. EXECUTED: All chains confirm execution. Proposal complete.
8. ROLLED_BACK: If any chain fails during execute, all chains revert to pre-prepare state.

4.2 Automatic Rollback Mechanism

Each governance receiver contract maintains a state snapshot taken at the PREPARE phase. If the EXECUTE phase fails on any target chain (transaction reverts, timeout exceeded, or precondition no longer met), the rollback signal propagates to all chains. Each chain restores the snapshot state and releases its lock. The rollback is automatic and does not require human intervention.

4.3 Bridge Attestation for Status Reporting

Target chains report their PREPARED and EXECUTED status back to the governance chain via the existing 14-of-20 bridge attestation protocol. Each bridge relayer independently observes the target chain state and signs an attestation. When 14 of 20 relayers attest to a chain's status, the governance chain updates the proposal state. This reuses the same security model as the cross-chain bridge without introducing new trust assumptions.

05Integration with JIL Ecosystem

5.1 Bridge Relayer

The bridge-relayer service (port 8150) serves as the communication layer for cross-chain governance. It transmits Merkle proofs to target chains, monitors execution status, and relays attestations back to the governance chain. The 14-of-20 multi-signature requirement applies to all governance attestations, ensuring that no single relayer can falsify execution status.

5.2 Corridor Governance

The corridor-governance service manages proposals that affect cross-border settlement corridors. When a corridor parameter change is approved, the two-phase commit ensures that both endpoint zones update simultaneously. This prevents the temporal inconsistency where one zone accepts transactions under new rules while the counterpart zone still operates under old rules.

5.3 Policy Registry

The policy registry service (port 8103) is a primary consumer of cross-chain governance actions. Compliance zone parameter updates, fee schedule changes, and asset restriction modifications that affect multiple chains flow through the cross-chain governance protocol to ensure atomic application.

5.4 Emergency Governance

For emergency actions (market halt, bridge pause, security incident response), the governance protocol supports an expedited path with a reduced voting window (1 hour instead of 72 hours) and elevated quorum (16-of-20 instead of 14-of-20). Emergency proposals follow the same two-phase commit protocol to ensure atomicity even under time pressure.

06Prior Art Differentiation

07Implementation Roadmap

08Patent Claim