# JIL Custodial Egress Pre-Clearance

## Design Document for Institutional Custodian Integration

**Document Owner:** JIL Sovereign Technologies, Inc.
**Status:** Design specification, internal and partner distribution
**Scope:** Pre-Clearance product line, institutional custodial egress tier
**Architecture Pillars Engaged:** RAN, CourtChain, PoCS, Sealed Escrow
**Companion Standards:** FRE 902(14), NIST CSF 2.0, FIPS 203/204, SOC 2 Type II

---

## 1. Purpose and Problem Statement

Institutional custodial wallets (Fireblocks, BitGo, Anchorage Digital, Coinbase Custody, Komainu, and similar) provide strong protection for assets at rest inside the custodian's quorum boundary. They do not provide cryptographic guarantees for the transit window between the custodian and an external liquidity venue (centralized exchange or decentralized exchange/AMM). That transit window is the dominant attack surface for institutional crypto operations and is structurally uninsured by the custodian's own SLA.

JIL Custodial Egress Pre-Clearance closes that window. It introduces a cryptographic, court-admissible compliance gate between the custodian's signing quorum and the destination venue, such that no egress transaction can be broadcast unless every attestation passes, the destination is provably the intended one, and the resulting evidence package is admissible under FRE 902(14) without further authentication.

This document specifies the design with sufficient detail that an implementer can build it, an auditor can attest to it, a custodian can integrate to it, and a court can rely on the artifacts it produces.

---

## 2. Threat Model

The system must defeat every adversary capable of operating against any link in the egress chain. The following catalog is exhaustive for the defined scope.

### 2.1 External adversaries

1. Network-layer attackers performing BGP hijack, DNS poisoning, or TLS interception against the custodian-to-venue path.
2. RPC layer attackers running malicious or compromised node infrastructure that returns false chain state, false gas estimates, or fabricated transaction receipts.
3. Mempool attackers performing front-running, sandwich attacks, and generalized MEV extraction.
4. Address poisoning attackers that seed similar-looking addresses into the custodian's address book or transaction history to cause operator selection error.
5. Smart contract attackers exploiting approval, allowance, permit, signature replay, or proxy upgrade vectors in transit contracts.
6. Counterparty attackers operating sanctioned, mixer-adjacent, or structurally illicit destinations.
7. Cross-chain bridge attackers exploiting wrap/unwrap mechanics, light-client falsification, or message-passing replay.

### 2.2 Insider adversaries

8. Compromised or malicious operators inside the custodian, attempting unilateral egress.
9. Compromised or malicious operators inside JIL, attempting to approve egress without legitimate attestation, or to block legitimate egress.
10. Compromised or malicious operators inside the destination venue, attempting to alter receiving addresses post-quotation.

### 2.3 Cryptographic adversaries

11. Adversaries with sufficient classical compute to attack ECDSA or Ed25519 in isolation.
12. Adversaries with future quantum capability against any single classical signature scheme.
13. Adversaries exploiting signature malleability, nonce reuse, or weak randomness in any signing party.

### 2.4 Procedural adversaries

14. Time-of-check to time-of-use (TOCTOU) attackers who pass attestation against one state and broadcast against another.
15. Replay attackers reusing valid signed payloads across chains, networks, or time windows.
16. Social engineering attackers manipulating approval flows through human operators.

The system defeats every one of these classes through the layered controls specified in Sections 4 through 9.

---

## 3. Design Principles

The architecture is governed by the following non-negotiable principles. Every implementation decision below traces back to one or more of them.

1. **No single point of compromise.** No single party (custodian, JIL, venue, validator, operator) can unilaterally cause or block a legitimate egress.
2. **Cryptographic binding, not procedural trust.** Every gate is enforced by a signature requirement, not by a process step that can be skipped.
3. **Pre-image integrity end to end.** The destination address, amount, asset, route, and counterparty that are attested at clearance time are the same ones that get broadcast. Any drift voids the signature.
4. **Hybrid post-quantum throughout.** All signatures are Ed25519 plus Dilithium-III (ML-DSA-65). All key encapsulation is Kyber. No classical-only signature is ever sufficient.
5. **Court admissibility by construction.** Every attestation, signature, denial, exception, and override is logged to CourtChain in a form that produces a self-authenticating CREB package under FRE 902(14).
6. **Custody minimization.** In the default tier, JIL never holds assets. JIL holds only signing authority over an egress-only condition. Any tier in which JIL holds assets is a separately scoped, separately licensed, separately priced product.
7. **Transparency to the regulator and the court.** The system produces evidence whether the egress completes, fails, is denied, or is overridden. There is no path that produces no evidence.

