Permaweb Publishing and Protocol Extensions

Frontend decentralization that matches your smart contracts.

Static assets are addressed by TX ID and served through Arweave gateways - swapping the UI means publishing a new transaction, not editing a server file.

• Content addressing: Each file maps to a TX ID - immutable references instead of a single origin you can silently replace.
• Manifest routing: Manifest operations in the API produce path → TX maps (application/x.arweave-manifest+json) so relative imports and SPAs resolve through the gateway.
• No central host: Many gateways can serve the same TX IDs; there is no one provider whose dashboard can unpublish the chain copy.
• One-time upload cost: Storage is paid per upload to the network, not a recurring hosting subscription for the static bundle itself.

Can I update my dApp after deployment?

Yes - use Arweave Manifests to create a new version of your deployment. Your ArNS name always resolves to the latest manifest. Older versions remain permanently accessible via their TX IDs for historical reference.

How do I handle dynamic data in a static permaweb app?

Static assets (HTML, CSS, JS) live on Arweave. Dynamic data usually comes from API calls to your own backend; reads from the wider Arweave network use public gateways and explorers. Hybrid architectures with a traditional backend for writes are common.

What is the uptime guarantee for Arweave-hosted content?

Arweave has no SLA in the traditional sense - it is a decentralized protocol. Evercore routes requests through multiple gateways for maximum availability, but gateway uptime is maintained by separate entities in the Arweave ecosystem.