Public Proof Bulletin Board

01Executive Summary

The Public Proof Bulletin Board is an immutable, append-only registry of cryptographic proofs that serves as the transparency backbone of the JIL Sovereign platform. Every significant protocol event - solvency attestations, compliance certifications, settlement confirmations, and audit receipts - is recorded as a verifiable entry on the bulletin board, allowing any third party to independently verify the platform's operational integrity without requiring privileged access.

Each bulletin board entry contains a proof type identifier, ZK-SNARK proof data, a validator-signed timestamp, the signatures of the attesting validators, and an on-chain reference to the underlying event. The board is append-only by construction - entries can never be modified or deleted, creating a permanent, tamper-evident record of all protocol operations.

02Problem Statement

Trust in financial platforms is traditionally established through periodic audits, regulatory filings, and third-party attestations. These mechanisms operate on weeks-to-months cycles, creating large windows of opacity during which platforms can become insolvent, manipulate records, or operate outside compliance bounds without detection.

2.1 The Opacity Problem

• FTX (2022): Appeared solvent in quarterly reports while secretly insolvent. No real-time solvency verification was available to any external party.
• Celsius (2022): Published marketing materials claiming full reserves while operating with massive shortfalls. Users had no way to verify claims independently.
• Traditional Audits: Annual or quarterly audits provide a point-in-time snapshot. A platform can be solvent on audit day and insolvent the next day. The gap between audits is a trust black box.
• Proof-of-Reserves: Merkle-tree based proof-of-reserves (as popularized post-FTX) prove assets exist but do not prove liabilities, compliance state, or operational integrity.

03Technical Architecture

3.1 Four Proof Categories

3.2 Bulletin Board Entry Structure

{
  "entry_id": "bb-2026-02-20-solvency-00042",
  "category": "SOLVENCY_ATTESTATION",
  "proof_type": "groth16",
  "proof_data": {
    "pi_a": ["0x1a2b...", "0x3c4d..."],
    "pi_b": [["0x5e6f...", "0x7a8b..."], ["0x9c0d...", "0xef12..."]],
    "pi_c": ["0x3456...", "0x7890..."],
    "public_inputs": [
      "1",                    // assets >= liabilities (boolean)
      "1708387200",           // timestamp
      "42"                    // epoch number
    ]
  },
  "timestamp": "2026-02-20T12:00:00Z",
  "block_height": 420000,
  "validator_signatures": [
    {"validator": "jil-validator-genesis", "sig": "ed25519(...)"},
    {"validator": "jil-validator-us", "sig": "ed25519(...)"}
    // ... 14 of 20 required
  ],
  "on_chain_ref": "0xabc123...def456",
  "prev_entry_hash": "sha256(previous entry)"
}

3.3 Append-Only Chain Structure

Each bulletin board entry contains a hash of the previous entry, forming an append-only chain similar to a blockchain block structure. This ensures that entries cannot be reordered, inserted retroactively, or deleted without breaking the hash chain. Any external observer can verify the integrity of the entire board by re-computing the hash chain from the genesis entry.

04Implementation

4.1 Proof Generation Pipeline

1. Data Collection: The proof-verifier service (port 8250) collects the inputs for each proof category from the relevant services (ledger for solvency, compliance-api for certifications, settlement for confirmations).
2. Circuit Execution: ZK-SNARK circuits (Groth16 or PLONK) execute on the collected inputs, producing a proof that the stated property holds without revealing the underlying data.
3. Validator Signing: The proof is broadcast to all 20 validators. Each validator independently verifies the proof and, if valid, signs the bulletin board entry.
4. Threshold Assembly: When 14 of 20 validator signatures are collected, the entry is finalized and appended to the bulletin board.
5. On-Chain Anchoring: The entry hash is written to the L1 ledger, creating a permanent on-chain anchor that links the bulletin board to the immutable blockchain.

4.2 Verification API

05Integration with JIL Ecosystem

5.1 Proof Verifier Service

The proof-verifier service (port 8250) is the primary engine for ZK proof generation and verification. It maintains the ZK circuits for each proof category, manages the prover keys, and coordinates the validator signing rounds. All proofs generated by the proof-verifier are posted to the bulletin board.

5.2 Proof Gateway

The proof-gateway service provides the public-facing API for the bulletin board, serving proof data to external verifiers, regulators, and auditors. It implements rate limiting and caching but does not require authentication for read access - the entire bulletin board is public by design.

5.3 Proof Page (User-Facing)

The proof-page application provides a visual interface for browsing the bulletin board. Users can see the most recent solvency attestation, verify their own settlement proofs, and browse the complete history of compliance certifications. Each proof includes a one-click verification button that runs the verification locally in the browser using WebAssembly.

5.4 Explorer Integration

The block explorer links on-chain proof anchors to the corresponding bulletin board entries. When a user views a block that contains a proof anchor, they can navigate directly to the full proof entry and verify it independently.

06Prior Art Differentiation

07Implementation Roadmap

08Patent Claim