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.

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. Each row shows a participant’s wallet address, its self-attested tags, 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.

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.

Building and serving the standalone page

cd webclients/marketplace
./build.sh    # wasm-pack build + stages shared/ into staging/

staging/ is the deployable bundle, served same-origin from account-api exactly like the webmail app — no CORS, the API base URL is the page’s own origin:

[static]
route = "/marketplace"
root = "webclients/marketplace/staging"

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.)

CSP note. The standalone page bridges the wire transaction to the format the external wallet signs with the vendored codec-only @solana/kit bundle (shared/lib/kit-codec.esm.js) — served from the same origin as the page, so account-api’s script-src needs no extra origins.

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.