---

## 4. Two-Tier Product Architecture

The Pre-Clearance product line is delivered in two distinct tiers. The tiers are intentionally separated for regulatory, commercial, and risk reasons.

### 4.1 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.

### 4.2 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. Not the default. Used only where the client requires JIL to actively manage execution rather than gate it.

The remainder of this document specifies Tier 1 in full and notes Tier 2 deltas where they apply.

---

## 5. Cryptographic Architecture

### 5.1 Signing scheme

Egress transactions require a (t, n) threshold signature where:

- The custodian holds (t_c, n_c) shares internally according to its existing scheme.
- JIL holds an additional independent share class. JIL's share class is itself (t_j, n_j) distributed across JIL validators in distinct jurisdictions.
- The composite scheme requires both the custodian quorum and the JIL quorum to produce a valid signature. Neither side can sign alone.

For chains using ECDSA (Bitcoin, Ethereum, EVM L2s), the implementation uses CMP/CGGMP21 threshold ECDSA. For Ed25519 chains (Solana, Sui, Aptos, Cosmos SDK chains using Ed25519), the implementation uses FROST.

### 5.2 Hybrid post-quantum binding

Every signed transaction is accompanied by a parallel JIL attestation signed under a hybrid scheme: Ed25519 plus Dilithium-III (ML-DSA-65). The attestation is bound by hash to the transaction payload. A verifier checks both signatures. Compromise of either primitive alone does not yield a valid attestation. Key encapsulation for any out-of-band channels uses Kyber (ML-KEM).

### 5.3 Key custody for JIL's share class

JIL's signing share is held inside FIPS 140-3 Level 3 HSMs at JIL validator nodes. The share is itself secret-shared across at least t_j of n_j HSMs in distinct legal jurisdictions, per the existing 20 active plus 20 standby validator architecture across 13 or more jurisdictions. No single jurisdiction's compelled disclosure can reconstruct JIL's share.

### 5.4 Domain separation and replay defense

Every signature is bound to a domain separation tag that includes:

- Chain ID (EIP-155 or equivalent)
- JIL network identifier
- Custodian identifier
- Client account identifier
- Egress request UUID (single-use)
- Block height window of validity (open and close)
- Hash of the full PoCS attestation bundle

A signature valid in one domain is cryptographically invalid in any other. Cross-chain replay, cross-client replay, and cross-window replay are all structurally impossible.

---

## 6. Egress Flow (Tier 1)

The flow is presented step by step. Every step is enforced by signature requirements; no step is enforced by procedure alone.

### 6.1 Initiation

The custodian's authorized operator submits an egress request to the JIL Pre-Clearance API. The request contains:

- Source vault identifier (custodian-side)
- Asset, amount, network
- Proposed destination address
- Proposed route (direct, via DEX, via CEX deposit address, via bridge)
- Purpose code (sale, transfer, settlement, treasury rebalance)
- Client identifier and authorization metadata

The request is signed by the custodian's operator key and counter-signed by the custodian's policy engine. JIL accepts no request that is not double-signed at this layer.

### 6.2 Destination provenance verification

Before any compliance check runs, the destination address is verified for provenance. This step alone defeats address poisoning and several MITM classes.

The verification combines:

1. **First-seen attestation.** The destination must either (a) appear in the client's pre-registered allowlist with a signed attestation older than the cooling period, or (b) trigger the new-destination workflow which requires out-of-band confirmation (Section 6.6).
2. **Venue-side attestation.** For CEX deposit addresses, JIL queries the venue over a mutually authenticated TLS channel (mTLS with certificate pinning) to confirm the address is currently assigned to the named client. The venue's response is signed.
3. **On-chain history check.** The address is checked against the JIL Risk Attestation Network (RAN) for prior interaction with sanctioned, mixer, or structurally illicit counterparties.
4. **Lookalike scan.** The address is compared character-by-character against the client's recent transaction history and address book to detect homoglyph or near-match poisoning.

If any of these fail, the request is denied and a CourtChain entry is written. There is no override at this layer that does not itself produce a signed exception record.

### 6.3 PoCS attestation

The PoCS engine runs the full attestation suite (500+ checks across 16 categories). For egress, the relevant categories include:

- Sanctions screening (OFAC, UN, EU, UK, regional)
- Counterparty risk scoring
- Asset provenance (no tainted lineage)
- Route attestation (each hop is acceptable)
- Velocity and pattern analysis against client baseline
- Jurisdictional gating (source, destination, intermediate)
- Time-of-day and behavioral baseline conformity

