bWeb build plan

Status: plan, 18 October 2026. None of the bWeb building service is live. The prices are a draft waiting for the owner’s approval. The first step is one real paid pilot, with the owner as the customer, before anyone else can order.

What bWeb is

You tell b, in bWalletX, what you want: a page for your band, a site for your café, a small shop. b writes a one-page brief. You get a fixed price in BSV and approve it once. An agent builds the site in a sandbox and shows you previews in the chat. When you are happy, the site is published on chain and you own the code. A shop takes payments through your own bWalletX Store.

The six steps:

1. Ask b. Describe what you want. b asks a few questions and writes a one-page brief.
2. Fixed quote. One tier, one price in USD, settled in BSV at the rate when the quote is made. One approval in your wallet.
3. Build. A headless Claude agent builds the site in a sandbox. Progress and preview screenshots appear in your chat with b.
4. Preview and changes. You get a preview link. Small changes are included; bigger ones get a new quote before any work.
5. Launch on chain. The files are inscribed on BSV, and you get a permanent address (and optionally a name). The code is yours.
6. Upkeep (optional). A monthly plan for small edits and re-publishing.

On-chain hosting: what we checked

All findings below were checked on 18 October 2026 with read-only requests to ordfs.network, the GorillaPool ordinals API and GorillaPool ARC.

Serving a page

A 1Sat ordinal inscription of text/html is served as a normal web page by ORDFS:

• https://ordfs.network/<txid>_<vout> returns the page with its own content type. Example: 80712ee1…11e6_0 (a 17 KB HTML inscription, block 971494) came back 200, content-type: text/html;charset=utf-8, with x-outpoint, x-ord-seq: 0 and the MAP metadata in x-map.
• https://ordfs.network/content/<outpoint> returns the same, and /v2/metadata/<outpoint> returns the metadata as JSON.
• Pages load other inscriptions by outpoint. Example: a252d85e…76dc_0 loads https://ordfs.network/content/5ea546aa…6ccd_0 as a script. Same-origin paths (/content/<outpoint>) work too, so the page is not tied to one gateway host.
• POST https://ordfs.network/preview with an HTML body returns the rendered page without broadcasting anything (checked: 200 text/html).

Many files: directory inscriptions

A site with several pages, CSS, JS and images is inscribed as one transaction:

• output 0 is an ord-fs/json manifest, for example {"index.html":"_1","about.html":"_2","style.css":"_3","logo.png":"_4"};
• outputs 1..N are the files.

_N means “output N of this same transaction”, so the whole site is written in one go and links inside it stay relative (href="about.html", src="logo.png"). ORDFS serves /content/<manifest>/about.html, falls back to index.html for unknown paths (single-page apps work), nests sub-folders by pointing a key at another manifest, and returns the manifest with ?raw. We did not find a live ord-fs/json example among the ~40,000 most recent inscriptions, so the pilot’s first job is to inscribe a two-file test site and confirm every one of these behaviours before we promise them.

Addresses and names

Three ways to reach a site, in order of how ready they are:

1. The outpoint itself (ordfs.network/<origin>). Works today and never changes.
2. A custom domain. ORDFS reads a DNS TXT record _ordfs.example.com "ordfs=<origin>" (optionally :<seq> to pin a version). The customer keeps their normal domain; the content comes from chain. To confirm in the pilot.
3. An OpNS name. OpNS today binds a name to an identity key (see the name bindings page), not to content, and David Case’s resolver work is still in progress. Name → site needs a small “site” record signed by that key. We will not promise names until that exists. The old bitcoin_dns and bitDNS repos are concept sites (company b. subdomains with tokens); they have no resolver we can reuse.

Updating a site

An inscription can’t be edited, but an ordinal can be re-inscribed: spend the site’s ordinal output into a new transaction that carries the new manifest. The origin stays the same, and ORDFS serves the newest version at /content/<origin>:-1 (60-second cache), while :<n> keeps every past version reachable (30-day cache). So:

• the permanent address is …/content/<origin>:-1 (or the DNS record without a pinned sequence);
• each update re-inscribes only the changed files plus a new manifest; unchanged files keep their old outpoints in the manifest;
• the customer holds the site ordinal in their own wallet, so only they (or someone they authorise) can publish an update. This is what “you own it” means in practice.

