Executive Summary
JIL's pre-clearance layer is architected as a provider-agnostic co-signing and attestation service that sits alongside - not inside - a client's chosen institutional custodian. The same compliance-gate contract, a signed pre-settlement attestation required before egress, is implemented as independent adapters against multiple, operationally unrelated custody providers - Fireblocks' Transaction Authorization Policy co-signer callback, BitGo's custom-policy module, and Anchorage Digital's Workflow API - so a client's compliance history, screening configuration, and attestation continuity are decoupled from any single custodian's continued operation.
That decoupling produces a failover property no single custodial platform can offer for itself: if a client's primary custodian becomes unavailable, insolvent, or exits a jurisdiction, the client can re-point the same compliance and attestation layer at a second, operationally independent custodian without losing the attestation and screening history accumulated with the first, because that history is held by JIL's attestation layer rather than by the custodian being replaced.
JIL never takes possession of the underlying asset under this architecture. It contributes an additional required signature share to the client's own custodian-side threshold or multi-signature scheme, gated on the client's compliance status - and it is precisely that non-custodial posture that makes provider substitution possible without a change-of-custody event.
Problem Statement
Institutional custodial wallets provide strong protection for assets at rest inside a single custodian's own signing quorum, but that protection is bound entirely to that one custodian's continued operational existence. If the custodian experiences an outage, insolvency, or a forced exit from a jurisdiction, the client's compliance and screening history built up with that custodian - audit trails, KYC/AML attestations, prior transaction risk scoring - does not travel with the client to a replacement custodian, because that history lives inside the custodian's own systems. A client forced to switch custodians effectively restarts its compliance posture from zero at the worst possible moment.
Technical Architecture
Composite Threshold Model
Egress transactions require a composite threshold signature: the custodian holds its own share set under its existing scheme, and JIL independently holds an additional share class, distributed across separate JIL-operated signing nodes in distinct legal jurisdictions (a target design topology; see the Prior Art Differentiation section for current-scale framing). A valid egress signature requires both the custodian's quorum and JIL's quorum - neither side can sign alone.
Custody-Provider Adapter Layer
| Provider | Integration Point | Provider's Native Scheme |
|---|---|---|
| Fireblocks | Transaction Authorization Policy (TAP) co-signer callback / webhook | MPC-CMP with an internal policy engine |
| BitGo | Custom-policy module, or an added fourth key in a 3-of-4 elevated egress configuration | multi-signature (user key, BitGo key, backup key) |
| Anchorage Digital | Workflow API required-approval step | Federally-chartered qualified-custodian approval workflow |
Each adapter's job is identical regardless of which custodian it targets: translate that custodian's native transaction-authorization callback into JIL's own attestation-request contract, obtain a pass/fail compliance determination, and return JIL's signature share for composition with the custodian's own share. The adapter interface - not any one custodian's specific integration - is what is fully specified; individual custodian integrations are brought online in phases as commercial and legal readiness allow.
Domain-Separated Replay Defense
Every JIL-side signature is bound to a domain tag including the chain ID, JIL's own network identifier, the custodian identifier, the client account identifier, and a single-use egress request ID. A signature valid for one custodian relationship therefore cannot be replayed against a different one - which is exactly the binding property that lets a client's JIL-side history and controls remain meaningful after a custodian swap: the JIL share of the signature was never bound to that specific custodian's key material in the first place, only to the client account and the specific request.
Failover Mechanism
- A client relationship is registered against JIL's attestation layer keyed by client account identifier, with the custodian identifier carried only as a domain-separation input, not as an identity anchor.
- On a custodian-unavailability event (outage, insolvency, jurisdictional exit), the client's compliance and screening configuration and its attestation history remain resolvable by that same client account identifier.
- A new adapter matching the replacement custodian is bound to the same client account.
- Egress resumes under the same compliance gate, with continuity of prior attestation records preserved for audit purposes.
Prior Art Differentiation
| Model | Compliance/Attestation Portability if the Custodian Exits | Custody During Transit |
|---|---|---|
| Single-custodian native compliance (a custodian's own policy engine used alone) | None - configuration and history live inside that one custodian's systems | Held entirely by that one custodian |
| Third-party transaction monitoring overlay (Chainalysis KYT, TRM Labs) | Partial - alerts and history are portable, but carry no signing authority, so they cannot themselves block an egress | N/A - monitoring only, no signing role |
| JIL Sovereign Pre-Clearance | Full - attestation history and the required co-signature role are held independently of any one custodian and re-bindable to a replacement | Never - JIL holds no asset at any point |