Sirius.X docs

The TLD registry

Every BCNR name lives under a top-level domain whose certificate is itself a first-class token on the Bitcoin Cash chain — an NFT with the TLD label as its commitment, paying dust to a dedicated TLD-registry beacon. That certificate is the on-chain proof the TLD exists, and once enforcement ships, it is what makes any second-level name under it valid to conforming resolvers.

Fourteen public TLDs on chipnet today (2026-08-29): bch p2p bit nav test x asm neo gt sc sia dex cex nt. The current list and per-TLD categories are at silentmode.st/tlds/.

Register a name — end to end

The buyer's certificate mints straight to a wallet they control, in one transaction that also publishes the initial records and pays the beacon. Nobody including the operator can take the name back — the covenant work in progress adds an expiry / reclaim clock but does not change who controls the key.

1. Search a label across every TLD. The registrar fans out to every TLD in the registry in parallel and shows available / taken per row. Available names appear first.
2. Create or connect a wallet. Built-in browser wallet (PBKDF2 → AES-GCM in localStorage) or WizardConnect to Cashonize / Paytaca — both mint to the buyer's own key.
3. Confirm the price. Miner fee + beacon dust + certificate dust + service fee. Chipnet placeholder is 10,000 sat; real pricing is a mainnet decision.
4. The certificate lands in your wallet. The name resolves the moment the transaction confirms. Records can be set or changed later — only your key can sign a UPD.

Records & hosting

A registered name carries a small JSON records object. Every record is optional and multiple can coexist. Priority order the gateway uses: h (inline HTML) → s3 (Sia bucket key) → ip (host header served by an IP) → u (redirect).

Subdomains inherit from their parent with a slight priority tweak: for a subdomain query, ip beats s3 (Host-header semantics). Full rule is in Argus/src/lib/record-picker.js.

Free edits — signed off-chain records

The on-chain records above (h, s3, ip, u, tls, np, el) cost a chain transaction to change and are capped at 200 bytes of OP_RETURN. For DNS-style records (A / AAAA / MX / TXT / CNAME / NS) and any records you edit often, Sirius.X uses a companion mechanism: a signed off-chain manifest that costs nothing per change and has no size cap.

The chain says who owns the name. A signed blob says what the records are. Resolvers verify both. No third party is trusted for records: the manifest is signed by the same key that holds the on-chain NFT certificate, so an operator (or Sia farmer, or anyone else in the middle) can't rewrite records without breaking the signature.

How the manifest is verified

1. Resolver reads the name's chain record, follows records.s3 to the Sia bucket, fetches _records.json.
2. Signature check — recovers the signing pubkey from the manifest's sig field, derives the CashAddress, compares to the current NFT-holder address from the chain. Mismatch = reject.
3. Replay check — the manifest carries a monotonic seq number. Resolvers cache the highest seen and reject anything less-or-equal. An old signed blob can't be re-served.
4. Fall-back — if the manifest is missing, invalid, or its signature doesn't match, the resolver silently falls back to the on-chain records. Signed records never override a name; they extend it.

The manifest shape

{
  "v":    1,
  "name": "bitcoin.cash",
  "seq":  42,
  "updated_at": "2026-09-15T00:00:00Z",
  "dns": {
    "A":     ["1.2.3.4"],
    "AAAA":  ["2001:db8::1"],
    "MX":    [{"pref": 10, "host": "mail.example.com"}],
    "TXT":   ["v=spf1 include:_spf.silentmode.st -all"],
    "CNAME": null,
    "NS":    []
  },
  "sig":  "<BCH message signature over sha256(canonical bytes)>"
}

Canonicalisation: sorted keys, no whitespace, null fields omitted. The signable bytes are the manifest with the sig field removed. Full spec: DESIGN-signed-records-manifest.md — signable byte order, seq-monotonicity rules, threat model, v2 roadmap.

Endpoints

The distinction between /api/records/<name> and /api/dns/<name> is deliberate: the former is transparent (raw manifest as uploaded, including the signature so clients can re-verify), the latter is opinionated (only the verified DNS records, with the gateway having done the sig + seq work). Bridges and shims should use /api/dns/; wallets and tools that want to see the full signed blob should use /api/records/.

A name needs records.s3 set on chain first — without a storage pointer, the manifest has nowhere to live. Portal and CLI both refuse to publish a manifest until s3 is present.

Host your name

The end-to-end recipe for putting a static site under a BCNR name. Chipnet today, mainnet later — the shape is the same. Three ways to host, most people combine two of them (Sia + VPS mirror) so the site keeps serving if either mirror goes down.

Pattern A — Sia only

