Executive Summary
JIL Wallet's document vault lets a user store sensitive documents - KYC paperwork, legal agreements, proof-of-funds statements, estate documents - in a way that is durable, portable, and provably theirs, without ever handing custody of the plaintext to JIL or any other platform operator. Encryption happens entirely on the user's own device: each document is encrypted with a per-document symmetric key using AES-256-GCM before any bytes leave the client, so the resulting ciphertext is the only thing that ever reaches a server.
The ciphertext is persisted to a content-addressed storage network and a permanent archival storage network rather than a conventional, centrally-operated bucket, so the document's durability does not depend on any single company remaining in business. A non-fungible token bound to the document's content pointer is minted and associated with the uploading wallet address as an on-chain, timestamped provenance record. When a user wants to share a specific document with a third party, an access-grant module wraps a copy of that document's symmetric key to the recipient's public key via X25519 elliptic-curve Diffie-Hellman key exchange, recorded as a discrete, independently revocable object.
Problem Statement
Users need to store sensitive documents in a way that is both durable and portable - not dependent on any single company staying in business, changing its terms of service, or being compelled to hand over data - and provably theirs, without surrendering custody of the plaintext to any platform operator, including the very platform providing the storage service. Conventional options force an unsatisfying tradeoff.
Centralized document platforms (DocuSign-style e-signature vaults, cloud drives with sharing features) hold the plaintext directly, meaning the operator can read the contents, is a single point of compelled disclosure, and revocation of a shared link does not reliably prevent a recipient who already downloaded or cached a copy from continuing to read it. Pure self-hosted encrypted drives protect privacy but offer no on-chain provenance proof and no built-in mechanism for granting - and cleanly revoking - access to a specific third party without manual key redistribution. NFT-based "proof of ownership" projects typically prove ownership of a pointer or metadata record, without cryptographically binding that record to client-side-encrypted content or providing a structured, revocable sharing mechanism at all.
Why Existing Approaches Fall Short
- Centralized e-signature/document vaults (DocuSign, Notarize): the operator holds the plaintext directly and is a single point of compelled disclosure or breach exposure.
- General-purpose cloud drives (Google Drive, Dropbox sharing links): access control is ACL-based, not cryptographic - a cached or downloaded copy remains fully readable after "revocation."
- NFT-only ownership-proof projects: typically prove ownership of a metadata pointer without binding client-side-encrypted content to that proof, and rarely offer structured, revocable third-party sharing.
- Self-hosted encrypted drives: durable and private, but with no on-chain provenance record and no built-in revocable per-recipient sharing mechanism.
Technical Architecture
| Layer | Component | Purpose |
|---|---|---|
| Encryption | AES-256-GCM, client-side, per-document symmetric key | Ensures unencrypted content never reaches a server the platform operates |
| Storage | IPFS (content-addressed pinning) + Arweave (permanent archival layer) | Decouples document durability and availability from any single operator's continued existence |
| Provenance | ERC-721 token, tokenURI referencing the content-derived pointer, owner = uploading wallet address | On-chain, timestamped record that a given address controlled this exact document as of a given block |
| Access control | X25519 ECDH handle-based grants, per-recipient wrapped key, revocable grant registry | Lets the owner share a specific document with a specific recipient, and revoke that recipient independently of others |
Client-Side Encryption Before Transmission
Encryption is performed on the user's own device using AES-256-GCM with a freshly generated symmetric key per document, before the document is transmitted anywhere. The platform's servers receive and persist only the resulting ciphertext - they never possess the plaintext, and never possess the document's symmetric key unless the user explicitly executes a share grant that wraps a copy of that key for a specific recipient.
Decentralized, Operator-Independent Storage
Rather than a centrally-operated storage bucket the platform could unilaterally delete or be compelled to disclose in plaintext, the encrypted document is persisted to IPFS for content-addressed retrieval and Arweave for permanent archival storage - two independent decentralized networks whose continued availability does not depend on JIL Sovereign specifically remaining operational.
On-Chain Provenance
An ERC-721 token is minted for each vaulted document, binding a content-derived pointer to the uploading wallet address as an on-chain, timestamped ownership record. This proves that a specific document, in its exact encrypted form, existed and was controlled by a specific address as of a specific block - without revealing the document's contents on-chain.
Revocable Sharing Mechanics
To share a document with a third party - an auditor, a counterparty, a family member for estate purposes - the owner's client wraps a copy of that document's symmetric key to the recipient's public key using X25519 elliptic-curve Diffie-Hellman key exchange. The resulting wrapped-key grant is recorded as a discrete object in a grant registry, independent of every other recipient's grant for the same document.
Because each grant is independently addressable, the owner can revoke one specific recipient's access - removing that recipient's wrapped-key grant from the registry - without needing to re-encrypt the document itself or redistribute new keys to any other current holder of a grant. This differs materially from access-control-list-based revocation on conventional sharing platforms, where the underlying content was never cryptographically gated per recipient in the first place, and where a recipient who already cached a copy typically retains readable access regardless of any subsequent "revocation" at the platform layer.
Prior Art Differentiation
| Approach | Operator Holds Plaintext? | Durability Independent of Operator? | Cryptographic Per-Recipient Revocation? |
|---|---|---|---|
| DocuSign / Notarize | Yes | No | No |
| Google Drive / Dropbox sharing | Yes | No | No - ACL-based only, cached copies remain readable |
| NFT-only ownership-proof projects | Varies - often no encrypted content binding | Depends on storage backend | Not typically offered |
| Self-hosted encrypted drives | No | No - single self-hosted point of failure | Manual, not structured |
| JIL secure document vault | No | Yes - decentralized storage | Yes - per-recipient X25519-wrapped grants |