Theseus Navigator Whitepaper

Abstract

Theseus Navigator is a desktop web browser in which a site's name is a record on the Bitcoin Cash blockchain, not an entry in a registrar's database. The browser resolves those names itself, from several independent sources at once, and fetches the content from decentralized storage or from any server the owner points at. No registrar can seize a name, no resolver sits between the user and the ledger for a name lookup, and the browser ships its privacy protections on by default, request blocking, consent-banner handling, DNS over HTTPS and Global Privacy Control, with anti-fingerprinting controls and a bundled Tor route one click away.

This paper describes the name system Theseus reads (the Bitcoin Cash Name Registry), how the browser turns a name into content without trusting any single party, how content and DNS-style records are published and verified, the protections and the wallet built into the browser, the extension model, and the companion tools that bring the same names to every other browser and to Android. It closes with the security model as it stands at the time of writing, and with the open questions.

Theseus is built by Silent Mode on Electron, currently for Windows, and is free software distributed with published checksums from two mirrors, one on ordinary DNS and one served over the name system itself.

The problem

A web address is only as free as the weakest party between the user and the page, and today that chain has four parties in it who can each break the link without the owner's consent.

• The registrar and the registry. The record of who holds a domain sits in a company's database, behind a registrar, a registry and their jurisdictions. It can be suspended on a complaint, seized by court order, lost to a missed renewal, or hijacked by whoever talks their way past a support desk. Whether a name is bought outright or leased for a term is not the problem; who keeps the record, and how many parties stand between the holder and it, is.
• The resolver. Whichever DNS resolver a device uses sees every name it looks up and can answer with something else. Hostile networks do exactly that: one pattern seen in the field returns A-typed data for AAAA queries, which breaks the operating system's own lookups until the device switches to an encrypted resolver.
• The certificate authority. HTTPS trust rests on a few hundred authorities, any one of which can issue a certificate for any name. The user cannot tell an issued certificate from a mis-issued one.
• The host and the CDN. A page lives on a server someone can be ordered to switch off, behind a content network that can decline to serve it.

On top of that, the browser itself has become the instrument of tracking: third-party requests on almost every page, consent banners engineered to be accepted, fingerprinting through timezone, language, fonts and hardware, and a real IP address that follows the user everywhere.

A browser that wants to fix this cannot bolt a plug-in onto the existing stack. The name layer has to be replaced by something no single party controls, the resolution has to happen inside the browser from sources the browser can check against each other, content has to be addressable without a host that can be switched off, and the privacy defaults have to be on from the first launch. Theseus is built around those four requirements, and the rest of this paper describes how each one is met and where the limits still are.

Names on Bitcoin Cash

A name in this system is a digital certificate record on the Bitcoin Cash blockchain: whoever holds the certificate holds the name, and the chain is the only registry. The record is kept on the chain instead of at a company, which removes the registrar, the registry and the resolver from between the holder and the name. The protocol is called BNS1 after its payload prefix; the name system as a whole is referred to as the Bitcoin Cash Name Registry, BCNR.

Registration. One transaction does everything. It mints an immutable digital certificate whose commitment is the name itself, writes a single OP_RETURN payload of at most 200 bytes, BNS1 followed by JSON with the operation, the name and its records, and pays 600 satoshis of dust to a fixed beacon address. The beacon is what makes the registry discoverable: any client can ask an ordinary Electrum server for the beacon's history and obtain every registration ever made, without an indexer. The certificate holds 1,000 satoshis and the transaction's first output is change, placed there so the next registration has a fresh coin at output zero, which a new certificate category requires.

Four operations exist: REG and UPD for names, TREG and TUPD for top-level domains. An update spends the certificate and re-issues it, so the same transaction proves ownership and carries the new records; the address that receives the certificate becomes the owner of record. A transfer is an update whose only change is the recipient.

Records are short keys in the payload.

Two names carry system records: electrum.bch lists Electrum servers (el), and tlds.bch carries the legacy top-level list that clients still read as the native set.

