Trust Is Engineered Into the System
JIL does not ask institutions to trust a brand, a team, or a promise. Trust is the result of architectural decisions that make harmful outcomes structurally impossible.
Three guarantees that protect every institution
These are not terms-of-service commitments. They are architectural constraints that cannot be bypassed by any user, administrator, or JIL employee.
No commingling of assets
Your digital assets are held in segregated accounts at all times. There is no shared pool, no omnibus structure, and no blending of client funds with platform reserves. Every asset is attributable to a single entity.
No rehypothecation
Assets under your control are never lent, staked, leveraged, or used as collateral - not by the platform, not by third parties. What you deposit is what you control, at all times, without exception.
No balance-sheet exposure
Your holdings exist outside the JIL platform balance sheet. In the event of platform insolvency, your assets remain yours. This is structural isolation, not a contractual promise.
How control is retained at every layer
Six mechanisms work together to ensure your organization maintains full control over assets, access, and operations.
MPC key management
Private keys are split across distributed key shares. No single party - including JIL - can act unilaterally on your assets.
Policy-controlled access
Every transaction must satisfy active policy rules. Policies are defined by your organization and enforced programmatically.
Immutable audit trail
Every action is recorded to a tamper-evident ledger. Records cannot be altered, deleted, or backdated.
Real-time visibility
Full transparency into every asset, movement, approval, and policy exception across all accounts and teams.
Cryptographic receipts
Every transaction generates a verifiable receipt bundle containing proofs, timestamps, and signer attestations.
Compliance-first architecture
KYC/KYB, AML screening, and jurisdiction rules are enforced at the platform layer - not bolted on after the fact.
Trust questions answered
No support desk has access to your keys
Self-custody means there is no help desk that can reset your credentials, override your policies, or move your assets. This is not a limitation - it is the core security property of the system.
No backdoor access
JIL employees cannot access, move, or freeze your assets. There is no admin panel, no override function, and no emergency access mechanism that bypasses your key shares.
Key recovery is cryptographic, not procedural
If you lose access to a key share, recovery is handled through the MPC threshold scheme and the independent escrow agent - not through a support ticket.
Support operates at the software layer only
JIL support can help with platform configuration, policy setup, and operational questions. They cannot and will never interact with your key material or signing operations.
What this means in practice
Time-lock security for sensitive operations
High-impact actions trigger mandatory delays before execution. This cooling-off period gives your security team time to detect, review, and halt unauthorized changes before they take effect.
Policy modifications
Changes to approval thresholds, signing requirements, or access policies are queued with a mandatory delay. All stakeholders are notified immediately.
Role and permission changes
Adding signers, removing team members, or changing role permissions triggers a cooling-off period. Existing signers must acknowledge the change.
Large withdrawals
Transactions exceeding organization-defined thresholds enter a time-lock queue. Multiple approvers must confirm during the delay window.
Escrow agent changes
Modifying the independent escrow configuration requires extended cooling-off with notification to all key share holders.
Recovery key rotation
Rotating recovery keys or backup shares triggers a multi-day delay with mandatory verification from existing share holders.
Bridge configuration
Changes to bridge limits, allowed corridors, or counterparty rules are time-locked with full audit trail notification.
Every request is verified. No exceptions.
The JIL governance model does not trust any individual actor - including administrators, founders, or JIL employees. Every action is subject to the same policy checks and approval requirements.
How zero-trust governance works
No admin override
There is no super-user account that can bypass policy checks. Administrators define policies but are subject to them like every other user.
Programmatic enforcement
Policies are enforced by the platform engine, not by human review. A transaction that fails policy checks is rejected automatically - there is no manual approval path.
Separation of duties
The person who creates a policy cannot be the sole approver of transactions under that policy. Role separation is structural, not procedural.
Immutable policy audit trail
Every policy change, approval, and rejection is recorded to the immutable ledger. Policy modifications cannot be made retroactively.
Policy enforcement examples
Key principle
"The system should be secure even if every human in the organization is compromised."
Zero-trust governance is designed to protect assets even in the worst case - an insider attack, a compromised administrator, or coordinated social engineering. Time-locks and threshold requirements make unilateral action structurally impossible.
Built to SOC 2 Type II standards
JIL architecture supports attestation requirements across all five SOC 2 trust service criteria. Controls are built into the platform - not bolted on for audit season.
Security
ReadyMPC key management, zero-trust governance, encryption at rest and in transit
Availability
ReadyRedundant infrastructure, automated failover, self-custody key recovery
Processing integrity
ReadyImmutable ledger, cryptographic receipts, hash-chained audit entries
Confidentiality
ReadyAES-256 encryption, role-based access, time-gated document sharing
Privacy
ReadyData segregation, jurisdiction-aware storage, GDPR-aligned controls
SEC Regulation D 506(c) Filed
ActiveJIL token offerings are filed under SEC Regulation D, Rule 506(c), allowing general solicitation to verified accredited investors. All purchasers undergo accredited investor verification prior to token allocation. Filing documentation available upon request.
Compliance Framework
Prepared for every scenario
JIL maintains a structured incident response capability covering detection, containment, investigation, and recovery. The self-custody model means your assets are protected even during platform-level incidents.
Detection
SentinelAI monitors 8 risk vectors in real time. Anomalous activity triggers immediate alerts to designated security contacts.
Containment
Automated containment protocols can freeze affected policy scopes while preserving access for unaffected operations. No global lockout.
Investigation
Immutable audit trails provide complete forensic records. Every action, approval, and policy change is timestamped and hash-chained.
Recovery
Self-custody architecture means asset recovery is independent of platform state. MPC key shares enable recovery even if the platform is offline.