How to run the wallet: the desktop app and what it lets you do

Most things called a “wallet” are a thin client: a pretty UI that asks a company’s server what your balance is and trusts the answer. The TensorCash desktop wallet is different. It’s bitcoin-qt — a full node with a GUI bolted on top — so the program holding your keys is the same program that syncs the chain, runs the P2P network, and re-checks blocks, signatures, scripts and the model registry itself. Your balances, assets and transactions are derived locally, not fetched from a backend you have to trust.

There’s one honest exception, and it’s the AI part. Re-running a model forward pass to check a block’s proof takes a GPU, so the node consults a verifier for that one check — and you choose who runs it: your own verifier next to the wallet, a verification service you trust, or a third-party provider. It’s one setting; see Wiring up verification below.

Either way, the wallet is where the whole protocol surfaces: issuing assets, registering AI models, and building contracts are all tabs in the same app, each backed by the node running inside it.

Get it: download, install, or build

Download the official binaries (Linux, Windows)

Releases are published on the project’s self-hosted forge — download the current release straight from git.tensorcash.org/tensorcash/tensorcash/releases: Windows installer and portable bundles plus Ubuntu and CentOS packages, for mainnet and testnet. These builds are unsigned, so your OS will warn on first launch — check the downloaded files against the release’s SHA256SUMS before running, and don’t download TensorCash binaries from anywhere else.

Or use AskTilly’s signed builds and WebWallet

Prefer a signed app, or macOS? AskTilly, an independent adopter that also runs a verification service for the community, offers signed macOS and Windows wallet builds and a browser WebWallet with client-side signing — your keys stay on your device. It’s independently operated, not run by the project, so the usual rule applies: do your own diligence.

Run it in a container (any platform with Docker)

The public node image has the same bitcoin-qt built in, behind a VNC console that stays off unless you give it a password:

docker run -d --name tensorcash-wallet \
  -e GUI_MODE=true \
  -e VNC_PASSWORD='pick-a-strong-one' \
  -p 127.0.0.1:5907:5907 \
  -v tensorcash-data:/data \
  docker.io/tensorcash/core-node:latest

Point any VNC client at localhost:5907 and you’re looking at the wallet, running on your own full node inside the container. Three rules keep this safe:

VNC is off by default. No VNC_PASSWORD, no VNC — the image refuses to start it without one, and there is no baked-in password. Pick a strong one.
Keep the 127.0.0.1 binding. For a box you reach over the network, tunnel in — ssh -L 5907:localhost:5907 you@host — and never publish port 5907 to the internet.
The tensorcash-data volume is your wallet. wallet.dat lives in it; back it up the way you’d back up any wallet, and don’t delete the volume with the container.

Build it yourself

Prefer to compile? It’s a standard CMake build with the GUI turned on. The one non-obvious prerequisite: generate the FlatBuffers headers first.

# 1. Generate the FlatBuffers headers the node expects, into src/rpc.
flatc --cpp -o <bcore>/src/rpc \
  shared-utils/fb-schemas/proof.fbs \
  shared-utils/fb-schemas/blockheader.fbs \
  shared-utils/fb-schemas/validation.fbs

# 2. Configure with the GUI + wallet enabled (Qt 6.2+ required).
cmake -S <bcore> -B build \
  -DBUILD_GUI=ON -DBUILD_CLI=ON -DENABLE_WALLET=ON \
  -DWITH_ZMQ=ON -DWITH_QRENCODE=ON

# 3. Build the app and the CLI. (Job count: $(nproc) on Linux,
#    $(sysctl -n hw.ncpu) on macOS — or just pick a number, e.g. -j8.)
cmake --build build --target bitcoin-qt bitcoin-cli -j8

The general build docs (doc/build-osx.md, doc/build-unix.md, doc/build-windows.md) cover toolchain and dependency setup per platform.

First run

On first launch the app walks you through a datadir and network, then a wallet:

Pick a network — start on testnet. (Mainnet is coordinated; see How to run a node.)
Create a wallet and encrypt it with a passphrase. This generates your keys locally — they never leave the machine.
Get an address from the Receive tab and let the node sync. While it does, the rest of the tabs are live but read-only until you have funds.

Under the hood this is createwallet / getnewaddress; the GUI just drives them. Addresses are Taproot-capable and use the network’s own prefix (testnet addresses start with the tct bech32 prefix).

Wiring up verification (it has to be real)

The node runs with -validationapi=real: every block’s AI proof gets a real verification verdict — there is no “skip the check” mode for a wallet holding funds. What you choose is who runs the verifier:

Run your own (open source). The verifier ships in the public repo and pairs with the node over ZMQ — this is the solo-stack setup, GPU required. Full walkthrough: How to run a verifier.
Use a verification service — yours or a third party’s. Point the node at any verifier exposed over HTTPS: your own verification-api running on a GPU box elsewhere, or a provider offering verification as a service:
```
# env (or the -validatorhttpurl= flag; container: same envs)
VALIDATOR_HTTP_URL=https://verifier.example.com
# optional: VALIDATOR_API_KEY=…  · several: VALIDATOR_HTTP_URLS / VALIDATOR_API_KEYS
```

Whichever you pick, the delegation covers only the AI replay. Signatures, scripts, assets, balances and the chain itself are always verified by your own node, in every configuration — the verifier can’t lie to you about anything except the one check you asked it to run, and even that is a replayable proof anyone can re-check.

What the app lets you do

Beyond send and receive, the menu bar carries the TensorCash surfaces. Each tab is a front end to a real consensus feature — there’s no server in between.

Tab	What it’s for
Assets	Issue and hold on-chain assets; flag an asset KYC-required with a zero-knowledge transfer circuit; rotate issuance keys (ICU). Issuer mode and holder mode in one page.
Trading	Build self-contained contracts between two parties — Repo, Forward, Spot, plus CFD and Option — and watch the trade board, pricing breakdown, and risk view.
AI Models	Register a model into the mineable set, post a challenge against one, manage the registration deposit, or burn it.
Mining APIs	Monitor a connected miner and verifier, and configure which validator the node talks to.

There’s more for advanced users — cross-chain bridge sessions, governance, and ZK proof tooling (commitment proofs, descriptor import/export) — surfaced as their own dialogs. The point isn’t to use all of it on day one; it’s that the protocol’s capabilities live in the wallet you already trust with your keys, not behind some hosted dashboard.

The asset-aware wallet (one thing to know)

The wallet treats assets as first-class alongside BTC. Each asset lives in its own output (a UTXO carries exactly one asset type), and by default the wallet won’t spend asset UTXOs when you send plain BTC — so an ordinary payment can never accidentally move your tokens. That guard is the avoid_asset_utxos setting (on by default). When you do want to spend an asset, the Assets tab (or sendasset) does it deliberately; from the RPC you opt in with fundrawtransaction … '{"avoid_asset_utxos": false}'. See managing-wallets and the asset RPC reference for the full surface.

Where to go next

The node underneath — pruning, sync, and the trust boundary: How to run a node
Verify it yourself — How to run a verifier
RPC reference — /docs/rpc/ · /docs/core-node/api/
What assets and contracts are — the assets and forwards explainers on the blog.

The app that holds your keys is the same one that verifies the chain. That’s the whole idea.

Authored pseudonymously by Imosuke Takakuni.