The re-inscription chain needs testing in the pilot as well.

Cost

GorillaPool ARC’s current policy is 100 sats per 1,000 bytes, and the largest transaction it accepts is 100 MB. At $17.93 per BSV (WhatsOnChain, 18 Oct):

Site size	Fee	In USD
100 KB (simple page)	~10,000 sats	~$0.002
1 MB (site with photos)	~100,000 sats	~$0.02
10 MB (shop with many product photos)	~1,000,000 sats	~$0.18

Fees are tiny next to the AI cost. We still compress images and limit pages to sensible sizes, because nothing can be deleted once it is inscribed.

Limits

• No server code. Sites are static HTML, CSS, JS and media. No database, no secrets, no server-side forms.
• Forms, sign-ins and payments go through bWalletX using Connect (BRC-100) on the page. A contact form becomes “send a message to the owner’s $name” or a bMail; a shop button becomes a payment to the owner’s Store.
• Permanent and public. Anything published stays on chain forever. No personal data about customers’ own customers, ever, and no secrets in files.
• Gateways. ORDFS is run by a third party. The content is on chain and any 1Sat indexer can serve it, but the convenient URL depends on ORDFS staying up. We should run our own gateway later.

The pipeline

Ask b ─▶ brief ─▶ quote ─▶ one approval (BSV) ─▶ job queue ─▶ agent in sandbox
     ─▶ preview ─▶ changes ─▶ launch inscription (+ DNS / name) ─▶ upkeep

1. Brief

b (already live in bWalletX chat) asks: what is it for, pages, words and photos you have, colours, shop or no shop. It writes a one-page brief as JSON plus a readable summary, and the customer confirms it. The brief is the contract: the tier and what “done” means come from it.

2. Quote and payment

Reuse the theme-order pattern already running at bwalletx.com/api/theme-orders (site/lib/themeOrders.js in the wallet repo):

• every request (quote, claim, mine) is signed by the wallet’s identity key;
• quote fixes the USD price, converts it to sats at the current rate, and returns a pay address (an env var, never in code), the amount, a quote_id and a 15-minute expiry;
• the wallet shows one approval; the transaction carries an OP_RETURN "bwx-bweb-order" <quote_id> memo that ties the payment to the quote;
• claim sends the signed transaction to our server, which checks it pays the quote and broadcasts it (ARC), then marks the order paid. Late payments within a day of expiry are still accepted.

New table bweb_orders (id, identity_key, tier, brief, quote fields, status quoted → paid → building → preview → launched | refunded | failed, preview outpoint, launch origin, created/updated). The migration goes to the owner for review before it runs.

3. Job queue and dispatcher

The b bug loop idea already needs the same thing: “b files an issue → a dispatcher wakes a headless Claude session → it ships → b replies.” The intake half exists (b_feedback and the hourly curator in bit-sign); the dispatcher does not exist yet. bWeb should build it once and share it:

• the queue is a table (agent_jobs: kind bweb | bug, payload, status, attempts, logs URL);
• a small dispatcher on the always-on Mac picks one job at a time, starts the sandbox, runs claude -p (Claude Code headless) with the brief and a fixed bWeb skill, and streams progress lines back to the customer’s chat;
• one job at a time at first. Each job gets a token budget per tier (below); going over stops the job and asks a person.

4. Sandbox build

• A fresh, throwaway sandbox per job (container or a Mandala VM), with a starter static-site template, our design rules, and the image tools. No access to our repos, keys, database or the customer’s wallet.
• Network: only the package registry and the customer’s own uploaded files. No outbound posting.
• Output: a folder of static files under a size cap per tier, plus screenshots at phone and desktop width. A checker script fails the build on broken links, missing alt text, files over the cap, or anything that looks like a key or a personal address.

5. Preview

Options considered:

Option	Good	Bad
Testnet inscription	Same mechanics as launch	ORDFS doesn’t serve testnet; customer can’t open it easily
Private preview inscription on mainnet	Exact final behaviour	Permanent and public: drafts would live forever
Preview on our own server (chosen)	Private, deletable, instant, free to change	Not 100% the final environment