Validity is computed, not declared. Every client sorts the beacon's history by height and transaction, orders it so no transaction is indexed before one it spends from, and applies two rules: the first valid registration of a name wins, and an update counts only if one of its outputs carries the name's own certificate category. Uniqueness is therefore indexer policy rather than chain consensus: clients that apply the same rules to the same history reach the same index. The protocol has no expiry of its own. Whether names under a top-level domain are bought outright or leased, per year, per two years or not at all, is a term for that domain's certificate holder to set; how such a term is enforced is an open question below, and no name expires today. Front-running of a pending registration is possible today; a commit-reveal scheme is specified but not implemented.

Top-level domains are digital certificates of the same shape on a second beacon. A TLD's records set its policy: open, cosign, covenant or frozen; a minimum label length; reserved labels; a price the owner sets for names under it; and hidden, which takes the TLD off public listings and restricts registration to the owner. A registration under a cosign or hidden TLD is valid only if the transaction also spends and re-issues the TLD's certificate, so the TLD owner countersigns every name under it; the gateway keeps a seven-day queue of co-sign requests and signs nothing itself. Every policy change is a TUPD kept on a timeline, so a name is judged by the policy in force at its own height. Of these fields, every client's indexer enforces co-signing and hidden; the minimum length, reserved labels and the frozen and covenant policies are enforced by the registrar when a name is registered, not by every client.

Ownership can be sold in one transaction. A seller signs the certificate input and a payout output with the SIGHASH_SINGLE | ANYONECANPAY flag; anyone can complete the sale by adding payment and receiving the certificate, and cancelling is spending the certificate once. USD-pegged listings move the certificate into a covenant that pays out target / price, clamped between a floor and a ceiling, against an oracle quote the gateway signs from the median of several public price sources.

Resolution: from a name to content

Theseus treats every dotted host as a Bitcoin Cash name first and falls back to ordinary DNS only when the registry has no record for it. The registry does not privilege ICANN: example.com is looked up on the chain before it is looked up in DNS, and only localhost, IP literals and single-label hosts skip the chain. What the browser resolves against is not a remote service but a local index of the whole registry, rebuilt from sources that can be checked against each other.

Every source writes the same index, so the browser never depends on one of them; the name's own record then decides where the bytes come from.

Four sources feed the index. They start in a fixed order at launch and none of them is trusted alone.

1. Bundled snapshot. Every build ships a snapshot of the registry's beacon history. The browser prefers a newer snapshot it has saved itself under the profile. Either way the snapshot is a floor: the index is marked stale the moment it loads, so the live sources overwrite it.
2. Delta poll. Every 30 seconds the browser opens an Electrum connection, asks for the beacon's transaction history, fetches only the transactions it has not seen, and rebuilds the index. The result is written back as the profile's snapshot, so the next launch starts where this one ended.
3. Full walk. If no snapshot can be read, the browser walks the beacon's entire history before answering.
4. Sia snapshot. A published name list is fetched from decentralized storage as a further floor. Today the poll's own snapshot overwrites it as soon as an Electrum server answers, so it matters only when none does.

The Electrum servers come from a seed list compiled into the resolver and from the chain itself: the electrum.bch name carries an el record listing servers, refreshed at most every 30 minutes. The browser connects by hostname first and, if that fails, by the server's pinned IP with the hostname as the TLS name, which defeats DNS interference against the resolver's own transport. With Tor on, these connections go through the SOCKS proxy.

Reducing history to an index is deterministic, so clients that see the same history compute the same index: the first valid registration of a name wins, and an update is honoured only when the transaction carries a proof output of the name's own certificate category, that is, only when the current holder signed it. A client that reaches the same history therefore computes the same index as every other client, with no resolver in between.

Serving the name. Once a host has an entry, the browser loads it through its own bns:// scheme and chooses the source in this order:

1. A subdomain rule set by the owner (block or redirect), fetched from the gateway for hosts served directly.
2. A subdomain with an ip record is served from that IP.
3. Inline HTML stored on the chain (h), for the root path only.
4. A Sia site (s3), fetched through the public gateway's /bns/ mount, which holds the storage keys so the browser never does.
5. A server address (ip), fetched directly. If the name also carries a tls record, the connection is pinned: the server certificate's SHA-256 fingerprint must equal the record or the socket is dropped, with no fallback to plain HTTP.
6. A proxied upstream (p), reverse-proxied by the browser with any path prefix kept.
7. A redirect (u).

