X1 Vault is encrypted storage built on a single, unusually clean idea: your wallet is your encryption key. There is no account to create, no password to remember and no key escrow to trust. You sign a message, the signature becomes an AES key, and your files go to IPFS already encrypted — where the server holding them could not read them if it wanted to.
It is a small product with a sharp thesis, and the thesis matters more than the feature list. Most "decentralized storage" is decentralized about where bytes live and entirely centralized about who can read them. Vault inverts that.
How the wallet becomes a key
The derivation is three steps and worth understanding, because everything else follows from it:
- Your wallet signs the fixed message
IPFS_ENCRYPTION_KEY_V1. - The signature is hashed with SHA-256, producing 32 bytes.
- Those 32 bytes are the AES-256-GCM key.
The property that makes this work is that Ed25519 signing is deterministic: the same key over the same message produces the same signature every time, on every device, forever. So the same wallet always derives the same encryption key, and there is nothing to synchronise between your laptop and your phone. Connect the wallet, sign, and your files decrypt.
Encryption happens in the browser — or in your process — before anything is uploaded. What reaches the server is a JSON envelope: version, algorithm, your public key, the derivation message, and a base64 payload of a 12-byte IV, the ciphertext, and a 16-byte GCM authentication tag. The tag is not decoration. GCM is authenticated encryption, so a file that has been tampered with in transit or at rest fails to decrypt rather than decrypting into something subtly wrong.
What the server can and cannot see
This is the part worth being precise about, and to its credit the documentation is precise about it too.
The server cannot read your file contents, derive your key, or decrypt anything. Without a signature over that message — which requires your private key — the encrypted JSON is inert. Possession of the file is not access to the file.
The server can see your wallet's public key, each file's size, its upload timestamp, and — this one deserves emphasis — its filename. Filenames are stored unencrypted so the file browser can present directory structure. That is a real metadata leak. tax-return-2025.pdf tells an observer a great deal without a single byte of plaintext, and anyone building on Vault should treat filenames as public and name accordingly.
The server can also delete your files or refuse to serve them. The docs say so plainly and give the correct mitigation: "for maximum resilience, pin your CIDs to multiple IPFS nodes." That is the honest position. Encryption protects confidentiality; it does not protect availability, and no amount of AES makes a host obliged to answer.
Retrievability: content addressing does the work
Files are stored on IPFS and pinned, which means every file is addressed by a CID — a hash of its own contents — rather than by a location. Three consequences follow, and they are the reason IPFS is the right substrate here rather than a fashionable one.
The address is a checksum. If a CID resolves at all, the bytes are the bytes that were uploaded. Combined with the GCM tag, you get integrity twice over: the network proves you got the right ciphertext, the cipher proves nobody edited it.
Any gateway will do. A CID is not tied to Vault's host. Pin it to your own node, a commercial pinning service, or a friend's Raspberry Pi, and the same address keeps resolving. This is what makes the "we could delete your files" caveat survivable rather than fatal — but only if you actually do it. Redundancy is a decision, not a default.
Directories survive. Structure is preserved through filename paths — docs/README.md — so a tree goes up and comes back down as a tree, with the browser handling navigation and in-browser decryption before handing you plaintext.
Built for agents, not just for people
The most interesting design decision in Vault is one most storage products get backwards: it treats non-interactive use as the primary case, not an afterthought bolted on for CI.
Keys load directly from disk, in .env form (SOLANA_PRIVATE_KEY=...) or as a raw base58 string. No wallet popup, no browser, no human. An agent running headless on a server derives its key exactly as a browser would and produces byte-identical output — the docs are explicit that CLI, Python, Node.js and browser implementations are fully compatible with one another. A file written by a Python cron job decrypts in a browser tab, because both did the same three steps.
The SDK surface is deliberately thin. Node.js needs @solana/web3.js, tweetnacl, bs58 and form-data; Python needs pynacl, base58, cryptography and requests. There is no proprietary client to depend on and nothing that would be hard to reimplement if the project vanished tomorrow — which, for a storage layer you intend to trust with years of data, is a feature rather than a shortfall.
The API is a small REST surface over an IPFS node:
POST /api/v0/add?pin=true— upload, multipart, withX-PubkeyandX-Filenameheaders. Returns{"Name":"myfile.txt","Hash":"QmXxx...","Size":"1234"}.GET /index/files?pubkey=X— every file for a wallet.GET /index/file/{cid}— metadata for one.DELETE /index/file/{cid}— remove from the index, authenticated byX-Pubkey.POST /api/v0/ls?arg={cid}andPOST /api/v0/cat?arg={cid}— directory listing and raw content.
Multi-agent isolation falls out of the key model for free. Give each agent its own wallet and, in the documentation's words, "Agent A cannot decrypt Agent B's files." There is no permission system to configure and therefore no permission system to misconfigure — a compromised agent leaks its own memory and nothing else. For anyone running a fleet of autonomous processes on X1, that is a materially better security posture than a shared bucket with IAM policies in front of it.
Where it is already used on X1
Vault is infrastructure, so the question is what runs on it. Two X1 projects already do, both from the same team that built Vault.
Solaris Prime, the largest NFT marketplace on X1, uses Vault for storage. Metaplex keeps a pointer on-chain and the metadata and media somewhere else, and that somewhere else is the weak link in most NFT collections — a URL on a server whose renewal date nobody is tracking. A CID cannot rot into someone else’s content the way a URL can, and the encryption layer makes holder-only content gated by cryptography rather than by a front-end check.
Kryptark, X1’s post-quantum messaging layer, uses Vault for message files. Messaging systems handle text elegantly and then hit a wall at attachments: a 40 MB video does not belong in a relay, and ordinary cloud storage would undo the privacy the messaging layer just established. The file is encrypted before it leaves the device and the message carries only a CID — small, immutable, and meaningless to anyone who intercepts it.
What to watch
Three caveats deserve to be stated as plainly as the docs state them.
Lose the wallet, lose the files. There is no recovery, no reset and no support ticket that helps — that is the direct cost of having no escrow, and it is the correct trade for this design, but it is not a small one. Anyone storing anything they care about needs their seed phrase backed up properly before the first upload, not after.
The key never rotates. Deterministic derivation is what makes the system portable, and it also means one wallet has exactly one key, permanently. There is no re-key short of migrating everything to a new wallet, which is worth knowing before a wallet becomes the root of years of stored data.
Nothing is documented about price or limits. No pricing, no storage caps, no rate limits appear in the docs. For hobby use that is fine. For anyone planning to point a production agent fleet at it, those are the first questions to ask, and the answer determines whether you also want that second pin somewhere else.
The bottom line
X1 Vault does one thing and does it with unusual clarity: it removes the storage provider from your threat model without asking you to run anything. The wallet-as-key derivation is elegant, the agent story is the best-considered part of the product, and the documentation is refreshingly willing to name its own limitations — the unencrypted filenames, the delete-and-refuse power, the unrecoverable key.
It is not a finished platform. It is a well-made primitive, and primitives are what an ecosystem is short of early — with two live consumers already, in the marketplace and the messaging layer, which is more than most storage projects can say at this stage. Use it as they do, and pin your own CIDs alongside: the encryption is the part nobody can take from you, and availability is the part you still have to arrange.