Three Custody Modes. One Policy And Audit Layer.
Choose the operating model that matches your organization's security posture and operational requirements. Switch modes as your needs evolve - your policies and your audit history carry over seamlessly.
Choose the model that fits your operational requirements
Each mode provides the same policy evaluation, audit trails, and compliance tooling. The difference is where key shares are held and who participates in signing.
Client-Managed Keys
Your organization supplies and operates the signing devices. JIL supplies the policy, approval and audit layer around them. Compatible with hardware wallets and air-gapped signing setups. Scoped per deployment - confirm the signing model for your tenant during onboarding.
Threshold Cosigning (MPC)
Signing authority is split across MPC shards rather than a single key file. Every signature is produced under your policy rules and recorded with an attestation receipt. On the default service key the shards are cosigned server-side - see the implementation note below.
Delegated
JIL manages the signing process on your behalf, subject to your policy rules and approval workflows. Lowest operational overhead while maintaining full asset segregation and audit trails.
Four-step key ceremony process
Every MPC deployment begins with a structured key ceremony. This process generates, distributes, verifies, and activates key shares in a way that produces cryptographic proof of correct setup.
Generate
Cryptographic key material is generated in a secure, isolated environment using a hardware random number generator. The generation process produces verifiable entropy proofs.
Distribute
Key shares are encrypted and distributed to the designated share holders for your deployment. Each share is transmitted through a separate secure channel.
Verify
Each share holder independently verifies their key share using zero-knowledge proofs. Verification confirms that shares are valid and that the threshold scheme is correctly configured without revealing any key material.
Activate
Once all parties confirm successful verification, the key is activated for signing operations. A ceremony receipt containing all proofs and attestations is generated for your records.
How key shards work together
Signing authority is split across shards rather than sitting in a single key file, and a signature is only produced once your policy rules and approval workflow have cleared the request.
Operational shard
Used for day-to-day signing under your policy rules.
Platform shard
Held by JIL. Stored in a FIPS 140-2 Level 3 certified HSM.
Recovery shard
Held in escrow. Accessible only during a recovery ceremony.
Any combination of two share holders can produce a valid signature, so the loss of a single shard does not lock you out and does not, on its own, authorise a movement.
Transaction initiated
A user submits a transaction request. The request passes through policy checks and approval workflows before reaching the signing layer.
Threshold reached
The required number of shards is gathered by the cosigning service. A request that has not cleared policy never reaches this stage.
Signature assembled
The signature is produced and the movement is broadcast, together with an attestation receipt covering the policy decision and the approvers.
Implementation note
On the default service key the shards are gathered and cosigned server-side, so the platform is able to produce a signature for a request that has cleared your policy rules. A non-interactive threshold protocol, in which no party ever assembles the shards, is an audit-gated roadmap item and is not what runs today. Deployments that require customer-operated signing devices should use the Client-Managed Keys model and confirm the signing arrangement during onboarding.
JIL is a software platform, not a custodian
JIL supplies the infrastructure - policy evaluation and attestation, audit trails, compliance tooling, and operational dashboards. Your holdings are segregated per entity and sit outside the platform balance sheet. This structural distinction has significant legal and regulatory implications.
Traditional custodian model
Your assets sit on the custodian's balance sheet. You depend on the custodian's solvency, security practices, and regulatory compliance. Counterparty risk is structural.
JIL platform model
Your holdings are segregated per entity and stay off the platform balance sheet, and every movement is gated by your own policy rules and recorded with an attestation receipt.