On-chain records are authoritative for the name itself; a signed subdomain rule can block or redirect a subdomain the on-chain record would otherwise serve. Records for a name are fetched only after the name is known to be registered, so ordinary DNS hosts the user visits are never sent to the gateway.

Collisions. A name that exists both on the chain and in ICANN's root is a collision. The default policy is chain first; the user can choose ICANN first, or ask each time, in which case an in-tab page offers both and can remember the choice per name or per top-level domain. Names under the registry's native top-level domains, listed on the chain by the tlds.bch name, are never treated as collisions.

Limits at the time of writing. A lookup miss on an index older than eight seconds waits for one poll before answering, so an unknown host can pause a navigation by the length of one Electrum round trip. History is taken from one server at a time; the resolver library can union several servers but the browser does not yet use that path. The profile snapshot is validated by shape only, not by signature. And the transactions an Electrum server returns are taken in their decoded form, token data included, without a check against the raw transaction or a block header, so a lying server could present a registration that is not on the chain.

Content and records

A name points at content in one of five ways, and the two that matter most, a site on Sia and a pinned server, need no host that can be switched off and no certificate authority that can be fooled.

Sites on Sia. The owner uploads a folder to the Sia network through an S3-compatible endpoint and puts its path in the name's s3 record. The public gateway serves it at navigate.st/bns/<name>/, with the usual conveniences of a static host: index.html for folders, /about for about.html, and a single-page fallback to the root. Theseus reads the same mount through its bns:// scheme, so the storage keys live on the gateway and never in the browser. Sirius Studio and Sirius Press publish straight into that folder through a gateway API where every upload is signed over the name, the path, the file's hash and a timestamp, and the signature must recover to the current holder of the certificate. No one else can write there through the gateway; the gateway itself holds the storage keys, which is the trust discussed under Security model.

Pinned servers. An ip record names a server; a tls record beside it names the SHA-256 fingerprint of that server's certificate. The browser connects directly, ignores the certificate chain, and accepts the connection only if the fingerprint matches. The owner's own key is the trust anchor, published on the chain they control, so no authority can issue a certificate the browser would accept for that name. If the fingerprint does not match, the socket is dropped and there is no fallback to plain HTTP.

Inline, proxied and redirected. A page small enough to fit the payload can live on the chain itself (h), served at the root path only. A p record makes the gateway or the browser reverse-proxy an upstream URL, keeping the path. A u record redirects. On the apex the order is inline, then Sia, then IP, then proxy, then redirect; for a subdomain an ip record wins first and a proxy is not inherited.

Signed records without a transaction. Everything a DNS zone would carry lives in a file the owner signs and stores beside the site: _records.json. It carries a sequence number, a timestamp and A, AAAA, MX, TXT, CNAME, NS, CAA and SRV records, canonicalised with sorted keys and signed with the same key that holds the name. The gateway verifies the signature against the current certificate holder on every read, rejects a sequence number that goes backwards, and answers GET /api/dns/<name> with the verified records and a 30-second cache. Publishing an update is a signed POST, no chain transaction and no fee. Version 2 adds a hosts map: each subdomain can have its own folder in the bucket, a redirect, a block, or its own record set, with a wildcard entry and a depth of up to eight labels. A block beats a redirect beats a folder, and an exact entry beats the wildcard.

On-chain records are authoritative for content, and the signed records extend them with everything DNS-shaped. Signed A records are not yet used for serving: the manifest lives beside a Sia site, and a name with a Sia site is served from it. The on-chain tls pin applies to whatever is served from an address. Theseus fetches these records only for names it already knows are registered, so ordinary hosts the user visits are never revealed to the gateway, and a page is not held for the fetch; only a subdomain served from an IP or from inline HTML waits, up to three seconds, for its host rule.

Subdomain rules apply everywhere. The browser asks the gateway for a host's verified rule before serving a subdomain from an IP or from inline HTML, the two paths it serves without the gateway. A subdomain the owner has blocked or redirected therefore behaves the same whether the name is served from Sia or from the owner's server, and a subdomain served from Sia gains no round trip.

Certificates for other browsers. Theseus needs no certificate authority because it checks the pin itself. Other browsers do, which is what the system-wide resolver described later provides: a local root constrained to the registry's top-level domains that mints a leaf per name on the user's own machine.

