Encryption Before Arweave Is a Custody Decision, Not a Checkbox

The question regulators keep asking When teams talk about “uploading to a permanent network,” security reviewers do not hear novelty. They hear loss of control. Permanent implies durable. Durable implies long-lived mistakes. Long-lived mistakes are where fines and headlines come from. That is why Evercore treats encryption as a custody decision first and a performance detail second. The product story is blunt: encrypt before data reaches Arweave and treat keys with a seriousness that matches your regulatory reality. What AES-256-GCM buys you in this architecture AES-256-GCM is widely understood by security reviewers: strong symmetric encryption and authentication in one primitive when used correctly. The part non-cryptographers miss is that “using it correctly” is mostly about operational discipline: • Randomized IVs per object (or per encryption operation), handled consistently end-to-end • Auth tags verified on decrypt, so tampering fails closed • Clear documentation of where keys live, who can access them, and how rotation works Evercore’s marketing surfaces emphasize that decryption keys are kept outside Evercore as part of the trust narrative. That is not a slogan. It is a boundary statement procurement can test against. Why “before Arweave” changes your legal story If plaintext lands on-chain, your permanence is also a permanence of risk. Even if access is inconvenient, the narrative becomes harder: you must explain what was exposed, to whom, and under what assumptions. Ciphertext changes the posture. You can explain permanence as commitment to a specific encrypted artifact, with keys and access paths governed elsewhere in your system. This distinction shows up in: • Data processing agreements • Incident response playbooks • Cross-border transfer analysis • Disclosure discussions when counterparties ask what “immutable” actually means in practice IV and auth tag metadata: boring until it is Exhibit A Engineers sometimes want metadata to disappear into “implementation details.” In evidence workflows, those details become audit artifacts. If you cannot reconstruct how an object was encrypted and how integrity was verified, you do not have an evidence-grade story. You have a demo. Evercore aligns with a clear approach: encryption metadata is part of the technical contract, not something you hope future-you remembers. Relationship to sharing, rooms, and exports Encryption at ingest is only the first chapter. Regulated teams also need: • Controlled external sharing with policy • Room workflows for review cycles • Export packs that can survive skeptical inspection Evercore packages those ideas as pillars around the same custody spine. Encryption is what makes those downstream controls meaningful rather than theater. What a serious proof of concept should test If you are evaluating Evercore in a security review, prioritize tests that map to how you fail in production: 1. Key compromise rehearsal: if a key is rotated or revoked, what breaks, and what remains provable? 2. Partial pipeline replay: can a retry create ambiguous duplicates, and how does deduplication interact with ciphertext identity? 3. Access path review: who can decrypt in each environment, and how is that enforced beyond secrets in a console? If those tests feel unfair, that is the point. Audit environments are unfair on purpose. Where the cryptography meets your everyday API Evercore surfaces cryptographic decisions next to the boring API objects engineers already reason about: files, manifests, tags, routing. You can treat OpenAPI/Postman as the “how to call it” contract, and the encryption platform page as the “why the ciphertext is never optional” contract. Batch uploads, dedup identity, and receipt-style responses are not unrelated features. They are how you keep ingest from lying to downstream evidence: • A retry should not accidentally turn into a second immutable story if the bytes are identical. • Settlement confirmation should remain distinguishable from “HTTP said ok”. • Version lineage (Parent-TX semantics in the product narrative) should remain legible when someone asks “which immutable object is the successor?” What you can verify without trusting marketing copy A useful internal demo is: upload the same file twice with different metadata labels but identical bytes, then show what changed and what did not. If “immutability” and “identity” are fuzzy after that demo, you have found a real gap early. Closing Encryption is not “turned on” so a checkbox turns green. It is how you keep permanence from turning into permanent liability. If you want the technical surface for Evercore’s encryption story, start at the platform encryption page and follow through to docs and OpenAPI where your engineers live day to day.

Topics

• AES-256-GCM
• application encryption
• key custody
• regulated data
• Arweave