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 holdings are kept in segregated accounts at all times. There is no shared pool, no omnibus structure, and no blending of client funds with platform reserves. Every holding 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
Signing authority is split across MPC shards rather than a single key file, and a signature is only produced for a request that has cleared your policy rules.
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 can talk its way past your policy
Policy evaluation is programmatic. There is no help desk that can reset your credentials, waive an approval, or push a movement through outside your rules. This is not a limitation - it is the core security property of the system.
No policy override path
There is no admin panel, override function, or emergency mechanism that lets a support agent bypass your policy rules or your approval chain.
Key recovery is a ceremony, not a ticket
If you lose access to a key share, recovery runs through the documented threshold recovery ceremony with the escrow agent - not through a support ticket.
Privileged actions are attributable
JIL support helps with platform configuration, policy setup, and operational questions. Every privileged action is scoped, logged, hash-chained and attributable to a named operator.
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 mean no single actor can push a movement through on their own.
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, documented key-recovery ceremony
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. Policy scopes are contained independently, so an incident in one area does not become a global lockout.
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
Recovery runs through a documented threshold ceremony with the escrow agent, so it does not depend on any single component of the platform staying online.