Privacy and protections

The protections below are on from the first launch unless the table says otherwise. The table gives the mechanism and the default; the paragraphs after it give the detail that matters for a threat model.

Shield runs inside the browser's one request hook. The main process owns the single onBeforeRequest listener for the session and asks each registered filter for a verdict, so add-ons cannot install competing hooks. The engine is Ghostery's adblocker library with network filters only; cosmetic filtering is not yet applied. A blocked request is cancelled before it leaves the machine. Top-level navigations are never blocked, so a page always loads even when its trackers do not.

Cookie Pop-ups runs in the isolated world of every page and answers the consent dialog the way a careful user would, rejecting everything but the essentials. It never sends anything anywhere; the rule set ships with the browser.

DNS over HTTPS has three modes. Automatic uses the encrypted resolver and falls back to the system resolver when it is unreachable. Increased protection never falls back, so a network that blocks the resolver blocks browsing rather than downgrading it. Off uses the system resolver. Providers are Quad9, Cloudflare, Mullvad, AdGuard, or any HTTPS resolver URL. This covers ordinary DNS hosts; a chain name's lookup never touches DNS, though fetching its content through the gateway does. With Tor on, hostnames resolve at the exit, not locally.

Identity. Theseus does not announce itself. The user agent drops the Electron and application tokens, the client-hint brands and their order are computed the way Chromium computes them, and both the JavaScript surface and the request headers agree. This is what keeps commercial bot filters from rejecting the browser. A window.chrome shim fills the properties sites test for.

Tor is bundled, not downloaded. One click starts the bundled binary with its own data directory and geoip files and points the session's proxy at it; the Electrum connections, Sia fetches and pinned IP fetches follow the same proxy, and WebRTC is restricted to proxied paths so no UDP leaves directly. Whether Tor is on is not remembered across launches; Tor's own data directory is. The browser is explicit that this buys IP privacy, not anonymity: it does not change the fingerprinting surface the way Tor Browser does.

VPN is an add-on rather than a core feature. It runs a pinned build of sing-box speaking VLESS over REALITY with a Chrome TLS fingerprint, verifies the binary's hash before every start, and can use Silent Mode exits, a pasted vless:// URL or a subscription URL. Exits with keys are not yet issued at the time of writing.

What is not done. There is no referrer-policy override, no Do Not Track header, and no third-party cookie blocking beyond what clearing on quit achieves. Several main-process fetches use the process's plain HTTP client and do not follow the Tor proxy: gateway record lookups, the Sia snapshot pull, proxied p upstreams, the update checks, add-on channel and package downloads, the Shield list refresh, the community catalogue and the home cards. Fingerprinting defences are opt-in emulation rather than a uniform fingerprint.

Wallet and dapps

Aegis is the wallet built into Theseus as a plug-in. It holds keys for seven chains from one recovery phrase, keeps key material in memory only and re-derives it from the vault on every launch, and lets pages transact through injected providers that can do nothing without an approval drawn by the browser itself.

Key material. The recovery phrase becomes a 64-byte seed the standard way, and that seed is used only to derive per-purpose roots with HKDF, one for wallets and one for messaging. The vault, which is the same vault the password manager uses, stores only those roots, encrypted with 200,000 rounds of PBKDF2 and AES-GCM; the seed itself is never written to disk. Each wallet then derives its own 32-byte root from the purpose root with a fixed HKDF label, and each chain derives its keys from that. Changing any of these labels would orphan funds, so they are frozen. Imported wallets live in a second file under the same password with a different salt, so a leaked purpose root yields none of their keys. The host scopes derivation to the plug-in's own identifier and to legacy identifiers its manifest declares it absorbs; that absorb list is not yet gated, which the roadmap covers.

Unlocking. The vault unlocks with the master password, entered in the wallet's panel and handed to the main process for the unlock. Two opt-in conveniences keep a wrapped copy of it on disk: stay-signed-in encrypts it under the operating system's own store, with a 15-minute idle lock and a lock on close by default, and a quick-access PIN wraps it under a PBKDF2-derived key.