Simplest. Site lives on the Sia storage network, name's s3 record points at the bucket key, gateways (navigate.st, silentmode.st, any BCNR-aware browser) fetch it on demand. Same pattern silentmode.bch uses.

# From a checkout with sia-s3.json credentials:
node Argus/src/lib/sia-upload.js ./my-site bns/myname/

# Set the chain record (once). Note the trailing slash — enables auto-index
# so /myname/ serves myname/index.html and /myname/about/ serves .../about/index.html.
node Argus/src/update.js myname.x '{"s3":"bns/myname/"}'

Bucket-path convention: bns/<label>/ (no TLD; the label is unique enough within our Sia namespace and keeps game.x + game.bch from colliding). Files update by re-running sia-upload; the chain record only changes when the bucket path does.

Pattern B — Your own server (VPS + ip)

Point the name at an IP; every request goes directly to your box. Add a tls record with the SHA-256 of the leaf certificate so browsers verify the connection against the chain instead of the OS trust store.

# On your VPS: nginx serves your site over TLS. Then, on chain:
node Argus/src/update.js myname.x '{"ip":"1.2.3.4","tls":"<sha256-of-leaf-cert>"}'

Pattern C — Dual host (Sia primary, VPS mirror)

What Sirius.X itself uses. Sia is the chain-authoritative source (survives if the VPS is down); the VPS serves the same content on silentmode.st/<path> for users without a BCNR resolver installed. On the VPS side, extend the nginx vhost serving silentmode.st with a new location block that aliases straight from disk:

location /myname-x/ {
    alias /opt/silent-mode/site-myname-x/;
    index index.html;
    try_files $uri $uri/ =404;
}

Then rsync / scp your site tree to silentmode:/opt/silent-mode/site-myname-x/ and reload nginx. This gives you two URLs for the same content: https://silentmode.st/myname-x/ (VPS-direct) and the chain-authoritative https://myname.x/ via any BCNR resolver.

The dual-host recipe, end to end

This is the exact sequence Sirius.X itself uses on every publish. The chain record stays constant; only file contents change, so no per-publish UPD is needed.

