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 pilot-ready encrypted ownership.
XRPL Grants would help Vaulted move from a working testnet MVP into a controlled pilot and mainnet-prepared architecture — expanding product access, secure sharing, infrastructure planning and advanced ownership research without overstating production readiness.
4-phase roadmap
Each phase expands usability, security and ownership depth.
The next stage is not starting from zero. It builds on an already verified local-first flow and prepares Vaulted for broader testing, stronger access workflows and a clearer path toward production-grade encrypted ownership.
Already verified in MVP
- local wallet restore
- local XRPL signing
- encrypted upload
- XRPL NFT minting
- owner download and decrypt
- recipient registration
- NFT transfer flow
- burn/delete lifecycle
Roadmap item
Initiative
Q2/26
Q3/26
Q4/26
Q1/27
Q2/27
Phase 1
Product Access
iOS / AndroidQ2 2026 → Q4 2026 · 3 quarters
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 mobileQ2 2026 → Q3 2026 · 2 quarters
Secure desktop loginDesktop login through QR scanning in the mobile app, allowing mobile approval of a limited desktop session without exposing the recovery phrase on the computer.
Website & docsQ2 2026 → Q3 2026 · 2 quarters
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 NotesQ3 2026 → Q4 2026 · 2 quarters
Encrypted note workflowEncrypted personal notes using the same client-side encryption and KeyEnvelope access model as Vaulted files.
Claimable TransfersQ3 2026 → Q4 2026 · 2 quarters
Pre-registered recipient supportImplementation of claimable transfers for recipients whose Vaulted identity or public address is known, but whose XRPL account may not yet be activated on-ledger. Vaulted can prepare a pending claim and complete NFT settlement after the recipient is ready.
Encrypted SharingQ3 2026 → Q1 2027 · 3 quarters
Access collaborationEncrypted sharing workflows for collaborative access, allowing owners to grant, revoke and manage recipient-bound access without exposing the underlying content.
Phase 3
Infrastructure
Multi-Oracle NetworkQ4 2026 → Q2 2027 · 3 quarters
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.
Distributed Storage NodesQ4 2026 → Q2 2027 · 3 quarters
Distributed encrypted storageEncrypted fragments are replicated across multiple storage nodes and jurisdictions, improving availability while keeping storage operators unable to read plaintext.
Replication and FailoverQ4 2026 → Q1 2027 · 2 quarters
Service continuityReplication and failover mechanisms that preserve availability and continuity of service if individual infrastructure components fail.
Payment InfrastructureQ1 2027 → Q2 2027 · 2 quarters
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
Research / specification track
File InheritanceQ1 2027 → Q2 2027 · 2 quarters
Inheritance transfer logicSpecification and prototyping for ownership and decrypt-access transfer to an heir when predefined inheritance conditions are met.
Conditional AccessQ1 2027 → Q2 2027 · 2 quarters
Policy-driven access rulesResearch and specification for access rules such as time lock, payment unlock, multisig approval, subscription period or organization policy.
Smart-contract / Hook R&DQ1 2027 → Q2 2027 · 2 quarters
XRPL automation researchResearch into XRPL primitives, Hooks, multisig and ledger-based conditions for future automation of ownership and access flows.
Enterprise PoliciesQ1 2027 → Q2 2027 · 2 quarters
Organizational control layerResearch and specification for corporate access policies, approvals, organization vaults and restrictions on data transfer for enterprise use cases.
Cross-phase track
Experience Design
UX/UI DesignQ2 2026 → Q2 2027 · 5 quarters
Product experience improvementImprovement of the application design and creation of a more convenient, intuitive and consistent user interaction experience across the Vaulted service.
Future exploration
Idea Implementation
Q2/27
Q3/28
DEX / NFT File MarketQ2 2027 → Q3 2028 · future exploration
DEX / NFT file marketplaceA future DEX-style marketplace built on top of the current project, where files can be traded through NFT-based sales. This can include intellectual property, documents, models and other digital assets that people want to buy or sell, with transactions executed through a guarantor or escrow flow.Future exploration, outside the current core grant scope.
Grant scope summary
The core grant scope focuses on product access, claimable transfers, secure notes, encrypted sharing, infrastructure planning, mainnet readiness, and advanced ownership research. Future marketplace or DEX work is outside the current grant scope.
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.