The page bridge. On .x sites Aegis injects window.bitcoincash with three calls: get an address, sign and send, sign a message. On every HTTPS page it injects an EIP-1193 window.ethereum provider (announced through EIP-6963 as st.silentmode.aegis), a window.solana provider, and the Tron provider surface, all speaking to the isolated world over tagged messages. Nothing injected can sign, read a balance or read an address on its own.

Approval. Every request from a page lands in an approval sheet the browser draws in its own view, never in the page: it names the plug-in and the requesting origin, one request at a time per origin, with focus on Cancel so Enter never approves a spend by accident. Permissions are remembered per origin: address access can be granted once, and a Bitcoin Cash spending allowance of 0.001, 0.01 or 0.1 BCH lets small payments through without a prompt until it is used up.

Pairing. For wallet-to-app sessions Aegis speaks WizardConnect, the LGPL protocol used by Bitcoin Cash applications, with an explicit pairing approval; a page is scanned for a pairing URI only when the user asks, and only matching URIs come back. Price lookups are off until the user turns them on, so a fresh install contacts no oracle.

Limits at the time of writing. Siacoin needs a walletd endpoint the user provides, with a public explorer as read-only fallback. WalletConnect is not implemented. The wallet is ordinary JavaScript running with the browser's privileges, which is the trust model of every plug-in and is discussed under Security model.

Extensions and plug-ins

Theseus has its own add-on model rather than Chrome's, and it publishes community extensions the same way it publishes sites: signed by a name's owner and stored on Sia, with the browser checking the signature against its own copy of the registry.

The host. An add-on is a folder with a manifest and a main script. The manifest declares an identifier, a version, a category (extension by default, or plug-in for wallets and other trusted components), and the capabilities it needs. Eleven capabilities exist, each unlocking one API:

Unknown capabilities grant nothing. Storage, host module imports and messaging need no capability. Page scripts run in the isolated world with a bridge that offers only the add-on's identifier, the page's origin, a message channel and an explicit evaluate-in-page call. Messages from a page are accepted only from origins the manifest lists, and messages from a panel only from the add-on's own files.

The trust model is stated plainly in the code: the main script is loaded into the browser's main process with full privileges, the same model as a developer-mode browser extension. Capabilities scope what the host offers; they are not a sandbox. Installing a community extension shows a prompt naming the publisher and the site that asked, and says so in those words.

The add-ons that ship with the browser. Aegis (wallet, plug-in), Shield, Cookie Pop-ups, a Word editor for .docx, a PDF editor, a screenshot tool with annotation, a translator using LibreTranslate or Google, a VPN client, and a notepad that serves as the reference add-on. Bundled add-ons cannot be removed, only turned off, and are re-seeded from the build only when the bundled version is newer than the installed one.

Updates are signed. Each add-on has an update channel on Sia, reached through the gateway. A channel entry names a version, a tarball, its SHA-256 and a signature; the browser accepts it if the operator's Ed25519 key signs it, or if the publisher's signature verifies as described below. The tarball's hash must match, the extracted manifest's identifier and version must match the entry, size caps apply (16 MB for the package, 128 KB for the manifest), and only versions newer than the installed one are taken. Updates are staged and promoted at the next launch, or in place for extensions on request; a wallet mid-session is never hot-swapped. There is one operator key today, and it can sign an update for any identifier; a channel entry names its publisher but is not yet pinned to the publisher the add-on was installed from. Both are on the roadmap to narrow.

Community publishing. A publisher who owns a name uploads a package to the gateway with two signatures from that name's key, one over the upload and one over the catalogue entry, both required to recover to the name's current certificate holder. An extension identifier belongs to the first name that publishes it, and versions must increase. When Theseus installs or updates a community extension, it recovers the signer of the entry and compares it with the owner it finds for that name in its own index, not the gateway's, so the gateway cannot substitute a publisher. The publish page on theseus.x does the signing in the page from a recovery phrase that never leaves it, and installs are one click from that site through a theseus://extensions/install/ link or a page-side bridge.

Plug-ins are the category for components that hold keys or route traffic: Aegis is one, and the system-wide resolver is managed from the same place. They are listed apart from extensions in Settings, their updates wait for a restart, and the toolbar chip that announces a ready update stays silent for them.

Beyond the browser