The output is a signed PoCS attestation bundle with a cryptographic hash that is bound into the signature domain (Section 5.4).

### 6.4 Pre-image binding

The transaction is constructed deterministically from the attested parameters. The construction is reproducible: given the same inputs, any verifier produces the identical raw transaction bytes. The hash of the raw transaction is bound into the signature domain. Any drift between attested parameters and broadcast parameters invalidates the signature.

This is the structural defense against TOCTOU. The custodian cannot pass attestation against one transaction and broadcast a different one; the signature would not verify.

### 6.5 Threshold signing

JIL's validator quorum produces JIL's share of the signature only after:

- All Section 6.2 checks pass.
- The PoCS attestation is signed and the hash is bound.
- The custodian's request signatures verify.
- The block height window is open.
- No active hold, freeze, or regulatory order applies.

The custodian's quorum produces its share. The composite signature is assembled. The transaction is now broadcastable and cryptographically bound to every attestation that produced it.

### 6.6 Out-of-band confirmation for new destinations

For any destination not on the pre-registered allowlist, an out-of-band confirmation step is required before the threshold signing in 6.5 will proceed. The confirmation:

- Is delivered through a channel cryptographically distinct from the API channel (typically a hardware-bound mobile attestation or HSM-protected operator console).
- Displays the destination address in a human-verifiable form including ENS or equivalent reverse resolution where available, address checksum, last-seen-in-history flag, and risk score.
- Requires affirmative signed acknowledgment from a named client officer whose key is registered with JIL.
- The acknowledgment signature is itself bound into the signature domain.

This step makes operator-side address substitution structurally detectable. An attacker who compromises the API channel cannot also forge the out-of-band confirmation without independent compromise of the client officer's hardware.

### 6.7 Broadcast and propagation

The signed transaction is broadcast through JIL-operated, custodian-operated, and independent third-party RPC endpoints simultaneously. The broadcast is monitored across all paths. Discrepancies in propagation, mempool position, or inclusion are flagged and logged.

For high-value egress, broadcast is performed through MEV-protected channels (private mempool, proposer-builder separation with attestation, or commit-reveal where chain-supported) to defeat sandwich and front-running adversaries.

### 6.8 Inclusion attestation

Once the transaction is included in a finalized block (with chain-appropriate finality depth), JIL writes an inclusion attestation to CourtChain anchoring the transaction hash, block hash, block height, and the full chain of attestations that produced it.

### 6.9 CREB package generation

A CREB package is generated for every egress request, whether it completed, was denied, was held, or was overridden. The package includes:

- The original request and all signatures.
- The PoCS attestation bundle.
- The destination provenance evidence.
- The out-of-band confirmation (where applicable).
- The composite signature and broadcast records.
- The inclusion attestation.
- All exception, override, and denial records.
- The CourtChain anchor proofs.

The package is self-authenticating under FRE 902(14) and admissible without further foundation.

---

## 7. MITM Defense Matrix

The following table maps each attack class from the threat model to the specific control(s) that defeat it. No attack class is defeated by a single control; every defense is layered.

| Attack Class | Primary Control | Secondary Control | Forensic Control |
|---|---|---|---|
| BGP / DNS / TLS interception | mTLS with certificate pinning on all custodian-JIL-venue channels | 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 | 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 and approval pre-image binding | Per-call CREB record |
| Sanctioned counterparty | RAN screening in PoCS (6.3) | 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 across jurisdictions (5.3) | Hybrid PQC dual signature (5.2) | Validator quorum log |
| Compromised venue address | Venue-side attestation (6.2) | Allowlist cooling period | Venue signature in CREB |
| Classical or quantum crypto attack | Hybrid Ed25519 plus Dilithium-III (5.2) | Kyber KEM for any encrypted channel | Algorithm identifier in CREB |
| Signature malleability / nonce reuse | HSM-enforced deterministic nonces | FROST/CMP protocol guarantees | Nonce log on CourtChain |
| TOCTOU between attestation and broadcast | Pre-image binding (6.4) | Block height window in domain (5.4) | Window evidence in CREB |
| Cross-chain / cross-window replay | Domain separation (5.4) | 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 |

There is no entry in this matrix for which a single defense exists. The layering is the security property.

---

## 8. Failure Modes and Recovery

### 8.1 JIL is unavailable

If JIL's quorum cannot produce a signature (network partition, mass HSM failure, regulatory hold), egress is blocked. This is a feature, not a bug, and is the explicit purpose of the gate. The custodian's funds remain safe inside the custodian's quorum. No data loss, no asset loss.

