Seal a file todaythat only opens if both curves fall.
A coin can move to a fresh address when the maths gets shaky. A file can’t. ArShield wraps it in ML-KEM-768 + X25519 on your device, signs it, and hands you something you can store anywhere.
Built on proven standards
Coins can run.
Data can't.
Crypto is planning for bunker mode: move coins to fresh addresses, in case elliptic curves fall early, to AI or to quantum computers.
A coin can run to a fresh address. A file can't. Anything sealed with curves alone can be copied today and opened the day those curves fall. Nearly every signature agents and wallets emit rides on the same math.
ArShield seals what you can't move. Every .arshield envelope is sealed with ML-KEM-768, the NIST post-quantum standard, on top of X25519, and signed with ML-DSA-65. On your device.
Going full bunker? Seal to a freshly generated key file. Its keys are random and never touch your wallet's signature, so if curves fall, an attacker still has to break ML-KEM-768 too.
Generate a key file in the appA file goes in. An unopenable envelope comes out.
Five steps, one primitive at a time, all in your browser. Nothing in the chain is optional: a copy taken today needs every one of them broken to open.
Your file
Read in the browser. Never uploaded.
ML-KEM-768 + X25519
Two independent KEMs run side by side, then their secrets are combined.
AES-256-GCM
Payload sealed with the derived key and a random 96-bit nonce.
ML-DSA-65
The whole envelope is signed, header included, so tampering is detectable.
.arshield
One portable container. Opens anywhere with your wallet or key file.
an attacker must break ML-KEM-768 · X25519 · ML-DSA-65 · AES-256-GCM — every one of them to open a single file.
We can’t lose your file,
because we never see it.
There is no upload, no account, and no ArShield server holding a copy. The envelope is built in your browser and the only keys that open it stay with you — a wallet signature, or a key file you keep. Lose both and the file is gone; that is the point.
- Nothing is uploadedEvery byte is sealed on your device.
- No account existsThere is no sign-up, and nothing to reset.
- Two independent mathsML-KEM-768 and X25519 both have to fall.
- Verifiable offlineA Seal carries the digest, so you can check later.
Humans drop files. Agents call tools. Receipts get signed.
ArShield runs entirely in your browser or in your agent runtime. There is no backend that sees plaintext, not ours, not anyone's.
Humans
Drop a file in the browser. Out comes a .arshield envelope that only your wallet or your key file can open, plus a Quantum Seal receipt. Store it anywhere and open it on any device with the same keys.
Agents (MCP)
Call arshield_encrypt_file from Claude, Cursor, or any MCP-aware agent. Same envelope, same crypto, same signer model. Zero browser.
Payments (x402)
Agents sign x402 payment payloads with ML-DSA-65 over MCP, under their own context, so anyone holding the agent’s post-quantum public key can check which key signed. Every paid call gets its own Seal once Shield ships.
Built to keep working when the rest doesn't.
Post-quantum by default, portable by design, and verifiable offline.
One identity, two doors
A wallet signature derives your keypair deterministically; a passphrase-wrapped key file holds a random one. Seal in the browser, open in your agent — same keys, same .arshield format, no export step.
No server, no plaintext
The web app is a static export. The MCP server runs on your machine. There is no ArShield backend to breach, subpoena, or leak.
Post-quantum by default
Not an opt-in mode. Every envelope is hybrid from the first byte.
MCP-native
Six tools over stdio for Claude, Cursor, and any MCP client.
In-browser speed
ML-KEM-768 + X25519 run client-side in pure JS/WASM-free code.
Seals you can verify
A Quantum Seal PNG carries the envelope digest for offline checking.
Holders encrypt more.
The quantum-safe token on ARC.
The envelope is post-quantum. Once $arshield is live, your balance on ARC will set how much you seal: its USD value raises encryptions per day and maximum file size in the web app. Seals, messages and the MCP server are the same on every tier. No subscriptions, no accounts: your balance will be your tier.
Free
For first envelopes and the occasional file.
- Quantum Seal on every encrypted file
- Wallet or key file mode
Holder
For daily use: more files a day, and bigger ones.
- Quantum Seal on every encrypted file
- Wallet or key file mode
Pro
For heavy daily use and large archives.
- Quantum Seal on every encrypted file
- Wallet or key file mode
Whale
No daily cap and no tier cap on file size.
- Quantum Seal on every encrypted file
- Wallet or key file mode
Bunker mode for agents.
The same post-quantum envelope, shipped as six MCP tools for Claude, Cursor and any MCP client. It runs on your machine, so the keys never enter the chat.
$ npx -y @arshield/mcpArShield Shield: PQ Gateway for x402.
A post-quantum tunnel for every x402 endpoint your agents pay.
Front any HTTP 402 Payment Required endpoint with a Shield URL. Requests and receipts tunnel inside a post-quantum envelope, and every paid call emits a Quantum Seal that can be anchored on ARC. Every receipt deserves a Quantum Seal.
- Hybrid ML-KEM + X25519 tunnel: drop-in proxy in front of any x402 endpoint.
- Every paid call emits a Quantum Seal PNG with endpoint, amount, and transaction hash.
- Reserved capacity for $arshield holders: Pro and Whale tiers get priority lanes.
- One endpoint swap. No code rewrites. MCP-native. Agent-ready.
X402 · Quantum Seal receipts · ARC anchors
Also on the roadmap
- Seal anchoring on ARC, from the app and the MCP server
- Gas-free anchoring on ARC
- Encrypt for any address through an on-chain key directory
- Sealed receipts for agents that trade Stock Tokens
A first cohort of x402 endpoints, chosen from applications. No date set. The application form goes up when the gateway is ready for that cohort. Questions until then: write to us.
Things people ask.
Can't find what you're looking for? Browse the docs.
Both. Humans use the web app at /app: drag a file, get a .arshield envelope. Agents use the MCP server, a local stdio process that Claude Desktop, Cursor or your own runtime calls as arshield_encrypt_file, arshield_sign_x402 and four more tools. Same crypto, same envelope, same .arshield binary format.
Bunker mode is a plan being discussed across crypto: move coins to addresses whose public key has never been revealed, in case elliptic curves fall early, to AI or to quantum computers. It protects coins. It does nothing for data: a file copied today stays copied. ArShield seals your files post-quantum, on your device. Seal them to a freshly generated key file and a copy taken today still needs ML-KEM-768 broken to open.
HTTP 402 Payment Required, brought back by Coinbase as a protocol for agents to pay APIs in stablecoins. The MCP tool arshield_sign_x402 signs any x402 payment payload with ML-DSA-65 under its own context, so anyone holding the agent’s public key and the payload can check which key signed a receipt; /mcp documents the exact bytes that are signed and where the signing key sits in the public key. Sealing every paid call on its own is what Shield is for, and Shield is on the roadmap.
The server runs over stdio inside your own agent runtime and exposes six tools: arshield_encrypt_file, arshield_decrypt_file, arshield_send_message, arshield_decrypt_message, arshield_verify_seal and arshield_sign_x402. Keys come from a passphrase-protected key file (keyfile_path, which the server reads from disk, or keyfile_json, plus its passphrase), or from signature_hex plus the address that made it: your EOA wallet’s 65-byte signature of the ArShield derivation message, passed only over local stdio. So a file you encrypt in /app with your wallet opens in your agent with that wallet’s signature, no key export needed.
It means the cryptography is designed to resist attacks from both classical and quantum computers. ArShield uses ML-KEM-768 and ML-DSA-65, the standards chosen by NIST in FIPS 203 and 204. To guard against unknown weaknesses in any single algorithm, we combine ML-KEM with classical X25519 in a hybrid scheme, an attacker has to break both.
No. A wallet is the fastest path, and it’s what powers token-gated tiers and Seal anchoring on ARC. Your keys come from one wallet signature, so they can be reproduced only if the wallet signs the same way every time — the app reads the signature back and refuses if it does not recover to the connected address. MPC and threshold signers that produce a different signature each time will fail that check, which is the intended behaviour. For files that must outlast your wallet’s curve, generate a passphrase-protected key file instead: its keys are random and never touch your wallet’s signature, so if curves fall, an attacker still has to break ML-KEM-768 too. Agents pass a key file, or the same wallet signature, to the MCP server.
No. The web app is a static site and the MCP server runs in your own agent runtime. Every byte is encrypted and decrypted on your device, and no server of ours ever receives your files, their names or your keys. We hold no plaintext and no keys, so there is nothing to hand over. Like any web app, the browser side is only as safe as the code our site serves.
Without the wallet or the key file, your files are unrecoverable. There is no server copy and no reset, that’s the whole point of zero-knowledge. A wallet-derived key comes back from the same wallet signature, so the practical backup of the wallet path is the wallet itself. If you would rather not depend on that, generate a passphrase-protected key file from the key-source screen: it holds random keys and opens your files on its own. Store the file and its passphrase somewhere safe.
Holding $arshield on ARC raises the two limits the web app enforces: from 3 encryptions a day on Free to 25, 250 or no daily cap, and from 25 MB files to 100 MB, 1 GB or no tier cap. Encryption, Quantum Seals, messages, the MCP server and wallet or key file mode are open to every tier. No subscriptions, no accounts, just a wallet balance. Until the token launches, every wallet is on the Free tier.