Theseus needs nothing installed on the machine to resolve names, but everything else on the machine does. Three companions extend the same registry to other browsers, to Android, and to the people who register and publish names. All of them share the resolver code with Theseus, so the same rules reduce the same history everywhere.

Ariadne's Thread is a Windows service that makes the registry visible to every application. Its installer adds one Name Resolution Policy Table rule per routable top-level domain, so only those names are sent to a local daemon and everything else keeps the system's own DNS; a full mode that repoints the adapters exists but is not the default. The daemon answers DNS on the loopback address, serves HTTP and HTTPS for names, and keeps its own index of the chain, taken from a published snapshot first and from an Electrum walk when that fails, refreshed every 30 seconds, with the gateway asked about a name it does not know. For HTTPS it holds a root certificate generated on the machine itself with a critical name-constraints extension limiting it to the registry's top-level domains and excluding every IP range, and it mints a two-year leaf per name on first request; the installer refuses to trust any root without those constraints, and the private key never leaves the machine. Names with an ip and tls record are reverse-proxied through the same fingerprint check Theseus applies. The list of top-level domains is synchronised every six hours from the registry's routable list minus every TLD delegated by IANA, so .com and its kind stay with ordinary DNS; when the list changes, the rules are adjusted and the root is rotated. A collision policy file is re-read every five seconds, so the browser's setting and the system's can agree. Theseus offers install, update, on and off from its Settings and checks the installer's hash before it runs.

Ariadne for Android is a tabbed browser for phones with the same resolution stack: a bundled index, a snapshot the gateway refreshes every ten minutes, an on-device Electrum walk with a 60-second cache, and a gateway fast path that races the trustless path. It claims the registry's routable top-level domains at start and refreshes them from the gateway. An optional system-wide mode runs a DNS-only VPN service on the device so other apps resolve names too; it tunnels nothing else. The package is signed with Silent Mode's own key, its certificate hash is published in the release manifest, and it is distributed from the download host rather than a store.

Sirius is the registrar and the publishing desk, reachable at sirius.x and mirrored on the ICANN site. Registration runs entirely in the page: a built-in wallet unlocked, created or imported there, or a WizardConnect pairing with a mobile wallet, builds the one transaction that mints the certificate and pays the fees. The dashboard manages every name and TLD the wallet holds: DNS records and subdomain rules through the signed manifest at no cost, content and hosting, redirects, transfers, marketplace listings in BCH or USD, TLD policy and the owner's share of each registration, and the co-sign queue for gated TLDs. Sirius Studio is a page builder on GrapesJS that publishes straight to the name's Sia folder through signed uploads and sets the s3 record with one transaction when needed; its optional assistant runs a small language model in the tab over WebGPU or against a local endpoint, and never executes model output. Sirius Press is a WordPress fork whose only change to core is 75 lines: accounts are Bitcoin Cash addresses, sign-in is a signed challenge, and every page is mirrored as static HTML to the name. The registrar speaks seven languages.

Hephaestus hosts the source. It is a Forgejo instance where the account is a Bitcoin Cash address and sign-in is a signed message through an OpenID Connect proxy, with repositories on the server and large files, attachments and packages on Sia. It answers on the ICANN name with a public certificate and on hephaestus.x with the project's own root.

The three resolvers read the chain themselves; the gateway is where bytes come from and where signed uploads land, and it reads the same chain to know who may write.

Security model

The design goal is that no single party between the user and a page can change what the page is. The table says who is trusted for what today; the paragraphs after it say what an attacker in each position can and cannot do.

A hostile network can block or delay but not redirect. It sees encrypted DNS to a chosen resolver, TLS to Electrum servers reached by pinned IP if hostnames fail, and, with Tor on, page traffic through Tor with the exceptions listed under Privacy. It cannot alter a name on the way through: the index is computed from history the browser fetches over TLS from servers it chose. It cannot forge a pinned site: the fingerprint is on the chain. It can still see which Electrum servers and which gateway the browser talks to when Tor is off.

A hostile Electrum server can lie by omission, returning a truncated history, which would make a recently registered name resolve as absent and fall through to ordinary DNS. It can also invent one: the browser takes the server's decoded transactions, token data included, without checking them against raw transactions or block headers. The defence today is thin, since the browser takes the first server that answers and the on-chain server list is consulted first; verifying decoded data against raw transactions and headers, and taking the union of several servers, are both on the roadmap.

