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. The desktop wallet is a light validation node: it runs the fast structural checks locally, but by default it delegates the expensive full/model re-run — actually re-executing a forward pass on a GPU — over HTTPS to a verification service. That keeps the app laptop-friendly. If you want even that check on your own hardware, you can run a local verifier and point the wallet at it; see How to run a verifier and How to run a node.
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: install, or build
Install (most people)
Download the signed installer for your platform from the releases page and run it:
- macOS — a notarised
.dmg; drag the app to Applications. - Windows — a signed
…-setup.exeinstaller.
The desktop bundle ships the node (bitcoin-qt), a small signing helper, and an
optional bundled Tor, so a fresh install is a complete, ready-to-run wallet with
nothing else to set up.
If you grab an early, un-notarised macOS build, Gatekeeper will refuse the double-click. Clear the quarantine flag once, then open it:
xattr -dr com.apple.quarantine /Applications/TensorCash.app open /Applications/TensorCash.app(Or right-click the app → Open → confirm once.)
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).
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.