← Back to Patent Claims
Patent Claim 155 All Patents →

Secure Document Vault with Client-Side Encryption and Revocable On-Chain Access Grants

Documents encrypted entirely on-device before transmission, persisted on decentralized storage, anchored with an on-chain provenance record, and shared through revocable per-recipient key-exchange grants

Patent Claim JIL Sovereign July 2026 Claim 155 of 157

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.

Core Innovation: Client-side encryption ensures the platform never possesses the plaintext or the encryption key of a stored document unless a user explicitly grants access; on-chain provenance and decentralized storage decouple durability and ownership proof from any single operator; and per-recipient X25519-wrapped share grants allow revoking one recipient's access without re-encrypting the document or disturbing any other recipient's grant.

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.

0
Plaintext bytes ever transmitted off the user's device
2
Independent decentralized storage networks backing every document
1
Revocable grant per recipient, independent of all other grants

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

LayerComponentPurpose
EncryptionAES-256-GCM, client-side, per-document symmetric keyEnsures unencrypted content never reaches a server the platform operates
StorageIPFS (content-addressed pinning) + Arweave (permanent archival layer)Decouples document durability and availability from any single operator's continued existence
ProvenanceERC-721 token, tokenURI referencing the content-derived pointer, owner = uploading wallet addressOn-chain, timestamped record that a given address controlled this exact document as of a given block
Access controlX25519 ECDH handle-based grants, per-recipient wrapped key, revocable grant registryLets 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

ApproachOperator Holds Plaintext?Durability Independent of Operator?Cryptographic Per-Recipient Revocation?
DocuSign / NotarizeYesNoNo
Google Drive / Dropbox sharingYesNoNo - ACL-based only, cached copies remain readable
NFT-only ownership-proof projectsVaries - often no encrypted content bindingDepends on storage backendNot typically offered
Self-hosted encrypted drivesNoNo - single self-hosted point of failureManual, not structured
JIL secure document vaultNoYes - decentralized storageYes - per-recipient X25519-wrapped grants

Patent Claim

Independent Claim 155: A computer-implemented system for self-custodial secure document storage comprising: a client-side encryption module that encrypts a document using a per-document symmetric key via AES-256-GCM entirely on a user's device prior to any transmission, such that unencrypted document content never reaches a server operated by the platform; a decentralized storage interface that persists the resulting ciphertext to a content-addressed storage network and a permanent archival storage network; a provenance module that mints a non-fungible token bound to a content-derived pointer of the encrypted document and associates said token with the uploading user's wallet address as an on-chain, timestamped ownership record; and an access-grant module that, to share a specific document with a designated recipient, wraps a copy of the document's symmetric key to the recipient's public key via an X25519 elliptic-curve Diffie-Hellman key exchange and records the resulting grant as a discrete, independently revocable object, such that the document owner may revoke a given recipient's access without re-encrypting the document or affecting any other recipient's grant.