A hostile gateway is the largest remaining trust. For Sia sites the browser takes the bytes from the gateway's mount and cannot verify them against the chain, because the site is not hashed on the chain. For signed DNS records the gateway does the verification and the browser trusts its answer. The gateway can therefore serve a substituted Sia site or a substituted A record to a browser, though not a substituted pinned site, and a substituted publisher for an extension still has to own a name in the browser's own index. Reducing this trust, by verifying manifests in the browser and by hashing site roots on the chain, is the main item on the roadmap.

A hostile certificate authority gains nothing against a pinned name and nothing against a Sia site reached through the gateway's own certificate, which is itself an ordinary TLS endpoint. For names without a tls record that are served from an IP, the connection is plain HTTP and offers no protection at all; owners are expected to set the pin.

A hostile page sees a browser shaped like the Chromium inside it, without the Electron tokens, with hardware and media APIs denied, and with wallet providers that can do nothing without an approval drawn outside the page. It can request fullscreen, notifications and the other benign permissions. It cannot reach the registry APIs beyond read-only lookups, and while it can see that a wallet provider is present, as with any wallet extension, it learns nothing about wallets or addresses until the user approves.

A hostile add-on is the user's own decision. Add-on code runs in the main process with the browser's privileges, and the capabilities scope what the host offers rather than what the code can reach. Bundled add-ons come from the build; community extensions come from a named publisher whose ownership the browser checks; anything else is a folder the user placed there. There is no sandbox, and this paper does not claim one.

A hostile update to the browser would have to come from the ICANN mirror over TLS, since the hash the browser checks is fetched from the same place as the file. A publisher signature on the manifest, verified against a key in the build, would close that; add-on updates already have it.

What the chain does not enforce. Name uniqueness and the co-sign rule are indexer rules, the other top-level-domain policies are registrar rules, and none are consensus rules of Bitcoin Cash. The co-sign rule is applied on the live walk and not yet on the snapshot path, which the roadmap covers. A name under a top-level domain nobody has registered still indexes today because the existence gate is off by default. There is no recovery for a lost key and no authority that can return a name.

Distribution and updates

Theseus ships as an unsigned Windows installer and a portable executable, with SHA-256 checksums published beside them, from two mirrors: one reached through ordinary DNS and one through the name system, which today run on the same server and differ in how they are reached rather than where they live.

• silentmode.st on ordinary DNS, with stable links at dl.silentmode.st/latest/ that redirect to the current versioned file. This is the mirror the updater reads.
• silentmode.bch on the name system, served from Sia through the gateway. A systemd timer mirrors the ICANN site into the Sia bucket every five minutes, so both surfaces carry the same release notes and hashes, and a user whose names resolve can fetch the browser from the name system's own surface.

The release page, the manifest and the theseus.x site all print the same two hashes, so a downloaded file can be checked against three surfaces.

The updater checks the release manifest at launch and every six hours, downloads the installer silently in the background, and refuses to install anything whose SHA-256 does not match the manifest: a mismatch or a missing hash deletes the file, and the toolbar chip falls back to offering a manual download. Only on success does the chip offer to install. Clicking it quits the browser and hands over to a detached helper script that waits for the process to exit, runs the installer silently, checks that the application archive is present afterwards and reruns the installer once if it is not, then deletes itself. That last step exists because an installer killed mid-update once left an install with no application archive.

The manifest travels over HTTPS from the ICANN mirror; it is not yet signed by a publisher key, so the trust in an update rests on TLS to that host. A signed manifest is on the roadmap.

Add-ons update separately. Bundled add-ons are seeded into the profile at first launch and re-seeded only when the build carries a newer one. Updates for them and for community extensions arrive over their own channel on Sia, are verified against the operator's key or a publisher's name key, staged, and promoted at the next launch, or in place for extensions on request; a four-hourly check and a toolbar chip cover the case where the user never restarts.

Companion downloads. The same manifest lists Ariadne's Thread for Windows and Ariadne for Android, and Theseus reads it to offer the system-wide resolver's install or update from Settings, with the same hash check before the installer runs.