For business continuity, the standby validator set (20 standby across the 13-plus jurisdiction footprint) takes over within the SLA window. If the standby set also fails, a documented break-glass procedure exists involving multi-party signed declaration of emergency, which is itself logged to CourtChain. The break-glass procedure is auditable and rate-limited.

### 8.2 Custodian is unavailable

If the custodian cannot produce its share, JIL's share alone is insufficient to broadcast. No egress occurs. JIL retains no obligation and no asset.

### 8.3 Attestation fails mid-flow

If an attestation fails after initiation but before signing, the request is denied, all collected evidence is bundled into a denial CREB package, and the CourtChain is anchored. The client receives a signed denial reason. No partial state is left in the system.

### 8.4 Inclusion fails after broadcast

If a transaction is broadcast but does not finalize within the expected window (chain congestion, reorg, fee starvation), the request enters a pending state. JIL monitors continuously. If the transaction is dropped from mempools, a re-broadcast may be triggered under the same signature (signatures bind only the payload, not the broadcast). If the underlying chain reorganizes past the inclusion attestation, the attestation is voided and a new one is issued post-finality. All such events are CourtChain-logged.

### 8.5 Post-broadcast detection of compromise

If a downstream signal (RAN update, sanctions list update, intelligence feed) indicates the destination became toxic after the egress, JIL issues a post-event alert and CourtChain anchor. The transaction itself cannot be reversed (this is the chain's property, not JIL's), but the CREB package supports immediate counterparty action, regulator notification, and recovery proceedings under standard legal process. This is the boundary of detection-and-proof versus active recovery.

### 8.6 Compromise of JIL signing infrastructure

Detected compromise of any JIL HSM or validator results in immediate quorum reconfiguration. The compromised share is rotated. No legitimate signature ever depends on a single share or single jurisdiction. Compromise of fewer than t_j shares produces no signing capability.

---

## 9. Integration Specifications

### 9.1 Fireblocks integration

Fireblocks operates an MPC-CMP signing scheme with policy engine and Transaction Authorization Policy (TAP). JIL integrates as a TAP co-signer requirement for transactions destined outside the Fireblocks Network. The integration is API-level (Fireblocks Webhook or Co-Signer SDK depending on deployment) plus a policy update on the Fireblocks side adding JIL's signature as a required approval for egress transactions matching the configured criteria.

### 9.2 BitGo integration

BitGo operates a 2-of-3 multi-signature model with a user key, BitGo key, and backup key. JIL integrates as either an additional required signer (via policy module) or as the holder of a fourth key in a 3-of-4 elevated configuration for egress, depending on the client's preference and BitGo's product tier. The CREB package and PoCS attestation flow are identical to the Fireblocks integration.

### 9.3 Anchorage Digital integration

Anchorage operates as a federally chartered digital asset bank. Integration is at the policy and approval layer using Anchorage's Workflow API, with JIL's attestation and signature requirement encoded as a required approval step. Because Anchorage is a qualified custodian under federal banking law, the JIL Tier 1 posture (no custody, attestation only) is the cleanest fit and the only tier offered to Anchorage clients without further legal review.

### 9.4 Generic custodian integration

For any custodian operating an MPC, multi-sig, or policy-gated signing scheme, the integration pattern is the same:

1. JIL provides a co-signer service with hybrid PQC attestation.
2. The custodian's policy engine adds JIL's signature as required for the egress conditions defined by the client.
3. The custodian's existing operator workflow gains an attestation-status indicator.
4. The CREB package is delivered through the custodian's reporting channel and through a JIL-hosted client portal.

### 9.5 Liquidity venue integration

For CEX destinations, JIL maintains attested integrations with major institutional venues for deposit address confirmation (Section 6.2). For DEX destinations, JIL maintains attested integrations with the major aggregators and DEX protocols for route, slippage, and contract verification. The list of attested venues is itself a versioned CourtChain artifact and is auditable.

---

## 10. SLAs and Operational Parameters

| Parameter | Target | Notes |
|---|---|---|
| Pre-Clearance attestation latency (p50) | Under 8 seconds | From request submission to attestation |
| Pre-Clearance attestation latency (p99) | Under 30 seconds | Includes RAN deep-check |
| Threshold signing latency (p50) | Under 4 seconds | Excludes attestation |
| End-to-end clearance to broadcast (p99) | Under 60 seconds | Full flow excluding chain inclusion |
| Out-of-band confirmation timeout | 15 minutes | Configurable per client |
| New-destination cooling period | 24 hours default | Configurable per client, regulator may pin |
| Validator quorum availability | 99.99 percent | Across 20 active plus 20 standby across 13-plus jurisdictions |
| CourtChain anchor finality | Per chain finality | Typically under 15 minutes for anchor chain |
| CREB package availability | Within 5 minutes of inclusion | Self-authenticating under FRE 902(14) |