Choice: previews are served from a private, expiring link on our server (static files, unguessable URL, 30 days), rendered under the same /content/<outpoint>/path layout so relative links behave exactly as on ORDFS. Drafts never touch the chain. ORDFS’s POST /preview is used as a last check of the home page before launch. Only the approved final version is inscribed.

6. Launch

• The server builds the inscription transaction (manifest at output 0, files after), the customer’s wallet pays the fee and receives the site ordinal, and we broadcast. The customer approves once, with the size and fee shown.
• We hand back: the permanent link, the DNS TXT line to paste if they have a domain, and a zip of the source.
• A shop: product data in the site, and the buy buttons pay the customer’s bWalletX Store (their address, their money; we take nothing on sales).

7. Upkeep

Monthly: small text and photo edits, re-publishing (new re-inscription, customer approves the fee). Cancel any time; the site stays up because it is on chain.

Draft price tiers (for owner approval)

Prices in USD, settled in BSV at quote time. Draft, not final.

Tier	Price	Includes	Our AI cost (est.)	Inscription fee (paid by customer at launch)	Margin (est.)
One page	$49	One page, your words and up to 6 photos, contact by $name/bMail, 1 round of small changes	$4–8	under $0.01	~$40
Site	$149	Up to 5 pages, simple navigation, up to 25 photos, 2 rounds of small changes, custom-domain setup notes	$12–25	~$0.02	~$125
Site + shop	$299	Site tier plus up to 30 products paid through your bWalletX Store, order emails via bMail, 2 rounds of changes	$25–50	~$0.05–0.20	~$250
Upkeep	$9/month	Up to 3 small edits a month, re-publishing	~$2–4	~$0.01 per publish	~$5

How the AI cost was estimated: Claude Opus 5.5 at $4 per million input tokens, $20 per million output, $0.20 per million cached input. A one-page build is roughly 1M fresh input, 3M cached input and 150K output (~$7); five pages roughly triple it; a shop roughly doubles that again. These are guesses until the pilot measures a real run. Each tier gets a hard token budget at about twice the estimate; a job that hits it stops and a person looks.

Not included in any tier: logos from scratch, copywriting beyond tidying your words, anything needing a server, adult content.

Security and policy

• Agent sandbox: throwaway per job, no keys, no repo or database access, limited network, size and time caps.
• No customer secrets: we never ask for passwords, keys or API tokens. If a brief contains one, b refuses and asks the customer to remove it.
• Content policy: no impersonating real brands or people, no scams or phishing, no fake reviews, no illegal content, no adult content in bWeb. b checks the brief before the quote, and a person reviews the final preview before launch during the early period.
• Payments: only through the customer’s wallet with one approval; signed requests; server-side check that the payment matches the quote.
• Refunds: if a build fails or we can’t deliver what the brief says, we refund the full amount in BSV to the paying address. If the customer cancels after a preview, we refund the price minus the measured AI cost. Nothing is inscribed until the customer approves the launch.

The pilot

Owner as the first customer, paying real BSV, before anyone else can order. It needs:

1. Owner approval of the tiers (or new numbers) and of the bweb_orders / agent_jobs migration.
2. A pay address env var for bWeb orders (could reuse the bCorp receive address, with owner OK).
3. An Anthropic API key for the dispatcher in the Mac’s environment, with a spend limit.
4. The always-on Mac (mini today, Studio later) to run the dispatcher.
5. A two-file test inscription to confirm ord-fs/json, _N links, :-1 updates and the DNS TXT record (a few cents).
6. A brief for the owner’s own site (which one?) and a person to review the preview.

Measure in the pilot: tokens and dollars per build, minutes per build, how many change rounds, any ORDFS problems. Then fix the prices and open a waiting list.

Open questions for the owner

• Are $49 / $149 / $299 and $9/month right, or do you want lower “try it” prices?
• Does the customer’s wallet pay the inscription fee, or do we include it in the price (it’s under a dollar)?
• Do we offer OpNS names at launch, or wait for the resolver?
• Should we run our own ORDFS gateway (for example site.bwalletx.com/<origin>) before opening?
• Which site should the pilot build?
• Is a person reviewing every launch acceptable at first, given the content policy?