Platform

Overview

How It Works

Beneficiary Identity

Policy Corridors

Deterministic Finality

Architecture

Security Model

Governance

Integration

Solutions

Corridors Overview

Institutional Overview

Pricing

All Scenarios

Humanitarian Impact Fund

Assurance

Technical Assurance

Verify Receipt

Receipt Example

Developers

Documentation

APIs & Bridges

Architecture Docs

Glossary

BID API

Company

About

Team

Partners

Roadmap

Investors

Contact

Blog

All Documentation

Schedule Consultation
Settlement Architecture - v95

Cryptographic Settlement Consensus

Ed25519-signed settlement finality across 13 jurisdictions. Every settlement is independently hash-verified, cryptographically signed, and batch-optimized via Merkle roots. Real-time validator health monitoring with automatic equivocation detection.

Ed25519 Signatures
14-of-20 BFT Quorum
Batch Merkle Consensus
Equivocation Detection
Consensus Architecture

Ed25519 Cryptographic Consensus

Each validator independently verifies settlement data, computes the hash, and signs with its persistent Ed25519 keypair. No validator trusts the coordinator's hash - every signature represents independent verification.

Ed25519
Signing Algorithm
Each validator holds a persistent Ed25519 keypair. Keys are auto-registered with JILHQ via heartbeat protocol.
70%
BFT Threshold
14-of-20 validators must independently verify and sign before finality is declared. No single point of failure.
10s
Heartbeat Interval
Every validator pings JILHQ every 10 seconds with status, height, uptime, and rounds signed.
5s
Sweep Interval
Stale rounds are auto-detected every 5 seconds. Rounds with sufficient signatures are retroactively finalized.
Merkle
Batch Consensus
Multiple settlements signed in a single round via Merkle root. Each settlement independently verified before root signing.
0
Trust Assumptions
Validators never trust the coordinator's hash. Settlement data is re-hashed independently before any signature is produced.
How It Works

Settlement Signing Flow

From settlement submission to cryptographic finality, every step is verified independently by each validator. The coordinator (JILHQ) orchestrates but cannot forge signatures or manipulate hashes.

Single Settlement Consensus

01
Submit
Settlement data submitted to JILHQ with zone_id and full transaction details
POST /v1/consensus/submit
02
Hash
JILHQ computes settlement hash (SHA-256 of canonical JSON) and creates consensus round
SHA-256 canonical
03
Broadcast
Full settlement data + claimed hash sent to all healthy validators via JSON-RPC
consensus_sign RPC
04
Verify
Each validator independently re-computes hash from settlement data. Refuses to sign if hash mismatch.
hash_verified: true
05
Sign
Validator signs verified hash with its persistent Ed25519 private key and returns signature + public key
Ed25519 sign
06
Finalize
JILHQ verifies signatures, checks for equivocation, and finalizes when quorum (70%) is met
14-of-20 BFT

Batch Consensus (Merkle Root)

01
Batch Submit
Multiple settlements submitted together in a single request
POST /v1/consensus/batch-submit
02
Hash Each
JILHQ computes individual SHA-256 hash for each settlement in the batch
N x SHA-256
03
Merkle Root
Binary Merkle tree built from individual hashes. Root represents entire batch.
SHA-256 Merkle tree
04
Verify All
Each validator re-hashes every settlement, rebuilds Merkle tree, verifies root matches
consensus_batch_sign
05
Sign Root
Validator signs the verified Merkle root with Ed25519. One signature covers all settlements.
Ed25519 sign root
06
Finalize
Quorum met on Merkle root finalizes all settlements atomically. No partial finalization.
atomic batch finality
Safety Mechanisms

Four Layers of Consensus Safety

Beyond BFT quorum, JIL enforces real-time validator health monitoring, automatic equivocation detection, round timeout management, and cryptographic signature verification.

Heartbeat Monitoring

Real-time - 10s interval
  • 01
    Validator Heartbeat
    Every 10 seconds, each validator sends status to JILHQ: height, uptime, rounds signed, public key, zone
  • 02
    Health Tracking
    JILHQ records heartbeat history, updates node status, and auto-registers Ed25519 public keys
  • 03
    Stale Detection
    Validators with no heartbeat for 30+ seconds are automatically marked degraded and excluded from consensus rounds