---

## 11. Regulatory and Licensing Posture

### 11.1 Tier 1 (Pre-Clearance Co-Signing)

Tier 1 is structured to operate without money transmitter licensing in the United States and equivalent foreign regimes. The legal theory:

- JIL never takes possession or control of the asset.
- JIL holds a signing share that is structurally limited to compliance gating.
- The custodian retains full custody throughout.
- JIL's product is an attestation and signature service, comparable in function to a transaction monitoring vendor with cryptographic enforcement.

The exact legal characterization is jurisdiction-specific. JIL maintains a state-by-state legal opinion file and updates it on regulatory change. For OFAC, FinCEN BSA, and equivalent sanctions and AML obligations, JIL operates as a service provider to the custodian, who remains the regulated entity for those obligations. JIL's attestations are designed to support the custodian's compliance, not replace it.

### 11.2 Tier 2 (Managed Egress)

Tier 2 requires money transmitter licensing or trust charter in jurisdictions of operation. JIL's roadmap includes a separate licensing track for Tier 2 markets and a parallel partnership track using already-licensed entities for jurisdictions where direct licensing is not yet in place.

### 11.3 Court admissibility

Every artifact produced by the system is designed to satisfy FRE 902(14) for self-authenticating electronic records. The CourtChain anchor provides the integrity proof. The validator signatures provide the authenticity proof. The CREB package format is the production-ready exhibit. JIL maintains a reference court submission template for counsel.

---

## 12. Implementation Phases

### Phase 0: Reference implementation and security review

Reference implementation of the threshold signing, hybrid PQC attestation, PoCS gate, and CourtChain anchor flow against a single test custodian (test environment only). Independent cryptographic review by a qualified third party. Penetration test against the full flow.

### Phase 1: First production custodian

Production deployment with a single launch custodian partner (Fireblocks, BitGo, or Anchorage based on commercial readiness). Limited client pilot. SOC 2 Type II audit covering the Pre-Clearance scope.

### Phase 2: Custodian fan-out

Onboarding of remaining major custodians. Liquidity venue attestation network expansion. ISO 27001 certification.

### Phase 3: Tier 2 (Managed Egress) launch

State money transmitter licensing complete in launch states. Tier 2 product launched as separately scoped offering. HITRUST CSF certification where healthcare-adjacent flows are involved.

### Phase 4: Federal and cross-border

Federal program integration where applicable. Cross-border attestation network expansion. FedRAMP path through partnership with already-authorized firms per existing JIL federal go-to-market strategy.

---

## 13. Open Questions and Forward Work

The following items are intentionally left open in this revision and should be closed before Phase 1 commitment to any specific custodian:

1. Per-custodian commercial terms for the policy module integration (revenue share, integration fees, support model).
2. Final cooling-period defaults across asset classes and client tiers.
3. Specific MEV-protection channel selections per chain.
4. CREB package format finalization with at least one institutional law firm review.
5. Per-jurisdiction legal opinion confirmations for Tier 1 posture.
6. SLA financial backing structure (contractual penalties, insurance, or letter of credit).
7. Final list of attested liquidity venues for launch and the attestation refresh cadence.

---

## 14. Glossary

**CourtChain.** JIL's tamper-evident, court-admissible logging chain. All system events of legal or evidentiary significance are anchored here.

**CREB.** Court Ready Evidence Bundle. JIL's evidence packaging standard, designed for self-authentication under FRE 902(14). Always written in all caps.

**Hybrid PQC.** The combination of a classical signature (Ed25519) and a post-quantum signature (Dilithium-III / ML-DSA-65) bound to the same payload, such that compromise of either primitive alone is insufficient.

**MITM.** Man-in-the-middle. Any adversary positioned to alter, intercept, or substitute messages or transactions between legitimate parties.

**MPC.** Multi-party computation. Cryptographic technique allowing multiple parties to jointly compute a function (here, a signature) without any party reconstructing the full secret.

**PoCS.** Proof of Compliance State. JIL's attestation engine producing a signed bundle of compliance check outcomes.

**RAN.** Risk Attestation Network. JIL's network of risk and counterparty intelligence sources, queried during PoCS.

**Sealed Escrow.** JIL's trust-and-escrow primitive, used in Tier 2 for constructive custody.

**TOCTOU.** Time-of-check to time-of-use. A class of attack where state changes between validation and action.

---

*End of design document.*