Multi-Cloud Storage Without Lock-In — Arweave, IPFS, Hedera

Arweave permanence is the floor, not a menu item Evercore’s multi-backend feature is frequently misunderstood as “pick a chain.” The accurate mental model is Arweave-first permanence with governed augmentation layers: 1. Permanence — Arweave is always part of the deployment story (primary or mandatory replica). 2. Primary write — which backend receives the encrypted bytes first (arweave or ipfs-kubo). 3. Replicate — fire-and-forget mirrors with trace tags (Evercore-Replicated-From, Evercore-Replicates). 4. Anchor — optional Hedera HCS audit messages via Pub/Sub workers. POST /files/upload is still the front door. What changes is how ContentPolicy on the tenant steers layers 2–4 after validation, encryption, and plan gating. This article walks the three canonical scenarios documented in MULTI_BACKEND_FLOW.md—without marketing gloss—so architects can map them to latency, cost, and audit requirements. Scenario A — Pure Arweave (default) When to choose A: You want the original Evercore guarantees—encrypted permanence, manifest versioning, receipts—without operating kubo or HCS infrastructure. Many growth-stage tenants live here indefinitely. Read path: POST /files/download/:locator routes 43-char locators through the Arweave gateway pipeline; decryption is identical regardless of how the object was ingested. Scenario B — Arweave primary + Hedera anchor (dual-chain audit) When to choose B: Compliance wants proof-of-existence on an independent consensus log in addition to Arweave—common in SOC 2, GDPR accountability, or programs that already standardize on HashScan-style explorers for auditors. Cost is dominated by HCS message fees (~$0.0001 per message on mainnet; testnet is free). Finality is seconds, not minutes—useful for “seal this step before the business day closes” workflows. Operators inspect anchors via: • POST /hedera/audit/timeline — tenant-scoped HCS log • POST /hedera/audit/source — all messages for a { kind, id } source • POST /hedera/anchor/verify — mirror node re-fetch Console renders these as structured sheets (event, source, receipt, metadata)—not character-split JSON. Scenario C — IPFS hot primary + Arweave replica + Hedera anchor When to choose C: Day-to-day reads should hit hot IPFS retrieval (milliseconds in your VPC), while Arweave holds the long-horizon record and Hedera holds the audit timeline auditors can query without understanding CID gateways. This is the enterprise pattern validated by the e2e:multi-backend-arweave-first script: upload C returns a CID, replica tx appears under contentBackend=arweave, anchor sequence lands on a tenant topic, and POST /proofs/multi-anchor/verify returns parallel reachability for Arweave, IPFS, and Hedera cards in Console. ContentPolicy is the control plane Tenants set policy with: • GET /storage/policy • PUT /storage/policy (plan-gated) • DELETE /storage/policy (reset to Arweave-only) Scopes include storage:policy:read|write, storage:hedera:anchor, storage:ipfs:write|read|unpin, and audit:timeline:read. The Console Storage Policy UI renders four layers and forces Arweave permanence when operators pick IPFS primary—removing the Arweave replica triggers a destructive banner because “hot without cold” violates the product’s custody story. Plan tiers (packages/shared/src/plans.ts) gate capabilities: Growth lacks Hedera and IPFS; Professional enables both with caps; Enterprise adds tenant-scoped topics and unlimited hot storage. Pricing copy on /pricing explains the economic framing—this article focuses on mechanics. Reading, listing, and reconciling across backends /files/list adds contentBackend and anchored=true|false|any filters. Rows expose backendId and anchors[] so UI badges link to the correct external explorer (ViewBlock vs IPFS gateway vs HashScan). Important: reconciliation errors that used to throw “Transaction ID must be 43 characters” for CIDs are gone—operators can refresh chain status for both locator families from the same menu action. Multi-anchor verification as an integration test POST /proofs/multi-anchor/verify runs Arweave, IPFS, and Hedera checks concurrently (Promise.allSettled). A typical CID-primary response shows IPFS reachable immediately, Arweave reachable after replica lag, and Hedera mirrorVerified: true when configured. Treat this endpoint as your release gate when enabling scenario C in a new environment: if any leg is false after configured wait windows, you do not yet have a defensible enterprise path—only a demo. Failure modes to document in runbooks • Replica lag — Arweave replica is fire-and-forget; automation must not assume instant dual registration. Use list filters or wait knobs (E2E_REPLICATE_WAIT_SECONDS). • Anchor degradation — Missing Hedera operator credentials skip anchoring silently; /health reports hedera-anchor status. Uploads still succeed; audit programs must alert on skipped anchors. • Plan gate denials — Saving anchor: "hedera" on Growth fails server-side in plan-gate.ts; surface this to admins during procurement, not during go-live night. • Locator confusion — Downstream systems must store both CID and replica tx id when scenario C is active, and know which locator is canonical for each workflow step. Where to go next • Platform overview: /platform/multi-backend and /platform/multi-backend/routing • Operator doc: apps/evercore-ms/docs/MULTI_BACKEND_FLOW.md • Pricing FAQ: multi-backend difference on /pricing • E2E: npm run e2e:multi-backend-arweave-first from evercore-ms Closing Multi-backend is not “more chains for marketing slides.” It is a layered write pipeline where Arweave remains the permanence anchor, IPFS optionalizes hot retrieval, and Hedera optionalizes an independent audit timeline—selected per tenant policy, enforced per plan, and verifiable with multi-anchor proofs. Pick scenario A, B, or C based on read latency, audit independence, and operational complexity you are willing to own—not based on which logo slides best.

Topics

• multi-backend storage API
• Arweave enterprise storage
• IPFS hot retrieval GDPR
• Hedera audit anchor
• ContentPolicy routing
• cloud storage without lock-in
• permanent storage plus hot read
• multi-anchor verification