10s
Heartbeat
30s
Stale Threshold
Auto
Key Registration

Equivocation Detection

Slashable - Evidence-based
  • 01
    Signature Audit
    After each signing round, JILHQ checks if any validator signed conflicting hashes for the same settlement
  • 02
    Evidence Recording
    Conflicting signatures are recorded as immutable evidence: both round IDs, both hashes, both signatures
  • 03
    Penalty Escalation
    First offense: warned. Second offense: suspended from consensus. Equivocating signatures are excluded from quorum.
0
Tolerance
2
Strikes
Immutable
Evidence
Industry Comparison

JIL vs. Legacy Settlement

How JIL Sovereign's cryptographic consensus compares to traditional settlement infrastructure across every dimension that matters to institutions.

Dimension JIL Sovereign SWIFT DTCC Ripple/XRP
Settlement Finality T+0 atomic (deterministic BFT, 9-state machine) T+1 to T+2 (message relay) T+1 (central clearing) ~4 seconds (probabilistic)
Settlement Types SIMPLE, DVP (Delivery vs Payment), PVP (Payment vs Payment) - atomic multi-leg Message-based instructions DVP (central netting) Single-leg transfers only
Settlement Lanes FI-to-FI, FI-to-Crypto, Crypto-to-Crypto - lane-specific compliance FI-to-FI only FI-to-FI only Crypto-to-Crypto only
State Machine 9 states: received, validated, compliance_check, accepted, ready, submitted, confirmed, final (+ 4 terminal) 3-4 states (sent, received, acknowledged) 5-6 states (proprietary) 3 states (proposed, validated, applied)
Consensus Model 14-of-20 BFT, Ed25519 signed None (centralized messaging) None (central counterparty) UNL (80% of trusted list)
Signing Algorithm Ed25519 per validator PKI certificates (RSA) Proprietary PKI Ed25519 (network level)
Hash Verification Independent per validator N/A (message forwarding) Central computation Proposer computes
Batch Optimization Merkle root signing (N settlements, 1 signature per validator) Netting windows (end of day) Batch netting (T+1) None (individual txns)
Equivocation Detection Real-time, evidence-based, auto-penalty N/A N/A None (trusted UNL)
Validator Monitoring 10s heartbeat, auto-health, auto-key-registration SLA monitoring (manual) Uptime monitoring (manual) Peer health (gossip)
Round Timeout 5s sweep, auto-finalize if quorum met N/A N/A Ledger timeout (4s)
Geographic Distribution 20 validators, 13 jurisdictions Centralized (US/EU) Centralized (US) ~35 UNL nodes (concentrated)
Settlement Fee Subscription + per-event ($0.50 base); volume-based bps available for high-value corridors $0.04-$0.20 per message Variable clearing fees ~0.00001 XRP (~$0.00)
Fee Timing At finality only - no fee if settlement never reaches final state Per message sent At netting/clearing At transaction broadcast
Travel Rule Evaluated per-leg during compliance_check state for FI-to-FI and FI-to-Crypto lanes Manual compliance (gpi) Participant responsibility Not enforced
BEC Prevention Beneficiary identity binding and BEC prevention gate. Final receipts include bec_check_result. Manual verification Not enforced Not enforced
Post-Quantum Dilithium/Kyber at protocol level Not planned Under evaluation Not planned
Compliance Zones 10 regulatory zones (FINMA, FinCEN, MAS, FCA, BaFin, JFSA, FSRA, ESMA, CVM, FATF) Country-level routing US-focused None (global pool)
Humanitarian Allocation 10% of settlement fees, protocol-level, immutable None None None
Settlement Flows

Two Modes, One Chain

Both permissionless DeFi and permissioned institutional settlement run on the same Layer 1 with shared Ed25519 validator consensus and liquidity depth.

DeFi Settlement

Permissionless - Algorithmic
  • 01
    Transaction Initiated
    User signs via wallet, no intermediary required
  • 02
    ZK Compliance Check
    Zero-knowledge proof validates eligibility without exposing PII
  • 03
    AMM / DEX Execution
    Automated market maker settles trade on-chain
  • 04
    Atomic Settlement
    Ed25519 consensus finality, 10% humanitarian fee auto-allocated