Roadmap and open questions

The system works end to end today; the items below are what stands between that and a system a stranger can rely on, in the order they matter.

1. Less trust in the gateway. Verify signed record manifests inside the browser instead of taking the gateway's word, and put a content hash for a Sia site on the chain so the bytes can be checked. Until then the gateway can substitute a Sia site or a DNS answer.
2. Front-running. The commit-reveal scheme for registrations is specified and not implemented.
3. Enforcement gates. Turn on the top-level-domain existence check by default so names under unregistered TLDs stop indexing, and bring the co-sign rule to the snapshot path and to Android.
4. A signed release manifest for browser updates, checked against a key in the build, so an update no longer rests on TLS to one host.
5. Per-identifier update keys for add-ons, so the single operator key cannot sign an update for any extension, and each installed add-on pinned to the publisher it came from, with the vault's absorb list gated the same way.
6. Resolution robustness. Verify the transactions Electrum servers return against raw transactions and block headers, use the union of several servers' history rather than one, and stop a lookup miss from waiting on a poll.
7. Tor coverage for the remaining main-process fetches: gateway record lookups, the Sia snapshot pull, proxied upstreams and the update check.
8. Protections still missing: an HTTPS-only mode, cosmetic filtering in Shield, a referrer policy, and third-party cookie controls.
9. Packaging. macOS and Linux builds, and a code-signing arrangement that does not depend on a certificate authority's approval.

Open questions the design has not settled:

• Whether name uniqueness and TLD policy should stay indexer rules or become covenant-enforced on the chain, which is the difference between "every honest client agrees" and "no client can disagree".
• How a top-level domain holder's rental terms, yearly, two-yearly or none, should be enforced on the chain rather than by the registrar, and what becomes of an abandoned name under a domain with no rent.
• Whether a sandbox for add-ons is worth the loss of capability, given that the wallet itself is an add-on.

Glossary and references

Public surfaces

• Theseus: theseus.x through the gateway, silentmode.st/theseus on ICANN DNS
• Downloads and release manifest: dl.silentmode.st, mirrored at silentmode.bch
• Registrar: sirius.x
• Source: code.silentmode.st/silentmode/theseus
• Gateway API root: navigate.st/api/tlds, /api/registry, /api/dns/<name>, /api/records/<name>, /api/market, /api/cosign, /api/site, /api/ext

Design documents in the repository (paths under the Silent Mode monorepo): Decentralized.DNS/PROTOCOL.md, Decentralized.DNS/DESIGN-tld-registry.md, Decentralized.DNS/DESIGN-signed-records-manifest.md, Decentralized.DNS/INTEGRATION-signed-records-clients.md, Argus/DESIGN-collision-modes.md, TheseusNavigator/docs/ADDON-UPDATES.md, Argus/src/lib/resolver-web.js (the reduction rules), Argus/src/lib/manifest.js (manifest validity), Argus/src/lib/register-tx.js (transaction shapes).

Licensing. Theseus Navigator, Ariadne's Thread and Ariadne for Android are published under the Mozilla Public License 2.0, the file-level copyleft Firefox and Brave use: changes to the project's own files stay open, and anything may be built on the browser. The resolver, gateway and protocol libraries are under the Apache License 2.0, so that other implementations of the registry can reuse them freely; the protocol documents and this paper are under Creative Commons Attribution 4.0. Sirius Press is GPL-2.0-or-later, as WordPress requires. Each build ships a third-party notices file: Chromium via Electron, Tor, DuckDuckGo autoconsent and the Ghostery adblocker (MPL-2.0), EasyList and EasyPrivacy, pdf.js, pdf-lib, mammoth, WizardConnect (LGPL-3.0-or-later), and the sing-box binary the VPN add-on fetches (GPL-3.0-or-later), whose complete source is published beside the binary. The project's names and marks are reserved and not covered by any of these licenses, so a fork must ship under its own name. The brand kits published at theseus.x/brand and sirius.x/brand carry the same note: their files may be used to refer to the projects, for example on a page that integrates with them, never as another product's mark.

All facts in this paper were read from the source tree and the live surfaces on 2026-10-01. The software moves faster than a paper; the repository and the release notes are the record of what has changed since.