How a site lives on-chain

Three steps take a site on-chain:

1. Bind: use SiteRegistry to bind the site to the container identity.
2. Publish: release the files through HashPort.
3. Visit: open it through tape://.

How a tape:// address gets opened

The browser derives the container address from the name, reads the files back from the chain chunk by chunk, and shows nothing until every byte checks out.

1. Find the processor: read the factory contract to get the processor contract address.
2. Derive the container address: it is computed from "chain + processor contract + #ID", not self-reported, so nobody can impersonate another site.
3. Check the state: does the circuit exist? Is the container open? Is it blocked by this client?
4. Activation check: a spec-compliant client only shows activated names.
5. Read the files: read from the SiteRegistry repository contract, stored in 24,000-byte chunks, each file up to 8.4 MB.
6. Verify byte by byte: the length must match the declared size and the SHA-256 must match the on-chain record, or it is not shown.
7. Render isolated: each site runs on its own and can harm neither you nor other sites.

Two baselines: every read needs at least two nodes from different operators to return exactly the same result, and any mismatch is rejected (no majority vote); all files are read as of the same block, so a site is never half old and half new.

The tape:// spec v0.2

The tape:// spec v0.2 (2026-09-13, draft) governs exactly four things: URL format, address resolution, verification, site isolation. It does not cover how files are uploaded, how a normal browser visits them, or how a wallet is built. Three parts matter most to developers:

• Site isolation (§7): an on-chain site may be malicious, so the shell must keep it from harming you, other sites, or the shell itself — one origin per site, no privileged execution, restricted network requests and popups.
• The "100% on-chain" mark (§8): only sites that pass both static scans and runtime checks show "100% on-chain".
• The immutability promise (§15.1): the spec separates "what never changes" from "what may change" and sets version-number rules.

What to open it with

The community builds openers too: the Wafer desktop browser (Mac beta) and a browser extension with a configurable gateway. Both are third-party — vet the source before installing.

How to put a site up

A. HashPort console (hosted): pick a circuit, drag in the site folder, sign; it handles hashing and chunking. You confirm 2 wallet signatures and a temporary wallet signs the rest of the uploads; the cost is on-chain gas only, about 0.01‒0.03 BNB per MB, the service fee shows 0 BNB, and binding your own domain is optional and free.

B. Call the contracts yourself: putFile writes the first chunk (≤24,000 bytes), appendChunk appends, setFallback sets the single-page-app fallback, and removeFile deletes.

Even with no circuit skills you can open a container in a minute: the community "container factory" runs pick a name, mint, tape out, open the container, using one NAND for the lowest cost.

Before publishing: static files only, always relative paths, prefer English file names, compute each file SHA-256 first; to earn the "100% on-chain" mark, the HTML/CSS must not reference any off-chain address (self-host fonts, scripts and analytics).

Does activation cost anything

Accounts conflict: the spec says 0.08 BNB per 30 days (pay 1‒120 months up front, non-refundable); HashPort shows a 0 BNB service fee with free domain binding; the on-chain monthlyFee() currently reads 0. As of writing it is 0 on-chain while the docs lag behind, so trust the amount your wallet shows.

Activation is only an official-client convention to show activated sites; it does not lock the data away — anyone can read the chain.

A hash is a file fingerprint: it proves you fetched the published copy, not that the content is true.

What it changes

• Blocking cost: from blocking one IP to blocking a whole chain.
• Ownership: a site finally belongs to whoever holds the private key.
• Security: from trusting institutions to byte-by-byte hash checks.
• Asset: sites become tradeable, financeable and cash-flowing.
• Publishing: digital content can be permanent for the first time.

Still early

Storage cost, read speed and UX are all still early — do not treat it as a finished internet.

On-chain Linux: a technical demo

On 2026-09-07 the founder posted a demo he called "the first time Linux ran on an L1 mainnet": every instruction executed by a BNB Chain mainnet transaction, all state stored on-chain. He compared it with Cartesi — Cartesi runs Linux on an off-chain node and the L1 only recomputes a step when there is a dispute.

The official on-chain Linux page shows the demo running mainline Linux 6.5.12 (rv32ima, no MMU, busybox userland):

• 16 MB of memory lives in 16,384 page contracts;
• each tick() call runs up to 1,024 instructions;
• from boot to the root login prompt it ran about 41.8 million instructions;
• the "machine" is owned by a circuit container.

It is not about speed — it is about proving that every step of computation can be put on-chain for anyone to check.

Community DeWEB apps at a glance

As of 2026-09-25, a scan of all records in the site-repository contracts on BNB Chain and X Layer found 51 on-chain sites with files written: 39 real community apps (36 on BNB Chain, 3 on X Layer), 2 official sites (the TapeKit home and a copy), and 10 test, empty or template pages.

The community apps fall into a few categories (format tape://<id>.<processor>):