IPFS
Content-addressed sharing. Anyone holding a file's CID can fetch and read it, and the file disappears once nobody pins it any more.
Why ZNode
Traditional clouds keep your files and the keys to them. Most decentralized networks make you choose between privacy, persistence and simplicity. ZNode Grid is built so you don't have to choose.
vs. traditional cloud
Big cloud drives encrypt your data at rest, but with keys they control. That means the provider can read, scan, lose or hand over your files. ZNode moves the key to your device and the storage to a network nobody owns.
The provider. Files are encrypted at rest, but with keys the provider holds, so staff, scanners and legal requests can reach them.
Only you. Files and their names are encrypted in your browser with a key that never leaves it.
Email and password, often a phone number, and an account the provider can suspend.
A wallet signature. No password exists, so there is none to leak, reset or phish out of a database.
One company's data centres, under one set of policies.
Three replicas on independent nodes, spread across different operators where possible.
A monthly subscription that keeps going up, forever.
One fixed payment, verified on-chain. No subscription.
To the provider.
90% into a reward pool that only the people running storage nodes can earn from.
Terms of service that can change at any time.
A public smart contract. Prices, fees and payouts follow code anyone can read.
vs. Storj & IPFS
IPFS is great for sharing public content, but it doesn't encrypt anything or keep it stored. Storj is private and durable, but it works like a cloud account: monthly bills, its own token and a company running the satellites. ZNode keeps the privacy and durability and drops the rest.
Content-addressed sharing. Anyone holding a file's CID can fetch and read it, and the file disappears once nobody pins it any more.
Encrypted, erasure-coded object storage. Strong engineering, billed monthly, with operators paid in the STORJ token.
Sealed in your browser, kept as three self-healing replicas, paid once in ETH under rules set by a public contract.
| Feature | ZNode Grid | Storj | IPFS |
|---|---|---|---|
| Encrypted before upload | Yes:AES-256-GCM in your browser, names included | Yes:Client-side encryption in the uplink | No:Public by default. Anyone with the CID can read it |
| Stays stored without babysitting | Yes:3 replicas, automatic repair in ~15 s | Yes:Erasure coding with automatic repair | Partly:Only while someone keeps it pinned |
| Sign-in | Yes:Wallet signature, no account | Partly:Account with email and password | Yes:None needed (peer-to-peer) |
| How storage is paid for | Yes:One fixed on-chain payment in ETH | Partly:Monthly usage billing | No:Not built in. Pinning services or Filecoin |
| Operator rewards | Yes:ETH, claim whenever you like, no held-back escrow | Partly:STORJ token, monthly, part held back for new nodes | No:None. Hosting is volunteer |
| Payout rules enforced by | Yes:A public smart contract | Partly:Satellites run by Storj | No:Not applicable |
| Storage overhead | Partly:3× (full replicas) | Yes:About 2.75× (erasure coding) | Partly:Depends on how many nodes pin it |
| Coordination | Partly:A single coordinator today | Partly:Satellites run by Storj | Yes:Fully peer-to-peer |
Security
Your vault key is unlocked from a wallet signature that happens on your device. The servers never see it, so a breached server doesn't mean breached files.
You sign a fixed unlock message. Signing is deterministic, so the same wallet always gives the same result.
The signature hash is stretched into a 256-bit unlock key, inside your browser.
A random 256-bit key, made once on your device. The server only ever stores it wrapped by the unlock key.
Every file and its metadata is sealed with a fresh random IV. Any tampering fails the auth tag.
What they getEncrypted blobs with random IDs. No names, no owner, no key.
Why it's not enoughChanged bytes fail AES-GCM's auth tag, and the file is fetched from another replica.
What they getEncrypted metadata, file IDs and wrapped vault keys.
Why it's not enoughUnwrapping a vault key needs that user's wallet signature, which never reaches the server.
What they getNode addresses and opaque blobs it routes.
Why it's not enoughIt never has a decryption key. Its settler key is limited by the contract to paying registered operators out of the reward pool.
What they getNothing. Storage is granted only after six checks pass.
Why it's not enoughChain, recipient contract, call data, exact amount, confirmations and the StoragePurchased event are all verified.
The contract only credits operators out of the reward pool, so every balance is backed by ETH it already holds.
Each node signs a fresh challenge with its own key, and must answer at its registered address before it gets traffic.
The backend and coordinator authenticate each other with a shared secret, compared in constant time.
Your part: because your wallet signature unlocks your vault, only sign the ZNode Grid Master Unlock v1 message on this site. A site that tricks you into signing it could decrypt your files. Losing your wallet means losing access too, so keep your seed phrase safe.
Go deeper
Architecture, cryptography, the node network, the economics and an honest threat model.