EVM × Sui Walrus GitHub
Showcase 02 · implemented

Host your dApp frontend on Walrus, point ENS at it.

Replace the IPFS-pinned-CID-behind-eth.limo pattern with one site-builder publish + one SuiNS link. No EVM contract; no IPNS; no public IPFS gateway in the critical path. The ENS bridge is a single DNSLink or CNAME from yourdapp.eth to the wal.app portal.

Source: showcases/02-walrus-sites/ Tools: site-builder CLI · SuiNS app · DNS Bytes: any static SPA output (Next.js export, Vite build, plain HTML)
01 · the pain

2024 broke the Cloudflare-gateway-behind-ENS-contenthash pattern.

2026 vibe
ipfs-pain.md · §10
"ENS contenthash is non-negotiable; pay Pinata or Filebase rather than trusting any free gateway; treat IPNS as broken." — and Uniswap interface #7753 had to rewrite "all references to Cloudflare's IPFS gateway."
— 2026 builder-sentiment survey
02 · the shape

Sui object owns the site, SuiNS owns the human name.

site-builder publish uploads the static build, creates a Walrus Site object on Sui, and returns its site_object_id. A single Sui transaction then links a SuiNS name to that object id — after the next epoch boundary the site resolves at <your-name>.wal.app.

Updating the site is republishing + re-linking. The SuiNS name is the only mutable surface; there is no IPNS, no DNSLink TTL race, no "what if the gateway operator forgets to renew DNS."

ENS users keep their .eth name and bridge to the wal.app portal via either DNSLink (closer to decentralized contenthash) or a CNAME from a custom domain (simpler, more centralized).

# the entire publish flow
pnpm build
site-builder --context testnet publish ./out \
  --epochs 200 \
  --site-name "yourdapp-demo"

# prints:
#   site_object_id: 0xa1b2c3...
#   resolves at <base36-of-id>.wal.app
#   (or yourdapp.wal.app once linked to SuiNS)
build/
site-builder
SuiNS · wal.app
03 · try it locally

Publish a 22-line example site to Walrus testnet.

01

Install the site-builder CLI

The site-builder binary is separate from the main walrus CLI. Follow the install instructions:

docs.wal.app/sites/getting-started/installing-the-site-builder/

You also need a Sui keypair with testnet SUI for gas and testnet WAL for storage. Get them from the Sui faucet and the WAL faucet.

02

Publish the included example site

cd showcases/02-walrus-sites
./publish.sh ./example-site
# → site_object_id: 0xa1b2c3...
# → log line ends with the <base36-of-id>.wal.app URL

The publish.sh wrapper hardens the raw CLI with input validation, a network selector (NETWORK=testnet|mainnet), and a configurable epoch budget (EPOCHS=200 default).

EnvDefaultPurpose
NETWORKtestnetSui + Walrus network the CLI talks to.
EPOCHS200How long the published blobs stay live before re-extension.
SITE_NAMEshowcase-02-demoFree-form label written on the Walrus Site object.
03

Link a SuiNS name to the site

Two paths — pick whichever fits your tooling:

  • SuiNS web app (one-off setups). Open suins.io, pick your name, use the "Set Walrus Site" action, paste the site_object_id. Sign with the wallet that owns the name.
  • PTB / sui client call (CI). Invoke the SuiNS package's set_walrus_site entry. The exact package id depends on the network — see docs.suins.io for current values.
04

(Optional) Bridge from ENS

DNSLink path — closer to decentralized contenthash:

# at your DNS provider
_dnslink.<yourdapp.eth>  TXT  "dnslink=/https/<your-suins-name>.wal.app"

# in the ENS Manager (https://app.ens.domains)
# set contenthash for <yourdapp.eth> → DNSLink('<yourdapp.eth>')

CNAME path — simpler, more centralized:

# at your DNS provider
app.<yourdomain.com>  CNAME  <your-suins-name>.wal.app

# in the ENS Manager
# set the `url` text record to https://app.yourdomain.com
04 · verify

What "good" looks like.

05 · what this is NOT

Limits to set expectations.

  • Not a Cloudflare IPFS gateway drop-in. The fundamental swap is from IPFS's P2P fetch to a Walrus aggregator's deterministic HTTPS fetch. Clients that probe for ipfs:// won't transparently see Walrus URLs.
  • Not an IPFS-pin migrator. This publishes new blobs to Walrus. Moving an existing pinned-on-IPFS frontend involves rebuilding and re-publishing — source is the input, not the CID.
  • Not a one-shot deploy. Each build produces a new site_object_id. The "mutable pointer" is the SuiNS link; re-link on each release.
  • SPA routing caveat. If your build uses client-side routing, emit a 404.html that re-bootstraps the shell — the wal.app portal serves static bytes only.
06 · source files

Where to look in the repo.