Overview

Thru Wallet is an experimental Chrome extension for personal key management and basic account operations on Thru's native Layer 1 betanet. It is unofficial, self-custody, and deliberately narrower than a general dApp wallet.

Not production-ready. Not security-reviewed. Not affiliated with Unto Labs. Betanet testnet funds only.

Install

The packaged extension is listed on the Chrome Web Store:

• Listing: Thru Wallet
• Extension id: ocahgpmgfeapjnceaknkikanjikhjgok
• Listing version: 1.4.1, updated 2026-10-04, 272 KiB, five permissions — verified against the live page on 2026-10-04
• Same build as source release v1.4.1, merged as cee006e on 2026-10-03 and published to the store a day later
• Not verified: all 36 rows of docs/MANUAL_SMOKE_CHECKLIST.md are unticked — 95 individual checks, since most rows are run twice for popup and side panel
• Source: buildbyravi/thru-wallet-ext
• This site: buildbyravi/thru-wallet-web

Use the store unless you are auditing or rebuilding. The full steps live on the install page and in Installation.

What it is for

• Create, import, lock, and unlock a local vault.
• Hold multiple keyrings and accounts.
• Read a THRU balance with raw units still visible.
• Create an on-chain account, claim a faucet where the network supports one, and send native THRU after review.
• Show a receive address and QR, plus decoded history when the shape is known.
• Read token balances and prepare token transfers on official program bindings, with live questions still open.

What it is not

Thru's own wallet architecture is an embedded, iframe-hosted wallet. There is no published standard yet for third-party extensions to plug into dApps built with Thru's SDKs. This project does not inject window.thru. Rabby, MetaMask, Phantom, and Keplr are UX references only. Thru is not EVM.

Three artifacts, not one

The first two columns finally agree. The betanet work merged on 2026-10-03 as v1.4.1 and was published to the store on 2026-10-04 — package 1.4.0 had been submitted the day before and was never published, which is why the release carries the 1.4.1 number. Submission, merge, and publication stayed three separate events, and this site only moved its listing facts when the public page moved.

What the agreement does not include is verification: 0 of 36 rows in docs/MANUAL_SMOKE_CHECKLIST.md are ticked — 95 individual checks counting popup and side panel separately. The package reached users one day after merge on 20 automated suites and no recorded manual run.

It also does not last. Contract v16 is written on the stacked, mergeable chain #17 → #18: it retires tx.send and token.transfer, taking 83 methods down to 81, and rewrites the status document to match. The chain does not bump the package number, so merging it as-is would leave main describing contract v16 under the same 1.4.1 string the store serves as contract v15.

Shared by all three: 14 routes, one popup stack, a 400px popup, 0 DOM sinks with the ratchet closed, and a vault built on PBKDF2-SHA256 at 600,000 rounds then AES-256-GCM.

Say which artifact you mean. "Thru Wallet supports betanet" is true of the package Chrome installs today and of the source; "Thru Wallet is verified on betanet" is true of neither.

The chain moved underneath the store build

The extension repository records a managed-genesis reset on 2026-09-26: the single-node alphanet is gone, betanet is Thru's final testnet before mainnet, and the old reverse-engineered program addresses no longer exist on-chain. The published 1.4.1 package points at the betanet RPC and nothing else: connect-src allows one origin. The alphanet-era 1.2.0 package left the install path on 2026-10-04. Building from main at cee006e gets you the same wallet the store serves.