Identity
Seed-based recovery keeps access tied to the user, not to a platform account.
[v]aulted
Encrypted file ownership on XRPL.
Private files stay encrypted. Ownership stays user-controlled.
Vaulted protects files and secrets locally, stores encrypted data off-chain, and uses XRPL NFTs to prove ownership and transfer access without exposing content to servers.
Local encryption
User-owned keys
Off-chain encrypted storage
NFT-backed ownership
About Vaulted
A private vault where files become ownable assets.
Vaulted keeps files, documents and secrets encrypted by default. Access is controlled by the user’s seed and keys, while ownership can be proven and transferred through XRPL NFTs — without exposing plaintext to the service.
Encryption
Files are encrypted before storage, so server infrastructure never needs plaintext.
Ownership
XRPL NFTs can represent file ownership and enable access transfer without file copies.
Storage
Encrypted data stays off-chain, while ownership and transfer logic stay verifiable.
The problem
Cloud storage solved availability. It did not solve ownership.
Traditional storage still makes users depend on servers for access, recovery, sharing and permission management. Vaulted shifts control back to the user.
server-based access
account recovery controlled by the platform
file sharing through copies and permissions
metadata and rights managed centrally
Traditional cloud
Server controls access and recovery.
Accounts become the main security boundary.
Sharing usually means links, copies or platform permissions.
Vaulted
User controls keys, access and recovery.
Seed-based access makes ownership portable.
NFT transfer can move ownership without exposing the file.
How Vaulted works
Storage, access and ownership are separated by design.
Vaulted treats every private file as an encrypted asset. The payload, the decrypt path and the ownership record each live in their own layer, so no server needs plaintext or user keys.
01 / Data
Local encryption, off-chain payload.
Files and secrets are encrypted on the client first. Storage nodes only receive ciphertext, never the original content.
02 / Access
Decrypt rights without exposing keys.
Key envelopes and re-encryption define who can open the file while keeping sensitive material inside the trusted client boundary.
03 / Ownership
XRPL NFT as the ownership anchor.
The ledger records who owns the digital asset. When ownership moves, access state can move with it.
Architecture
Four layers, one trust boundary.
The client encrypts, decrypts and signs locally. Oracle coordinates access state and verification. Storage nodes keep encrypted payloads. XRPL anchors ownership, offers and transfer/payment state.
Clientencrypt / decrypt / sign locally
Oraclecoordination / verification / access state
Storage nodesciphertext only
XRPLNFT ownership / offers / payments
Trusted client boundary
Everything needed to see or sign sensitive data stays with the user.
seed phrase
private keys
content key
plaintext
local decrypt
local XRPL signing
Server / ledger layer
Infrastructure coordinates state and stores encrypted data, but cannot decrypt user content.
Oracle coordination
storage authorization
transfer state
encrypted payload
ledger verification
ownership record
Seed & wallet flow
One seed phrase can power multiple key domains.
A Vaulted wallet is created or restored from a 12-word seed phrase. From that local root, the app derives the identity, encryption and wallet material needed to recover access across devices.
12-word seed phrase
A local cryptographic root, not a server password.
The seed stays on the client and can deterministically restore access to files, identity and wallet functions on a new device.
01
Identity
Derives the Vaulted identity layer used to recognize the user across recovery and ownership flows.
02
Encryption
Produces encryption material that protects files and secrets locally before anything is stored.
03
XRPL wallet
Generates the ledger wallet used for NFT ownership, signing, offers and payment-linked actions.
04
Device & auth
Separates device and authentication keys so access can be managed safely across trusted endpoints.
05
Metadata protection
Extends protection to file-related metadata, reducing what infrastructure can learn about user content.
Why it matters: if the user moves to a new device, the same seed can restore access predictably across these domains — without turning the service into the owner of the keys or the data.
File lifecycle
From local encryption to local decryption.
Vaulted keeps plaintext on the device. Upload turns a file into ciphertext before it leaves the client, and download restores it only after access is checked and the file key is recovered locally.
Upload flow
Plaintext never leaves the device.
The client selects a file, derives a fresh content key, encrypts the payload locally, and only then sends ciphertext to storage. Ownership is anchored on XRPL while Oracle completes the vault state.
01
Select
The user chooses the file to protect inside the client.
02
content_key
The client generates a random file key for this specific payload.
03
Encrypt
The file is encrypted locally and wrapped into a KeyEnvelope for the owner.
04
Upload
Only ciphertext is sent to storage nodes; plaintext stays on the device.
05
Mint NFT
The client mints an XRPL NFT to anchor ownership of the digital asset.
06
Finalize
Oracle finalizes the vault object and links storage, access and ownership state.
Download / decrypt flow
Access is delivered, decryption stays local.
Oracle and storage participate in coordination and delivery, but they do not decrypt the file. The client restores the content key and opens the payload locally.
Request access
The client requests the vault object and current access state.
Access check
Oracle verifies that the user is allowed to open the asset.
Get ciphertext
Storage returns the encrypted payload, not plaintext.
Get KeyEnvelope
The client receives the encrypted file-key wrapper for the authorized user.
Local decrypt
The private key opens the KeyEnvelope, restores the content_key and decrypts the file locally.
Storage and Oracle help deliver state and ciphertext, but they never perform the decryption step themselves.
Transfer flow
Ownership moves on XRPL. Access has to move with it.
A transfer is only complete when the NFT changes hands and the decrypt path updates too. Vaulted keeps ownership and decryptability synchronized so the new holder can actually open the asset.
Ownership + access sync
Transfer is finalized only when Bob can decrypt.
Alice starts the transfer and signs the XRPL offer locally. Bob accepts it on-ledger. After ownership changes, Vaulted updates encrypted access material so the new owner gains decrypt rights instead of receiving only a ledger record.
Origin
Alice
The current owner initiates the transfer and signs the XRPL offer locally.
01Alice initiates the transfer.
02She signs NFTokenCreateOffer on the client.
XRPL offer
NFT Offer
The ownership offer is published on XRPL and becomes available for acceptance.
Vaulted update
Access Update
Encrypted access material is refreshed so decrypt rights follow the new owner.
Destination
Bob
Bob accepts the offer, receives NFT ownership and then gains the ability to decrypt.
03Bob accepts via NFTokenAcceptOffer.
04XRPL ownership moves to Bob.
05Vaulted updates encrypted access material.
06Bob can decrypt the file.
Why this matters: Vaulted treats transfer as both an ownership event and an access event. If the NFT moves but decrypt access does not, the transfer is not truly complete.
Security model
Vaulted should never become the custodian of user data.
The model is built so that servers can coordinate, store ciphertext and verify ownership, but they should not gain the keys, plaintext or authority required to open user files.
Core guarantees
Security depends on keeping decryption power on the client.
Even if Oracle or storage infrastructure were compromised, an attacker should be limited to metadata, transfer state or encrypted payloads — not the ability to decrypt the underlying files.
No seed on server
The seed phrase is never uploaded, making it a local recovery root rather than a server credential.
No private keys
Private keys remain under user control and are not delegated to backend infrastructure.
No plaintext
Plaintext content stays on the client and is encrypted before any network transfer happens.
Ciphertext only
Storage nodes keep encrypted payloads, reducing their role to persistence rather than custody.
Oracle cannot decrypt
Oracle can coordinate access state, but it does not hold the plaintext content key or perform decryption.
XRPL ownership only
The ledger records ownership and transfer state, not the file content or decryptable data itself.
Threat model: if Oracle or Storage are compromised, the attacker may observe encrypted payloads, access metadata or transfer state, but should still be unable to decrypt files because the decryption authority remains on the client.
Roadmap & grant impact
From verified MVP to production-ready encrypted ownership.
XRPL Grants would accelerate Vaulted beyond core demo flows into a broader product, stronger infrastructure and more advanced ownership logic — building on an MVP that already proves upload, decrypt and transfer behavior.
4-phase roadmap
Each phase expands usability, security and ownership depth.
The next stage is not starting from zero. It is taking an already verified flow and turning it into a resilient encrypted ownership platform with better access, richer sharing models and stronger infrastructure.
Roadmap item
Initiative
Q2/26
Q3/26
Q4/26
Q1/27
Q2/27
Phase 1
Product Access
iOS / Android
User mobile applicationsDevelopment of full user-facing mobile applications for iOS and Android, allowing users to manage encrypted files, ownership and access directly from their devices.
QR-login via mobile
Secure desktop loginImplementation of desktop login through QR scanning in the mobile app, reducing the risk of seed phrase leakage that can happen when entering recovery material manually on a computer.
Website & docs
Project website and documentationDevelopment of a complete public-facing project website together with structured product documentation, onboarding materials and developer-facing technical docs.
Phase 2
Secure Features
Secure Notes
Encrypted note workflowImplementation of secure notes as a mobile-first feature, enabling users to create, store and manage encrypted personal notes directly from their devices.
Claimable Transfers
Pre-registered recipient supportImplementation of claimable transfers for recipients who are not yet registered in the Oracle. This makes it possible to send an NFT and arrange access to encrypted files for a public address that has not yet been onboarded into the Vaulted system.
Encrypted Sharing
Access collaborationEncrypted sharing workflows for collaborative access, allowing file owners to grant and manage protected access rights without exposing the underlying content.
Phase 3
Infrastructure
Multi-Oracle Network
Synchronous Oracle networkCreation of a synchronized network of Oracles running across different servers and jurisdictions. This allows the service to continue operating even if one or more Oracle nodes become unavailable.
Storage-nodes Superposition
Distributed encrypted storageImplementation of a storage-node network across multiple servers and jurisdictions, where each user’s encrypted file is stored simultaneously across all participating storage servers.
Replication and Failover
Service continuityReplication and failover mechanisms that preserve availability and continuity of service if individual infrastructure components fail.
Payment Infrastructure
Service payment layerCreation of the payment infrastructure for Vaulted services, including subscriptions, service fees, storage usage accounting, payment processing and future XRPL-native payment integrations.
Phase 4
Advanced Ownership
File Inheritance
Inheritance transfer logicTransfer of ownership and decrypt access to an heir when predefined inheritance conditions are met.
Conditional Access
Policy-driven access rulesAccess rules such as time lock, payment unlock, multisig approval, subscription period or organization policy.
Smart-contract / Hook R&D
XRPL automation researchResearch into XRPL primitives, Hooks, multisig and ledger-based conditions for automating transfer flows and access rules.
Enterprise Policies
Organizational control layerCorporate access policies, approvals, organization vaults and restrictions on data transfer for enterprise use cases.
Cross-phase track
Experience Design
UX/UI Design
Product experience improvementImprovement of the application design and creation of a more convenient, intuitive and consistent user interaction experience across the Vaulted service.
Client application demo
Vaulted client app in action.
A short walkthrough of the client experience: encrypted file handling, wallet-based access, ownership flows and the core product interactions behind Vaulted.
Client-side workflow: the video demonstrates how users interact with the Vaulted application and how the product experience connects encryption, ownership and access management.