<3s
Finality
Open
Access
ZKP
Privacy
None
Intermediary

Institutional Settlement

Permissioned - 9-State Machine - DVP/PVP
  • 01
    Receive & Validate
    Institution submits settlement (SIMPLE, DVP, or PVP). Structural validation, then compliance check with travel rule evaluation.
  • 02
    Accept & Readiness
    Compliance passed. DVP/PVP: both parties attest readiness. SIMPLE: auto-promoted. Three lanes: FI-to-FI, FI-to-Crypto, Crypto-to-Crypto.
  • 03
    Ed25519 Consensus
    Submitted to L1. Validators independently verify hash, sign with Ed25519, quorum collected.
  • 04
    Finality & Fee
    Cryptographic finality receipt. Per-event fee applied at finality. No fee if settlement never reaches final state.
T+0
Settlement
Sub + Event
Fee Model
Full
Audit Trail
Ed25519
Signatures
Unified Architecture

Shared Infrastructure, One Chain, Two Modes

Both settlement types run on JIL's Layer 1 with unified Ed25519 validator consensus, shared liquidity depth, and embedded humanitarian allocation.

🔗

Unified L1

Single consensus layer with Ed25519-signed BFT validators across 13 jurisdictions

🛡

ZK Compliance

Privacy-preserving proofs bridge DeFi openness and institutional regulation

💧

Shared Liquidity

Predictive liquidity pools serve both permissioned and open markets

🌎

10% Impact Fee

Every settlement, DeFi or institutional, allocates 10% to humanitarian outcomes

Safety Architecture

Built for Trust. Engineered for Safety.

Unlike centralized exchanges or single-chain validators, JIL's multi-jurisdictional design with Ed25519 cryptographic signing ensures no regulatory action, infrastructure failure, or coordinated attack can compromise the network.

Independent Hash Verification

Every validator independently computes the settlement hash from raw transaction data before signing. The coordinator sends full settlement details - not just a hash to rubber-stamp. If a validator's computed hash differs from the claimed hash by even a single bit, the validator refuses to sign and logs the mismatch. This eliminates the possibility of a compromised coordinator forging settlement data.

Deterministic BFT Finality

Many blockchains use probabilistic finality where transactions could theoretically be reversed with enough hash power. JIL uses deterministic BFT consensus: once 14-of-20 validators independently verify and Ed25519-sign a settlement, it is final. There is zero risk of chain reorganization or settlement reversal. This is the standard institutions require.

Real-Time Validator Health

Every 10 seconds, each validator sends a heartbeat to JILHQ containing its current block height, uptime, rounds signed, compliance zone, and Ed25519 public key. Validators that miss heartbeats for 30 seconds are automatically marked degraded and excluded from consensus rounds. This ensures only healthy, responsive validators participate in settlement finality.

Equivocation Is Slashable

If a validator signs conflicting hashes for the same settlement (equivocation), the evidence is recorded immutably: both signatures, both hashes, both round IDs. The validator receives a warning on first offense and is suspended from consensus on the second. Equivocating signatures are excluded from quorum calculation, ensuring they cannot influence finality.

Batch Efficiency via Merkle Trees

High-throughput periods use batch consensus: multiple settlements are individually verified, then combined into a binary Merkle tree. Validators verify each settlement independently, rebuild the Merkle tree, confirm the root matches, and sign the root once. One Ed25519 signature per validator covers the entire batch. This provides O(1) signature overhead regardless of batch size while maintaining per-settlement verification integrity.

Quantum-Resistant from Day One

Most blockchain networks rely on elliptic curve cryptography that will be broken by quantum computers. JIL implements NIST-standard Dilithium (digital signatures) and Kyber (key encapsulation) at the protocol level. The Ed25519 consensus layer provides immediate production security while the post-quantum layer ensures long-term protection against quantum threats.

For Institutions, Funds & Payment Processors

Settlement infrastructure that institutions can trust.

Ed25519 consensus. T+0 finality. Batch Merkle signing. Real-time validator monitoring. 13 jurisdictions.