The name marketplace

The open market for aliases and domains, in the browser: a single browse pane that lists every name currently offered for sale, lets you buy one with a click, list your own for a fixed price, and look back over completed sales. It is the graphical twin of the CLI’s alias sell/alias buy and domain sell/domain buy commands — the same fixed-price, first-come-first-served listings, driven from a page instead of a terminal. Prices are in SOL; a completed sale settles on-chain with the seller keeping 90% and the postoffice the remaining 10% (the standard marketplace split).

The marketplace ships two ways, both from the same shared core (webclients/shared/marketplace-panes.js):

• a standalone page (webclients/marketplace/) that does nothing but the marketplace, and
• the identical pane mounted inside the webmail app, the Outlook add-in, and the Thunderbird extension, alongside their other settings panes.

Two wallets meet here

Every other browser pane signs in the page with the in-wasm keypair (see the webmail app). The marketplace is deliberately different, because you may want to buy a name with a hardware wallet or a Phantom account that never touches this app:

• Browsing and sale history are plain reads. They ride the authenticated /v1/chain/listings and /v1/chain/sales account-api routes with your normal session JWT. The listing index is global — the JWT only authenticates the request; whose wallet it belongs to is irrelevant to what you see.
• Buying and listing sign with an external wallet. When you click Buy or List for sale, the pane connects your browser wallet — Phantom or a Ledger through it — builds the unsigned wire transaction from a wasm *_unsigned builder, and hands it to that wallet to sign and broadcast. The in-wasm keypair never signs a purchase, and your external wallet’s key never enters the page.

If no browser wallet is injected, the buy/list controls report the wallet as unavailable; browsing still works.

The tabs

The pane opens on For sale — the names you can buy right now — and offers four filters:

• For sale (default) — live listings: every offer with no expiry, or whose expiry is still ahead. These are purchasable.
• Expired — listings past their binding window. Nothing sweeps expired listings on-chain (see the binding window), so they linger in the index; this tab is where they land, and they are no longer buyable.
• Sold — completed sales, newest first. This tab lazy-loads sale history from /v1/chain/sales the first time you open it.
• Participants — the opt-in campaign pool: wallets that published a discovery beacon advertising the topics they’ll accept paid mail on. Like Sold, it lazy-loads on first view.

The Participants tab

The first three tabs trade names; the Participants tab is a window onto the campaign pool — the people who have opted in to be reached, not the names for sale. A tag-filter box narrows the pool to wallets carrying every tag you enter (a logical AND); Apply re-pulls the list from the global /v1/chain/participants account-api route. Tags go by the same names the sithbit campaign --tag flag takes — interest.technology, region.apac, and so on, case-insensitive — and the filter also accepts raw bit positions, mixed freely in one comma-separated list (interest.technology,10). A name the vocabulary doesn’t know is reported as an error right in the pane, before anything is fetched. Each row shows a participant’s wallet address, its self-attested tags by name (a tag newer than the page’s vocabulary shows as its bit number rather than disappearing), and whether it advertises an off-chain detail profile.

Browsing the pool is a plain read; reaching the people in it is a separate, paid step — you send them bountied mail, most easily with the sithbit campaign tree. See Campaigns for the whole flow and what it costs.

Managing your own beacon

Below the pool list, a My beacon heading carries a single Manage my beacon button — disabled until a browser wallet is available, because authoring your beacon, like buying and listing, signs with your external wallet, never the in-wasm keypair. Clicking it connects the wallet, reads your own beacon from chain, and shows one of three states:

• Not opted in — a “not in the pool yet” prompt, six checkbox groups of tag pickers by name (interest / skill / age / region / language / role — the same 71-tag vocabulary the sithbit campaign --tag flag takes), an optional detail CID field, and a Publish beacon button. Publishing requires at least one tag picked.
• Opted in — your published tags by name, above the same form pre-seeded from your chain state, with Update beacon, Disable, and Close beacon buttons.
• Disabled — a clear notice that your beacon is disabled and advertises no tags, with Re-enable alongside Update and Close.

The detail CID field is paste-only: it takes a literal CID, mirroring the CLI’s --detail-cid — the page never encrypts or pins a profile for you (that is the CLI’s --profile-file path). And like the CLI, an update is a wholesale replacement: the picked tags and the pasted CID replace whatever the beacon carried, so an empty CID field clears a published one.

Disable is a convention of this pane, not a chain state. Disabling publishes an update carrying no tags: the beacon account and its rent stay on-chain, but because a pool search must match at least one tag, a tag-less beacon drops out of every tag search. The pane remembers the tags you disabled locally in your browser, per wallet, so Re-enable restores exactly the set you had — the chain never stores that remembered set, so a different browser or a cleared profile has nothing to restore and says so; pick your tags again and Update instead. Close is the full opt-out: it closes the beacon account and refunds its rent to your wallet.

Success, pending-signature, and error feedback share the pane’s existing status lines, exactly as a buy or a listing does.

Each For sale row shows the name, whether it is an alias or a domain, and the asking price in SOL, with a Buy button. A successful buy refreshes the index and shows the transaction signature.

Listing your own name

The List for sale form takes the kind (alias or domain), the name, and an asking price in SOL. It connects your external wallet — which must be the name’s current holder/authority — signs the listing transaction, and refreshes the index so your new offer appears under For sale. Listings default to the program’s 30-day binding window; the CLI’s alias sell / domain sell let you set a different --expires-in.

A marketplace listing names nobody: whoever pays first wins. To hand a name to one specific recipient for a fee, use the escrowed alias transfer or domain transfer offer instead; for an ascending-bid sale, see Auction an alias.

The standalone page

Besides the panes built into every client, the marketplace has a standalone page of its own, served by your operator at a URL they choose.

The standalone shell asks you to import a Solana keypair on first run: that keypair unlocks the browse JWT only. Buying and listing still use your separate Phantom/Ledger wallet, which connects on demand from the pane. (The in-client panes reuse whichever wallet already logged that client in, so they skip this step.)

Operators: building and mounting that page is Serving the browser clients.

Honest notes

• Purchases are public. The buyer’s wallet, the asking price, and the winning transaction all live on-chain — an observer can see who bought which name and for how much. This is inherent to a public ledger; see What’s public and private.
• Sale history comes from an indexer, not the chain directly. The Sold tab is only as complete and current as the operator’s alias/marketplace indexer; an operator who disables it leaves the tab empty.
• [chain] is required. All three routes the pane uses answer 503 without account-api’s [chain] section configured, just like the other chain-backed panes.