How JIL attests without holding the asset.
A custodian sends a transit to JIL for pre-clearance. Four stages run in parallel for 350ms. JIL returns a court-ready Pre-Settlement Attestation signed by 14 of 20 validators across 13+ jurisdictions. The custodian then decides whether to broadcast. The asset never enters JIL.
Custody is solved. The transit is not.
Institutional crypto custodians (Fireblocks, BitGo, Anchorage Digital) keep customer keys safe. They have policy engines, MPC signing, multi-sig vaults. What they do not have, today, is an independent third party that can attest, transit by transit, that the destination of an outbound transfer is still benign at the moment of signing. KYC happens at customer onboarding. Sanctions screens once a day. The transit itself is the gap. The Ronin Bridge attack in March 2022 cost $625M because every check passed at onboarding, the sanctions list refreshed yesterday, and the destination was still technically valid - but at the moment of broadcast, the receiver had been newly attributed to Lazarus. Pre-Clearance is the fourth-party signal that closes that gap.
One request in, one signed verdict out.
Read the diagram top-to-bottom. The custodian's request goes UP into JIL. The signed attestation comes DOWN. The asset itself goes ACROSS the bottom, custodian directly to exchange, never through JIL.
Four steps, end to end.
1 Custodian asks before signing.
The custodian's policy engine (Fireblocks TAP, BitGo policy, Anchorage rules) is configured to call POST /v1/preclearance/validate before approving any outbound transfer. The request body names the source address, the destination address, the asset, the amount, the sender and receiver IDs. It is signed with HMAC-SHA256 over canonical bytes.
2 JIL runs four checks in parallel.
The endpoints stage looks up the source and destination addresses in our 33,547-row labeled-wallet index (sanctioned wallets, DPRK attribution, mixers, scam wallets, exchange hot wallets, DeFi routers, bridges). The KYC stage verifies sender and receiver. The sanctions stage screens against OFAC, UN, EU, UK, and OpenSanctions. The risk stage scores velocity, novelty, and graph distance. All four return in 350ms p50.
3 Fourteen validators sign.
The four findings are rolled up into a verdict (pass / flag / fail). Fourteen of twenty validators across thirteen jurisdictions independently sign the canonical bytes with Ed25519. The signatures, the findings, the verdict, the addresses, and a 60-second validity window are bundled into a Pre-Settlement Attestation (PSA), persisted to JIL's database, and returned to the custodian.
4 Custodian decides. Asset moves.
The custodian's policy engine reads the verdict and applies its existing rules. JIL does not approve, freeze, or hold the asset. If the policy proceeds, the on-chain transfer goes directly from the custodian's wallet to the exchange's deposit address, on the relevant chain, on the relevant wallet stack. JIL is never in the value path. The exchange can optionally call POST /v1/preclearance/verify with the PSA to confirm authenticity before crediting the deposit.
Real public data, not stubs.
Every stage backs onto real ingested public data. No paid Chainalysis or TRM subscription assumed. Customers can layer their own paid feeds on top via webhook for richer signals.
Stage 1 · Endpoints / address consensus
Address-intelligence index merged from 6 anonymous public sources, refreshed by scripts/pull-address-intel.ts:
- OFAC SDN crypto mirror - 121 addresses across 7 chains (ETH/BSC/BCH/XMR/LTC/ZEC/DASH)
- ScamSniffer community phishing - 2,530 EVM addresses
- MEW Ethereum darklist - 715 curated entries
- Etherscan label cloud - 29,945 labeled addresses (CEX hot wallets, DEX routers, bridges, mixers)
- DefiLlama protocols - 1,811 on-chain DeFi protocol contracts
- DPRK / Lazarus attribution seed - 6 publicly-attributed Lazarus wallets (Ronin, Atomic Wallet, Stake.com, CoinEx, Alphapo)
Hard-fail on sanctioned, DPRK, mixer, scam categories. Informational pass on exchange, DeFi, bridge categories. Source provenance for every match is in the PSA.
Stage 2 · KYC / AML
Forwards to JIL's internal kyc-service (separate microservice):
- Sender / receiver identity verification against the custodian's onboarding records (referenced by
sender_idandreceiver_id) - Corridor risk assessment using FATF high-risk + monitored jurisdictions list
- IBAN MOD-97 validation + BIC ISO 9362 structural check for fiat-leg sanity
- Cross-border EDD trigger on flagged corridors or instruction-change events
Output: sender status, receiver status, AML flags, jurisdictions checked, corridor risk band.
Stage 3 · Sanctions
Forwards to JIL's local-cache sanctions service. Daily-refreshed merged list:
- OFAC SDN - 37,900 entries + 720 crypto addresses
- OFAC SDN crypto mirror (multi-chain, see Stage 1)
- UN Consolidated Sanctions - 1,000 entries
- EU CFSP - 6,000 entries (direct + OpenSanctions federation)
- UK HMT - 39,500 entries
- US Consolidated Screening List - 25,600 entries
- OpenSanctions / Yente - 74,600 entries
- OIG LEIE + SAM.gov exclusions for healthcare + government corridors
Two-stage matcher: postgres token prefilter narrows ~13K SDN rows to under 100 candidates; in-memory jaro-winkler + token-subset + initials scoring at 0.85 threshold.
Stage 4 · Risk
Forwards to JIL's risk-scoring service. Local heuristics + credential-registry forward:
- Amount-deviation z-score against historical sender behavior
- Velocity check - transfers per 60-second window
- Novel destination flag - has this counterparty ever received from this sender?
- Graph distance to sender - on-chain hops between source and destination
- Large-transfer escalation - $1M+ transfers add 35 points
- Suspicious-suffix detection - addresses ending in known patterns (vanity-address scams)
Output: integer score (0-100), risk band (low / elevated / high), signal breakdown, upstream attribution.
Findings, not approvals.
What is in a Pre-Settlement Attestation
- PSA UUID, transit ID, timestamp, validity window (60s default)
- Source + destination address, asset, amount (native + USD)
- Sender + receiver IDs, custodian + exchange names
- Four stage findings, each with its own status (pass / flag / fail), duration, and details object
- Overall verdict (pass / flag / fail) by majority + severity rules
- 14 validator signatures with jurisdiction metadata
- Optional BLS aggregate signature for compact verification
- Fee record (25 bps default, $1 floor, basis + amount)
- CourtChain™ anchor reference (FRE 902(14) admissibility)
What JIL does NOT do
- JIL does not hold the asset. The asset never enters any JIL wallet, vault, or contract.
- JIL does not co-sign the on-chain transaction. Custodian's MPC signs; JIL signs only the attestation.
- JIL does not broadcast. The custodian sends the transaction to the chain.
- JIL does not approve or deny. JIL produces evidence; the custodian's policy engine produces decisions.
- JIL does not freeze. No freeze mechanism. No clawback. No pause.
- JIL does not see customer keys. Customer keys remain inside the custodian's MPC.
- JIL does not retain personally identifiable information beyond the audit window. PSAs reference IDs assigned by the custodian; JIL does not store name + address + DOB.
This separation is deliberate. It keeps JIL outside Money Transmitter Licensing (MTL) and MSB scope. Memo on file from outside counsel.
Pre-Clearance Co-Signing · Managed Egress.
The Pre-Clearance product line ships in two tiers. They are intentionally separated for regulatory, commercial, and risk reasons. See §4 of the Custodial Egress Design Document for the canonical specification.
Tier 1 · Pre-Clearance Co-Signing (default)
JIL is a required co-signer on egress transactions. JIL never takes possession of the asset. The custodian's MPC quorum retains all material custody. JIL contributes one share of a threshold signature scheme that is required only for transactions leaving the custodian's quorum boundary.
Regulatory posture: JIL operates as a compliance attestation provider and signature service. No money transmission. No custody. No trust company activity. Comparable in posture to a transaction monitoring or KYC vendor, with the addition of a cryptographic signing role that is structurally limited to compliance gating.
Status: PoCS attestation layer (§6.3) live in production today. Threshold cosigning (§5, §6.5) Phase 2 deployment target.
Tier 2 · Managed Egress (separately scoped)
JIL takes constructive custody of the asset for the duration of the transit window under an explicit Sealed Escrow trust agreement. JIL executes the venue interaction on behalf of the client, settles the proceeds, and returns them to the custodian or a designated address.
Regulatory posture: Requires state money transmitter licensing or trust charter in jurisdictions of operation, qualified custodian status where applicable, and explicit client trust agreements. Priced and contracted as a distinct service.
Status: Post-Phase 1 SOC 2 Type II completion. Use cases: institutional Metamask-to-DEX routing, OTC settlement, treasury rebalancing where the client wants JIL to actively manage execution rather than gate it.
Sixteen attack classes. Three layered defenses each.
Every attack class against the egress chain is mapped to a primary cryptographic defense, a secondary procedural defense, and a forensic record. No attack class is defeated by a single control. The layering is the security property.
| Attack Class | Primary Control | Secondary Control | Forensic Control |
|---|---|---|---|
| BGP / DNS / TLS interception | mTLS with cert pinning on every custodian-JIL-venue channel | Out-of-band confirmation on new destinations (§6.6) | CourtChain™ log of every channel handshake |
| RPC manipulation | Multi-source RPC broadcast with cross-validation (§6.7) | Inclusion attestation against finalized block (§6.8) | Discrepancy log on CourtChain™ |
| Mempool front-run / sandwich (MEV) | Private mempool / PBS broadcast (§6.7) | MEV-aware route attestation in PoCS (§6.3) | MEV exposure flag in CREB™ |
| Address poisoning | Destination provenance verification (§6.2) | Out-of-band confirmation (§6.6) | Lookalike detection log |
| Smart contract exploit | Route attestation includes contract risk score | Allowance / approval pre-image binding | Per-call CREB™ record |
| Sanctioned counterparty | RAN screening in PoCS (§6.3) - 33,547 labeled wallets live | Jurisdictional gating | Sanctions evidence in CREB™ |
| Bridge exploit | Route attestation rejects unproven bridges | Per-hop attestation requirement | Hop-by-hop CourtChain™ anchor |
| Compromised custodian operator | JIL co-signature requirement (§5.1) | Out-of-band confirmation (§6.6) | Operator identity in CREB™ |
| Compromised JIL operator | Threshold signing across 13+ jurisdictions (§5.3) | Hybrid PQC dual signature (§5.2) | Validator quorum log |
| Compromised venue address | Venue-side mTLS attestation (§6.2) | Allowlist cooling period | Venue signature in CREB™ |
| Classical or quantum crypto attack | Hybrid Ed25519 + Dilithium-III (§5.2) | Kyber KEM for any encrypted channel | Algorithm identifier in CREB™ |
| Signature malleability / nonce reuse | HSM-enforced deterministic nonces (FIPS 140-3 L3) | FROST / CMP protocol guarantees | Nonce log on CourtChain™ |
| TOCTOU between attestation and broadcast | Pre-image binding (§6.4) - Phase 1 today | Block height window in domain (§5.4) | Window evidence in CREB™ |
| Cross-chain / cross-window replay | Domain separation (§5.4) - Phase 1 today | Single-use UUID per request | Replay attempt log |
| Social engineering of approval | Out-of-band confirmation with hardware key (§6.6) | Named client officer registry | Officer signature in CREB™ |
Reading the matrix: Each row is an attack a sophisticated adversary will attempt. The Primary Control is the cryptographic defense (a signature requirement, an HSM enforcement, a threshold). The Secondary Control is the procedural defense if the primary is somehow degraded. The Forensic Control is what produces the evidence on CourtChain™ - so even when something goes wrong, the CREB™ package is admissible.
The pitch in three bullets.
One POST, four findings, fourteen signatures.
POST https://preclearance.jilsovereign.com/v1/preclearance/validate
X-JIL-Access-Key-Id: ak_live_...
X-JIL-Timestamp: 2026-05-03T17:14:32Z
X-JIL-Nonce: a4f9c2b8...
X-JIL-Signature: base64(hmac_sha256(secret, canonical))
{
"transit_id": "fb-2026050301-7c3a",
"source_addr": "0x7Bcf...aBa2",
"destination_addr": "0xbeefdeadbeefdeadbeefdeadbeefdeadbeefdead",
"asset": "ETH",
"amount_native": "12.5",
"amount_usd": 41250.00,
"sender_id": "fund-tax-id-37-3892034",
"receiver_id": "kraken-acct-2391",
"custodian": "fireblocks",
"exchange": "kraken"
}
Returns a PSA with verdict, four stage findings, fourteen signatures, attribution, and a 60-second validity window.
Tailored 3-slide briefs per integration partner.
Fireblocks
Pre-Clearance as a TAP external policy engine. Pre-signing /validate call, signed PSA back, custodian's TAP applies the verdict.
BitGo
Distributed BFT signing aligned with BitGo's distributed-custody ethos. 14-of-20 across 13+ jurisdictions, court-ready under FRE 902(14).
Read the BitGo briefAnchorage Digital
Compliance-first framing for federally-chartered custody. Non-custodial by construction, NIST CSF 2.0 mapping, EU residency, 60-day evaluation cycle.
Read the Anchorage brief