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
Architecture Assurance

Trust Boundary Diagram

Visual mapping of trust boundaries across 6 architectural layers. Each boundary represents a point where authentication, authorization, or data validation occurs. Understanding these boundaries is essential for security evaluation.

← All Assurance

System Trust Boundary Diagram

The diagram below shows how data flows through JIL's architecture, crossing trust boundaries at each layer. Orange dashed lines indicate trust boundary crossings where authentication or validation is enforced.

Layer 1: External (Untrusted)
Web Browser
User device
Mobile App
User device
API Client
Integration partner
Ethereum
Bridge deposits
Trust Boundary: TLS + Authentication
Layer 2: Edge (CDN / Proxy)
Cloudflare
TLS termination, DDoS
Caddy
Reverse proxy
Trust Boundary: JWT Validation
Layer 3: Application (API Services)
Wallet API
:8002
Explorer API
:8003
Launchpad API
:8004
BID Service
:8750
Trust Boundary: MPC Authorization
Layer 4: Settlement Protocol
MPC Cosigner
:8200
Compliance API
:8100
Ledger Router
:8000
Bridge Relayer
:8150
Trust Boundary: Consensus Protocol
Layer 5: Consensus (Validators)
Validator Node
Rust (L1)
Proof Verifier
:8250
Settlement Consumer
:8051
Trust Boundary: Cryptographic Verification
Layer 6: Data (Persistence)
PostgreSQL
Ledger state
Redis
Cache / session
Kafka
Event stream
S3 Storage
Documents / backups

Trust Boundary Details

Each trust boundary enforces specific authentication and validation rules. Crossing a boundary without proper credentials results in request rejection.

Boundary 1: TLS + Authentication

External to Edge

All external traffic must use HTTPS (enforced by Cloudflare). API requests require JWT bearer tokens. WebAuthn provides passwordless authentication for wallet operations.

Boundary 2: JWT Validation

Edge to Application

Caddy forwards authenticated requests to backend services. Each API service validates JWT claims including user identity, permissions, and token expiry. CORS enforcement restricts origins.

Boundary 3: MPC Authorization

Application to Settlement

Settlement requests require MPC 2-of-3 signing ceremony. The user's key shard must participate. Policy engine evaluates corridor rules before forwarding to consensus.

Boundary 4: Consensus Protocol

Settlement to Validators

Settlement proposals are broadcast to the validator network. 14-of-20 must attest before finalization. Each validator independently evaluates the proposal against its policy engine.

Boundary 5: Cryptographic Verification

Validators to Data

All data writes to the ledger are cryptographically signed. Hash chains provide tamper detection. Data reads verify integrity before serving.

Boundary 6: External Chain

Bridge to Ethereum

Bridge operations verify deposit events on Ethereum via the chain watcher. Smart contract interactions use verified ABI. Rate limits bound bridge throughput.

Data Flow Classification

Data TypeClassificationEncryptionBoundary Restrictions
User key shardsCriticalAES-256-GCM at rest, never transmittedNever leaves Layer 4 (MPC cosigner)
Validator signing keysCriticalAES-256-GCM at rest, HSM storageNever leaves Layer 5 (validator node)
Settlement dataConfidentialTLS in transit, encrypted at restPartitioned by jurisdiction at Layer 5
Identity verificationConfidentialTLS in transit, hashed at restProcessed at Layer 3 (BID), not stored in ledger
Public blockchain dataPublicTLS in transitRead-only from Layer 6, served via Layer 3
Monitoring telemetryInternalInternal network onlyCollected at Layer 5, processed at JILHQ

Authentication Methods by Layer

LayerAuthenticationAuthorization
External to EdgeTLS client hello, Cloudflare WAFRate limiting, IP reputation
Edge to ApplicationJWT bearer token, WebAuthnRole-based (user, admin, service)
Application to SettlementMPC signing ceremonyPolicy corridor matching
Settlement to ValidatorsEd25519 proposal signature14-of-20 attestation threshold
Validators to DataService credentials, connection poolingSchema-level access control
JILHQ to ValidatorsAPI key (x-api-key header)HMAC-authenticated commands

External Integration Points

The following external systems interact with JIL across trust boundaries. Each integration point has specific security controls.

  • Ethereum mainnet: Bridge deposits/withdrawals via JILBridge.sol. Chain watcher reads events from verified contract address only.
  • Cloudflare: TLS termination, DNS resolution, DDoS protection. Within trust boundary for edge operations.
  • Hetzner infrastructure: Server hosting. Not trusted for data integrity - all data is cryptographically verified.
  • Identity verification vendors: BID service integrates with 7 external vendors for KYC checks. Vendor responses are verified and cached.
  • Hetzner S3: Object storage for documents and backups. Encrypted at rest, access key authenticated.

Ready to verify?

Start with a structured POC. Evaluate JIL settlement infrastructure on a single corridor.

Request a POC All Assurance