1. Edit locally. Site source lives at site-myname-x/ in your working repo. Any static generator works (or plain HTML) — the deploy is content-agnostic.
2. Push VPS mirror (fast path). Serves at silentmode.st/myname-x/ within seconds. Users without a BCNR resolver hit this route.

   scp -r site-myname-x/* silentmode:/opt/silent-mode/site-myname-x/

3. Push Sia mirror (durable copy). Serves at sirius.x/ via any BCNR gateway. Survives VPS outage.

   node Argus/src/lib/sia-upload.js site-myname-x/ bns/myname/

4. Verify both. curl -so /dev/null -w "%{http_code}\n" https://silentmode.st/myname-x/ and curl -so /dev/null -w "%{http_code}\n" https://silentmode.st/bns/myname.x/ — both should return 200.

Auto-backup: one command, both mirrors

Wrap the two commands into a script so every publish reaches both mirrors without extra thought. This is exactly what a two-liner deploy hook looks like:

# scripts/deploy-myname-x.sh
#!/usr/bin/env bash
set -eu
SRC="$(dirname "$0")/../site-myname-x"
VPS_DEST="silentmode:/opt/silent-mode/site-myname-x/"
SIA_BUCKET="bns/myname/"

echo "→ VPS mirror"
scp -qr "$SRC"/. "$VPS_DEST"

echo "→ Sia mirror"
node "$(dirname "$0")/../Argus/src/lib/sia-upload.js" "$SRC" "$SIA_BUCKET"

echo "✓ deployed; verifying"
for url in "https://silentmode.st/myname-x/" "https://silentmode.st/bns/myname.x/"; do
  code=$(curl -so /dev/null -w '%{http_code}' "$url")
  printf '  %s → %s\n' "$url" "$code"
done

Wire it into git: chmod +x scripts/deploy-myname-x.sh, add a .git/hooks/post-commit that runs it if the site subtree changed, or invoke manually. Sia uploads that fail (network hiccup, quota) leave the VPS mirror ahead until the next run — same failure mode as any staged deploy.

Automate the reverse — VPS → Sia periodic backup

If your primary publish path is straight-to-VPS (nginx-direct, no Sia step per publish), a cron job can pull the VPS state and push to Sia on a schedule:

# /etc/cron.d/sirius-x-sia-backup (on the operator's VPS)
17 * * * * root  cd /opt/silent-mode && node Argus/src/lib/sia-upload.js \
    /opt/silent-mode/site-myname-x/ bns/myname/ >/var/log/sia-backup.log 2>&1

Runs hourly at :17 (offset from the top of the hour so it doesn't collide with everyone else's cron traffic). The tradeoff: up to an hour of drift between VPS and Sia after a publish — usually fine, since the chain record still resolves correctly either way and BCNR gateways cache Sia content.

Verify records changed correctly

node --input-type=module -e "
import { loadWallet } from './Argus/src/lib/wallet.js';
import { resolveName } from './Argus/src/lib/bns.js';
const w = await loadWallet('main');
console.log(await resolveName(w.provider, 'myname.x'));
process.exit(0);"

Resolver / gateway

Three paths, same chain data. Anyone can pick.

1. Local — Ariadne Resolver. A system-wide resolver that intercepts BCNR TLDs and answers them from the chain. Any browser you already use starts opening .bch URLs directly. Installs a local root CA for TLS. Download →
2. In-browser — Theseus Navigator. A Chromium build with the resolver baked in, plus an on-chain TLS trust anchor. No OS trust-store install; nothing modified globally. Download →
3. Public gateway — navigate.st. For anyone without the resolver installed: https://navigate.st/bns/<name>/ proxies through a hosted resolver. Same content, fewer guarantees — trust the gateway to fetch honestly, or run one of the first two.

Pricing (mainnet)

On mainnet the covenant enforces USD-denominated floors, tiered by TLD label length. This is what keeps someone from land-grabbing every ICANN TLD in one afternoon. TLD registration is one-time — a TLD is closer to a domain purchase than a lease.

On name registration under a TLD, the TLD's owner collects a share (fee_bps, default 5%, cap 50%). Chain-enforced when the TLD's policy is covenant; honour-system otherwise. Name registration is yearly and priced separately.

The TLD owner also sets what names under it sell for and whether the TLD is on or off, straight from the portal: a price record (flat USD per name, replaces the length tiers for every buyer) and a hidden record (1 makes it a private TLD: off the public list, nobody but the owner can register names under it — the owner still can from the portal, paying only the platform share — until it is switched back on). Both ride the same signed TUPD, so every client reads them from the chain; the owner keeps 90% of each sale.

Tracker & mirrors

A tracker publishes signed snapshots of the TLD registry to Sia and Nostr so downstream clients don't have to walk the chain themselves. The chain is authoritative; the tracker is speed. Every snapshot carries a root hash anyone can recompute locally — a lying mirror is caught by any recipient who bothers to check.

A conforming client falls through: (1) fetch snapshot from a mirror, (2) verify root, (3) if suspicious, walk the beacon and rebuild. All three yield the same list for any given block height.

Verify anything

You do not have to trust that sirius.x, silentmode.st, or navigate.st are serving honest content. Every name's certificate is on chain; every record is a signed on-chain payload; every host is checkable independently.

Confirm a specific name on chain

node --input-type=module -e "
import { loadWallet } from './Argus/src/lib/wallet.js';
import { resolveName } from './Argus/src/lib/bns.js';
const w = await loadWallet('main');
console.log(await resolveName(w.provider, 'sirius.x'));
process.exit(0);"

Fetch the operator-signed TLD snapshot from Nostr

Kind / d-tag

30078 / bns-tld-list

Pubkey (x-only, hex)

f2c925194c531c7c398017e35b2396df64a61a613aa5fadebdf1f4990f2267f4

Relays

wss://nos.lol · wss://relay.damus.io

Reach any site via more than one route

Same content should be served from at least two independent paths:

• Direct BCNR: https://<name>/ (requires local resolver + CA)
• Public gateway: https://navigate.st/bns/<name>/
• silentmode.st mirror: https://silentmode.st/bns/<name>/
• Direct from Sia (content-addressed) via the name's s3 record

Operator runbook

These docs describe what. The how — exact bash commands to register TLDs, mint names, update records, and deploy — is INSTRUCTIONS.md. Three ways to read it, in order of "how much do I already have installed":

1. Just read it in the browser Served straight from the docs directory: /sirius-x/docs/INSTRUCTIONS.md. Plain text; every browser renders it.
2. Clone the git remote git clone https://silentmode.st/sirius-x/repo/silent-mode.git — dumb-HTTP, no auth. Get the whole tree, browse offline, run the scripts.
3. Browse the Forgejo mirror Repo lives at code.silentmode.st/silentmode/sirius on the Silent Mode Hephaestus forge. Rendered runbook: docs/INSTRUCTIONS.md. Clone: git clone https://code.silentmode.st/silentmode/sirius.git — public, no auth.

The runbook covers CLI name registration, TLD-registry seeding, record updates, Sia upload, VPS deploy, tests, and the historically-costly gotchas.