Restoring a phrase now scans for the account numbers it already uses,
instead of opening account 1 and leaving the rest to be guessed at. Each
number is derived under both schemes, the chain is asked in one request
which of those addresses exist (a System::Account entry is there for an
account that has ever been funded), and the scan carries on while a batch
held any, stopping after a gap of 20 empty numbers, as the mobile
wallet's import does. Numbers found are opened and remembered like a
hand-added one, so they come back on the next unlock. The same scan is a
"Find accounts" button on every open wallet with a phrase, and it says
what it found. A wallet with no phrase, or a chain that is not connected,
offers no scan; a failure during restore is swallowed, since the wallet
is open either way and the button retries.
On the dev node: 7 DEV sent from the CLI to account 3 of the dev phrase,
then that phrase restored here. Without pressing anything the wallet
opened accounts 1, 2 and 3 under both schemes, account 3 showing the
7 DEV, after looking at 40 numbers; settings recorded 1 and 2. On a
freshly created phrase, Find accounts looked at 20 numbers, added
nothing, and said so.
Closes#69
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014ftBXYuba8ARhQeF74oUgW
The spent check for wormhole deposits looked each nullifier up in
Wormhole::UsedNullifiers by key. That map is Blake2_128Concat, so the key
is blake2_128(n) ‖ n and every request handed the node the nullifier
itself. An exit publishes its nullifier on chain, so whoever runs the
node could match a later exit to the connection that asked, and that
connection also asked for the wallet's ordinary balances. The accounts
page ran it automatically for every open wallet with a phrase, so 0.1.0
and 0.2.0 sent unspent nullifiers to our mainnet endpoint.
spent_among now does what quantus/extension does: it reads whole buckets
of the map (keys sharing the first byte of blake2_128(n)) with
state_getKeysPaged, the buckets it needs padded with random others to at
least 16 and asked in shuffled order, and decides membership in Rust. The
node learns which buckets were read, never which entry mattered. The per-
key lookup is gone. Tests pin the rule: the plan covers ours, pads to 16
without repeats and does not lead with ours; no request carries a
nullifier and each is the map's root plus one byte. Against mainnet, a
real used nullifier read from a bucket hashes to that bucket and the
bucket read reports it spent and a random one unspent.
doc/threat-model.md gains the wormhole section: nullifiers and the
wallet's leaves are never named to a node, and spending (#46, #47) must
not request the Merkle path for the spent leaf alone.
Closes#68
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014ftBXYuba8ARhQeF74oUgW
91ec5fb bumped the workspace to 0.2.0 but left wallet-entities,
wallet-core and wallet-data pinned to each other at =0.1.0, so Cargo.lock
no longer resolved. The pins are now =0.2.0, the lockfile follows, and
script/stamp-version.sh rewrites the pins from the workspace version so
the next bump cannot leave them behind. Gate run with --locked.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014ftBXYuba8ARhQeF74oUgW
"Add account" on a wallet that carries a phrase derives the next account
number under both schemes, numbered as Quantus's clients number them
(m/44'/189189'/<account>'/0'/<scheme>', the mobile SDK's pathForIndex),
opens them at once, and remembers the number in settings under the
wallet's name; the next unlock re-derives them from the phrase. The
keystore file stays quantus-cli's single keypair, so nothing about the
added accounts is written there, and nothing secret is written anywhere.
Accounts show "Account N" wherever they are listed or picked unless the
person named them. A single-key wallet offers no Add account and the
command refuses it by name. settings_set keeps the stored account
numbers, so a save from the webview's cached settings cannot erase one
added since.
Pinned against quantus-cli 2.2.2 imports of the dev phrase at
--derivation-path: account 1 is qzm41eg2… (ML-DSA-65) and qzn2nAa4…
(ML-DSA-87), account 2 is qzohziq6… (ML-DSA-65). Driven on the dev node:
restore, Add account showed those two addresses as Account 2; after a
restart and unlock they were still there; 4 DEV from crystal_alice to
Account 2 and 1 DEV back from it, both submitted.
Closes#67
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014ftBXYuba8ARhQeF74oUgW
No scheme choice anywhere. Create and restore no longer ask for ML-DSA-65
or ML-DSA-87, and the commands behind them take no scheme. A wallet that
carries a phrase opens with an account under each scheme at its
conventional path, ML-DSA-65 first and ML-DSA-87 labelled legacy, plus
the file's own keypair when it sits at another path, de-duplicated by
account id. A raw key such as crystal_alice keeps its one account. The
default follows Quantus's own clients: quantus-cli's --scheme default,
the mobile SDK's DilithiumSchemeExtension.current and the extension's
DEFAULT_TYPE are all ML-DSA-65, and the extension already shows both
accounts with no key type to choose. The keystore file stays
quantus-cli's and records the ML-DSA-65 keypair; the rest is derived on
every open.
Any number of wallets open at once. The session holds a list of open
wallets, each with its accounts and seed; unlocking adds one, locking
takes a wallet name or locks all, signing finds the account in
whichever wallet holds it, and one idle clock locks them all. Session
status lists the wallets and a flat account list where every account
names its wallet. The sidebar lists open wallets with a lock each, an
"open another" page and "lock all"; accounts groups rows by wallet;
send, receive and history pick from every account of every open wallet,
grouped by wallet and labelled by scheme; the wormhole panel is per
wallet.
Driven on the dev node: crystal_alice open, the public dev phrase
restored beside it with no scheme field, and its two accounts appeared,
qzq29m9… (ML-DSA-65) and qzjrYTUnn… (ML-DSA-87, legacy), the addresses
quantus-cli lists for that phrase. 5 DEV from crystal_alice to the
legacy account, 2 DEV from it to its ML-DSA-65 sibling, both in blocks.
Locking devphrase left crystal_alice signing while a transfer from
devphrase's account was refused; lock all returned to the lock screen.
Unit tests cover both-schemes derivation for every CLI fixture,
side-by-side wallets, per-wallet lock and the shared idle rule; the
secret-leak test passes with both signers held.
Closes#65Closes#66
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014ftBXYuba8ARhQeF74oUgW
Three faults a first tag would have hit. The version check and the
collect step looked for target/release/wallet-app, but the binary has
been blackbeard-wallet since the product was renamed for packaging. The
bundle step ran the Tauri CLI with --dir ui, where there is no Tauri
project to find; it now runs from crates/wallet-app, checked with
`tauri info`, and the CLI is pinned to 2.11.4 as doc/reproducibility.md
said it would be once a release was cut. The publish job's `rpm -K`
right after signing would exit non-zero on a runner whose rpm database
does not hold the lair.cafe key; the check now runs on the repo host
after the rsync, where gitea_ci verifies cichlid-0.1.9 as OK today.
Refs #32
Refs #33
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014ftBXYuba8ARhQeF74oUgW
The rust gate builds and tests with --locked, so a change that would
move Cargo.lock fails instead of resolving something new. A dependency
policy step runs cargo deny check (licenses, advisories, bans, sources
from deny.toml) and cargo machete, both now in the runner image
(gongfoo bd936d3, images run 284). deps.yaml runs the advisory check
daily on the rust runner, so an advisory published against a
dependency the lockfile already pins turns red within a day whether or
not anyone pushes.
Closes#49
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014ftBXYuba8ARhQeF74oUgW
wallet_data::ramp::StubRamp builds a session URL on our own host from
the request (direction, asset, destination, currency) and nothing else;
it is what proves the plumbing before a provider is signed (#44). The
ramp_session command decodes the address, builds the request, refuses a
URL that is not https, and hands the URL back; the receive screen's Buy
and Sell buttons pass it to the opener, whose capability allows
blackbeard.observer and the explorer and nothing else. The wallet's
webview never navigates: driven live, the client returned
https://blackbeard.observer/ramp?direction=buy&asset=dev%2Fnative&…,
Buy handed it to the opener without error, and the webview stayed on
#/receive.
doc/reproducibility.md records what the build pins and what a second
build of the same tag is expected to differ in; the release workflow
exports SOURCE_DATE_EPOCH from the tagged commit. The diffoscope
comparison waits on the first tag.
Closes#43
Refs #51
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014ftBXYuba8ARhQeF74oUgW
wallet_core::orders is the pure part: Quoted → AwaitingDeposit →
Processing → Success | Refunded | Failed, with Expired when a quote's
deadline passes before a deposit is seen; it never moves backwards, a
quote past its deadline expires without a network call, and the poll
delay doubles from ten seconds to five minutes (five seconds while
processing). Orders persist through an OrderStore port on the same
SQLite file; on start the app follows every order still open, and the
follower asks the provider with backoff and jitter, persists each move
and emits orders:updated.
Commands: swap_assets (what 1Click lists and the registry maps),
swap_preview (a dry quote), swap_order_create (a wet quote persisted
with its deposit address and deadline) and orders_list. The swap screen
sits behind a preview setting, says plainly that every pair today is
paid from an external wallet, quotes, shows the deposit address with a
QR, memo and deadline, and lists orders with their states.
Driven live on the dev network: BTC on bitcoin to USDC on near, 0.001
BTC quoted at 75.568313 USDC, at least 74.812629, about 805 s. Reserving
a deposit address failed with 1Click's "Failed to get quote": a wet
quote needs the partner credential the relay will hold (#40), which is
the operator's registration. Until then the screen previews and the
poller has nothing to follow; the state machine and the store are
covered by unit tests, including the mid-order restart the store makes
possible.
Refs #39
Refs #41
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014ftBXYuba8ARhQeF74oUgW
tauri-plugin-updater with a minisign public key in tauri.conf.json (the
private key and its password are repository secrets, generated for this
and never in the repo), the manifest endpoint on the same host as the dnf
repo, and updater:default plus process:allow-restart granted with their
reasons. app_info now says how the binary was installed; the rpm and deb
opt out because dnf and apt own their updates, the AppImage, NSIS and dmg
opt in. The shell shows an offer three seconds after settling, with the
two versions, and applies it only on "Update and restart". The release
workflow signs the bundles (createUpdaterArtifacts), writes latest.json
for linux-x86_64 pointing at the release asset with its signature, and
the publish job rsyncs it to rpm.lair.cafe last, so a manifest never
names an asset that is not yet released. Windows and macOS entries come
with #34; the run-N-then-N+1 check waits on two published releases.
The secret handling audit is a test, secrets_do_not_leak.rs: create a
wallet from a known phrase, open it, unlock, sign, derive the wormhole
keys, use both caches, lock, all under trace logging into a sink; then
assert the log, every file in the data directory and the Debug output of
every secret-holding type contain none of the words, the seed, the
secret key or the wormhole secret, as hex, as raw bytes or as the decimal
list a derived Debug prints. OpenedWallet and Session gain redacting
Debug impls so the test can log them. The sample of the secret key
starts inside K: an ML-DSA secret key opens with rho, which is also the
public key's first 32 bytes, and the first draft of this test flagged the
public key for it.
Closes#50
Refs #35
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014ftBXYuba8ARhQeF74oUgW
keys/wormhole.rs derives the wormhole keys from the seed at the wormhole
coin type (m/44'/189189189'/i'/0'/0'), pinned to what quantus-node's
`key quantus --scheme wormhole` prints for the public dev phrase at
index 0 and 1, and derives a miner's address from its published inner
hash (bob's, as the observer shows it). The nullifier that spends a leaf
is mirrored on the Poseidon core alone, pinned to four vectors produced
once with the circuit crate, so the wallet does not carry the prover to
know what it has spent.
substrate/wormhole.rs reads ZkTree::LeafCount, scans ZkTree::Leaves in
pages of 500 locally computed keys for leaves paying an address, and
checks Wormhole::UsedNullifiers. Nothing on chain indexes leaves by
recipient, so the scan runs once from zero and then only over what was
appended; the SQLite cache keeps the leaves and the frontier under a
ShieldedCache port. The wormhole_summary command derives the keys from
the session's seed for the call, scans, marks spent leaves, and answers
with the address, the inner hash and the shielded and received totals;
the accounts page shows it with copy and rescan. A raw-seed wallet with
no seed is told so rather than shown a fake address.
Verified on mainnet through the public endpoint: a full scan of 107,127
leaves in 16 s found 31 leaves paying bob's wormhole address for
9.34 QTC, the observer's 30-reward attribution of 9.33 plus the one
since; the dev phrase restored in the app shows
qzq32vN2ZtX2T9YrvCh69CMvbC2nWmEq4tCjRWKg4CyuxeShg and inner hash
0x5a5891e7…, the node's own numbers, with the tree scanned to its end.
doc/threat-model.md names the assets, the boundaries and the file behind
each mitigation; its review by someone else is what closes#48.
Closes#45
Refs #48
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014ftBXYuba8ARhQeF74oUgW
crates/wallet-data/spec/1click-v0-openapi.yaml pins NEAR Intents'
1Click API (0.1.10); swap/oneclick.rs types tokens, quote (with dry),
deposit/submit and status from it, camelCase as the spec has them, with
every documented execution status round-tripping through serde. The
wallet's SwapRequest maps both assets through the asset registry and is
refused by name for anything it cannot map; a status answer maps to the
wallet's states with the destination tx hash on success and the refund
reason on failure. The JWT is a bearer the relay sets at run time, never
a constant; without it the API answers tokens and dry quotes, which is
all a preview needs.
Live, ignored test: a dry EXACT_INPUT quote of 10 USDC on Base to USDC
on NEAR at 100 bps came back 9.974166 with a floor of 9.874424, within
the slippage asked for, and reserved no deposit address.
Closes#38
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014ftBXYuba8ARhQeF74oUgW
assets.toml beside the chain profiles: what the wallet holds (QTC, PLK,
DEV; none on NEAR Intents yet, which is why the Quantus leg of a swap is
its own child) and the transit legs it only passes value through (BTC,
wNEAR, USDC on NEAR, XLM), each with its Intents asset id from
GET /v0/tokens. AssetRegistry parses it, refuses a duplicate asset or an
Intents id claimed twice, and answers intents_id with
SwapError::UnsupportedPair naming the asset for anything it cannot map,
rather than guessing. A saved token list pins that every mapped asset
resolves to exactly one live id with the same symbol and decimals.
Closes#36
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014ftBXYuba8ARhQeF74oUgW
An "Other networks" table under the accounts: every profile the settings
allow other than the selected one, each connected on demand and
following heads like the main table, with the account's spendable and
total balance there and the chain's state. One seed gives the same
address on every Quantus-family chain (they share coin type 189189), and
the table says so rather than pretending they are different accounts.
Run on the dev network with testnets shown: Quantus mainnet through
wss://quantus.blackbeard.observer at block 54032 and Planck at 1111122
listed beside the dev chain, both at zero for crystal_alice; a Polkadot
address in the send form refused as "a Polkadot address, not a Local dev
node address".
Closes#37
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014ftBXYuba8ARhQeF74oUgW
deny.toml allows the GPL-compatible licenses this wallet may link
(MIT-0 for qp-poseidon-core among them), fails on advisories and yanked
crates, bans a vendored OpenSSL and the chrono soundness range, and
refuses unknown registries. Running it: time 0.3.45 carried a stack
exhaustion advisory and is updated to 0.3.55, which needs Rust 1.88, so
the workspace's rust-version moves from 1.85; quick-xml 0.38's two
advisories are ignored with the reason recorded, since it is reached
only through plist at build time on this repository's own files and
plist 1.8 pins it. cargo-machete found serde and serde_json unused in
wallet-app; both are dropped. The CI steps follow once the rust runner
image carries the two tools (gongfoo bd936d3).
Refs #49
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014ftBXYuba8ARhQeF74oUgW
A table of the SS58 prefixes a person is likely to paste by mistake, from
the SS58 registry, so a Polkadot or Kusama address pasted into the send
form is refused as "a Polkadot address, not a Quantus address" rather
than as a bare prefix number; a prefix nothing knows still says which
prefix a Quantus address has. Profiles the wallet carries take
precedence over the table, so a Quantus-family prefix names mainnet.
Refs #37
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014ftBXYuba8ARhQeF74oUgW
rpm/blackbeard-wallet.spec is the house prebuilt-binary spec: the bare
binary from the release, the desktop entry rendered from the same
template Tauri's bundlers use, AppStream metadata and four hicolor icons;
no strip, no debuginfo; validators run where they exist; every rpmlint
warning that stands is explained at the top. The release workflow gains a
package job on the rpm runner (changelog entry from the tag through
actions/rpm-changelog, rpmbuild with dist .fc44, rpmlint) and a publish
job under the shared rpm-publish concurrency group that signs with the
repository key, rsyncs as gitea_ci to oolon, runs createrepo_c and
regenerates packages.json, exactly as cichlid does. rpm/rpmmacros and
script/generate-packages-json.py are cichlid's.
Built here from the local release binary: blackbeard-wallet-0.1.0-1.fc44
installs /usr/bin/blackbeard-wallet, the desktop entry, the metainfo and
the icons. The publish job needs RPM_SIGNING_KEY, RPM_SIGNING_KEY_ID and
RSYNC_SSH_KEY on this repository, which only the operator can add; until
then a tag builds and attaches the release but stops at publish.
Refs #33
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014ftBXYuba8ARhQeF74oUgW
Pushing vX.Y.Z runs .gitea/workflows/release.yaml on rust-gtk3: it
refuses a tag that disagrees with the workspace version
(script/stamp-version.sh, which also stamps tauri.conf.json and
ui/package.json from Cargo.toml), builds the webview and the deb, rpm and
AppImage bundles through the npm Tauri CLI, checks the binary answers
--version with the tag, and attaches the bundles, the bare binary and
SHA256SUMS to a Gitea release for the tag using the repository's own
Actions token.
The product is now `blackbeard-wallet`, no space: that name is the
binary, the rpm and deb package, and every release asset, so
`dnf install blackbeard-wallet` reads right. The window title and the
desktop entry keep "blackbeard wallet" through a desktop template. The
binary answers --version and --help before touching the display.
Bundled locally on Fedora 44: deb, rpm (name, license and URL right,
desktop entry installed) and a 114 MB AppImage that prints
"blackbeard-wallet 0.1.0". The AppImage step needs librsvg2-devel for
linuxdeploy's GTK plugin, which the rust-gtk3 runner image does not carry
yet; that is a one-line change in gongfoo, without which the workflow's
bundle step fails on the AppImage.
Refs #32
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014ftBXYuba8ARhQeF74oUgW
History comes from the observer's account activity route, chosen over a
relay because the observer already indexes every chain with a profile
and serves per-account activity keyset-paginated (recorded on #23). A
HistorySource port in wallet-core with an observer adapter in wallet-data
reads it; the rows a person looks for are typed (transfers in and out,
wormhole exits, reversible schedule, cancel and execute, and calls the
account signed) and the rest dropped, while the cursor always advances
over the raw rows. The wormhole pallet mirrors every native transfer as
NativeTransferred, so only rows with the wormhole's own account as a
party count as wormhole movements; the mirrors would otherwise list each
send twice. A saved response pins the parser.
A HistoryCache port with a rusqlite adapter keeps what the indexer said
under <data>/history.sqlite, keyed by chain, account and position, with
a per-account record of when the indexer last answered and how far it
had read. The history_page command stores as it fetches and, when the
indexer cannot be reached, serves the cache with from_cache set and the
reason attached.
Profiles carry the indexer URL (none for the dev node, and the screen
says so). The history screen pages with "Older", refreshes, shows an
offline chip with the cache's age, and opens the account on the public
explorer through tauri-plugin-opener, granted open-url for those two
hosts only, with the reason in the capability file.
Verified on mainnet: two pages of 45 and 46 rows for an active account
through the client, the cache file written; with the indexer overridden
to a dead address, the same call served 50 cached rows marked offline
with the error and the last fetch time, and the screen showed
"offline: cached 1 min ago". An unknown account reads as "Nothing yet".
The observer's ignored live test reads two pages.
Closes#23Closes#30
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014ftBXYuba8ARhQeF74oUgW
On Linux, before Tauri, tokio or any thread exists, the app reads what
the machine says (NVIDIA module loaded, Wayland session, an explicit
WALLET_WEBKIT_DMABUF=on|off) and sets __NV_DISABLE_EXPLICIT_SYNC=1 for
NVIDIA on Wayland and WEBKIT_DISABLE_DMABUF_RENDERER=1 for NVIDIA at all,
each logged with its reason so a blank-window report says which path was
taken. A variable already set in the environment is left alone. The
decision is a pure function with tests for the paths this Intel machine
cannot take.
doc/platform-smoke.md carries the v1 checklist and today's Linux pass
(Fedora 44, GNOME 50 on Wayland, webkitgtk 2.52.5). Windows 11 and
macOS 15 are not run: no such machine here; #31 stays open for them.
Refs #31
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014ftBXYuba8ARhQeF74oUgW
The accounts page lists PendingTransfersBySender for every account of the
open wallet, refreshed every five seconds, with when each executes: at a
block, counted down at the block interval the chain manager now measures
over its last 32 best heads (exposed as ChainStatus.block_interval_ms,
with the profile's nominal time as the fallback and labelled as such), or
at a timestamp, counted down by the clock. Cancel prepares
ReversibleTransfers.cancel and goes through the same review pane as a
send, which moves out of the send route into ReviewAndSign.
The call decoder now renders a 32-byte argument by its metadata type: an
AccountId32 as SS58, anything else as hex. Before, a cancel's tx_id was
dressed up as an address. Unit tests cover both the interval and the
rendering; the remaining Option<u64> fields are typed `number | null`.
On the dev node: a 2 DEV transfer with a 60-block window listed at block
314 with "49 blocks, about 52 s" against a measured 1.1 s interval; a
3 DEV transfer with a 1000-block window cancelled through review, the
tx_id shown as hex, and the balance back up by 3 less the fee. Block 314
arrived 14 s after the estimate: the dev chain's interval swung between
0.6 and 1.7 s per ten blocks over that minute. See the issue for what
that means for the acceptance criterion.
Closes#29
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014ftBXYuba8ARhQeF74oUgW
The form collects text. Review shows the call decoded from the bytes
that will be signed, from PreparedTransferInfo: pallet and call, each
argument as Rust rendered it, the fee, the mortality and the nonce.
Submit hands back only the prepared id, so nothing the form holds can
reach the signature; Back discards the prepared transaction on the Rust
side. A cancellation window is offered as presets or a custom block
count, described in the chain's nominal block time, and hidden for a
high-security account whose delay is fixed. After submit the tx:status
events drive a stage list until finalized, failed or dropped.
Event subscriptions now go through one helper that copes with `listen`
resolving after the effect is torn down, which under StrictMode left a
second listener alive and showed every stage twice. Optional u64 fields
are typed `number | null` rather than `number`.
On the dev node, from crystal_alice: 3 DEV reviewed as
Balances.transfer_keep_alive with the recipient and "3 DEV", signed and
in a block; 2 DEV with a 200-block window reviewed as
ReversibleTransfers.schedule_transfer_with_delay, in a block, and then
listed by reversible_pending with cancellable_by_me; a prefix-42 address
refused at prepare with the cross-chain message; 5,000,000 DEV signed
and reported Failed: Arithmetic(Underflow).
Closes#28
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014ftBXYuba8ARhQeF74oUgW
The receive screen shows one account's address as text, as a QR (drawn
in the webview by qrcode-generator, since an address is public), and as
the five-word checkphrase Rust derives, with a copy button through
tauri-plugin-clipboard-manager granted only write-text, with its reason.
Accounts can be named in place; the labels live in settings under
account_names, keyed by address, and show on the receive screen too.
Checked against the dev node: the checkphrase for crystal_alice reads
Toast-Terrific-Kitten-Warrior-Churn, the same as `quantus wallet list`;
a `quantus send` of 7 DEV from crystal_bob raised the accounts row from
99,957.786510548 to 99,964.786510548 within the next head; Copy flips
to Copied; a rename is written to settings.json and survives a lock.
Closes#27
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014ftBXYuba8ARhQeF74oUgW
Three routes under /onboarding, reachable from the lock screen and from
the shell, since a second wallet is the same flow as the first. Create
picks a scheme (ML-DSA-65 by default), shows the 24 words once, and
stands the backup challenge between seeing them and having a wallet; a
failed challenge drops the phrase on the Rust side and starts over.
Restore takes a phrase and a scheme, with a note that the same phrase
gives a different account under each. Import opens a native file chooser
through tauri-plugin-dialog, the first plugin, granted only
dialog:allow-open with its reason in the capability file; the path goes
to Rust, which reads the file. Every path ends unlocked on the accounts
page.
Driven through the WebKit inspector against the dev node: create wrote
onboard_test.json and unlocked; restoring the same phrase under a new
name produced the same address; importing a fixture file with the right
password opened it and with a wrong one mapped to wrong_password. The
chooser itself is a Wayland window nothing here can type into, so the
permission is verified by the open promise staying pending rather than
rejecting; CLAUDE.md and the inspector script now say so.
Closes#26
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014ftBXYuba8ARhQeF74oUgW
Running the shell for the first time showed a blank white window and no
error anywhere: Vite's dev page injects an inline React Refresh preamble,
the production CSP forbids inline scripts, and every component module then
throws on `$RefreshReg$` before React mounts. `tauri.conf.json` now carries
a `devCsp` for the dev server's origin; the production CSP is unchanged.
`WALLET_DATA_DIR` relocates wallets, settings and profile overrides
together, so a dev run lives in a throwaway directory instead of the real
app data; `WALLET_KEYSTORE_DIR` still moves only the wallets, for sharing
them with quantus-cli in place.
Verified end to end against the local dev node by driving the webview
through WebKitGTK's remote inspector (`script/webview-inspect.py`, kept
with the reason in CLAUDE.md): the lock screen lists both dev accounts;
unlocking crystal_alice shows 99,957.786510548 DEV at block 1832, 100 from
final, with the status bar on ws://127.0.0.1:9944 at spec 152; the block
number advances on its own; a settings change lands in settings.json; the
idle rule locks the UI without a click after the configured minute and the
Rust log says so; the Lock button locks; the console shows nothing but
Vite connecting. GNOME refuses D-Bus screenshots and ImageMagick captures
WebKit's GPU surface as flat grey, so the DOM was the evidence.
Refs #25
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014ftBXYuba8ARhQeF74oUgW
The frame every screen sits in. A lock screen fronts everything while the
session is locked: pick a wallet file, type a password, and the password
goes to Rust and nowhere else. Unlocked, a sidebar carries the sections,
the network switcher and a lock button with the minutes until the idle rule
fires; a status bar shows the chain in use, its endpoint, best and finalized
heights and spec version, and says "connecting…" or the last error
otherwise. Testnets are labelled in the switcher, the status bar and above
their content, as on the observer: a balance on a testnet is not money and
the chrome says so before the number does.
Settings persist as JSON in the app-data directory, written atomically:
network, idle lock, whether testnets are offered. Changing the network
re-keys every query; changing the idle lock takes effect on the next check.
The theme (system, dark, light) is a local preference applied before first
paint from the entry point, because the CSP allows no inline script.
Design tokens are the observer's, lifted whole so the wallet and the
scoreboard read as one family. The accounts page shows spendable and total
per account with the block the numbers were read at and how far that is
from final, refreshed by Rust on every head; send, receive and history are
placeholders naming their issues.
Wide integers now cross the IPC typed as `number`: they are JSON numbers on
the wire, which `bigint` cannot be serialised to, and none of them (block
heights, seconds, nonces) approaches 2^53. Amounts still travel as strings.
Closes#25
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014ftBXYuba8ARhQeF74oUgW
`script/dev-node.sh` fetches the v1.0.1 release binary once into `.cache/`,
checks it against the sha256 the release publishes, and runs
`quantus-node --dev` on a throwaway base path. The workflow starts it in
the background, waits for `system_chain` to answer `Quantus DevNet`, and
runs every ignored test whose name says `dev_node`: the send, reverse,
cancel and named-failure path, and the scheme-by-era probe that found the
mortality bug. Public-node tests stay ignored in CI.
Rehearsed locally on a second node on port 9955: both tests pass in 15 s.
Closes#24
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014ftBXYuba8ARhQeF74oUgW
`SubstrateAdapter` implements the chain-adapter port for Quantus. `prepare`
builds the call from a chain-neutral intent, decodes it back from its own
bytes through the runtime metadata into a summary a person can check (a
32-byte account renders as the chain's SS58 address, an amount in the
token's units), prices it by assembling a full extrinsic with a zeroed
signature of the right size and asking `TransactionPaymentApi_query_info`,
and returns the signer payload for the session to sign. `submit` refuses
if the runtime spec moved or the payload no longer matches, assembles with
the session's signature, and streams statuses; a dispatch error is reported
at inclusion, named `Pallet::Variant` where the chain names it, so nobody
waits for finality to learn a transfer failed.
Reversible transfers: `reversible_for` routes through
`ReversibleTransfers::schedule_transfer_with_delay`; a high-security
account is routed through the pallet's default-delay call whether it asked
or not, since the chain's extension refuses a plain transfer from one.
`pending_reversible` lists what is waiting with the execution block from
the scheduler's lookup, whose task name is the tx id itself, and
`CancelReversible` cancels.
Three things the dev node taught, each now written into the code:
- Mortality must be anchored at the *best* block. Finality on this
proof-of-work chain trails the tip by a hundred blocks, and an era born
at the finalized head names a birth block whose hash the runtime resolves
differently: "Transaction has a bad signature", for both schemes, while
immortal transactions from the same keys passed. Probed all four
scheme-by-era combinations to isolate it.
- Everything the UI shows is read at the best block, with the block number
and the finalized height alongside so confirmations can be shown.
subxt's `at_latest()` is the finalized block; the pending list read there
showed the state of a hundred blocks ago while the chain's events showed
every schedule landing.
- subxt's runtime-update subscription died on this node with "header not
found" after a reorg and took the connection with it. It is advisory
now: on error the runtime version is polled every ten heads and a change
forces a reconnect, which refetches metadata.
Live, against `quantus-node --dev` with the funded dev accounts: a 3 DEV
transfer from crystal_alice to crystal_bob is included and moves bob's
balance; a reversible transfer with a 200-block window is scheduled, shows
as pending with its execution block, and is cancelled; an overspend fails
as `Token(FundsUnavailable)`. Fee for a plain transfer: 0.010157927 DEV.
In the app: `transfer_prepare` (amount parsed from its decimal form in
Rust), `transfer_submit` (signs through the session, emits `tx:status`),
`transfer_discard`, `reversible_pending`, `reversible_cancel_prepare`.
Closes#22
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014ftBXYuba8ARhQeF74oUgW
`account_info` reads `System::Account` and
`ReversibleTransfers::HighSecurityAccounts` at the latest finalized block
through subxt's dynamic storage API, so a number the UI shows cannot be
reorganised away and no generated code has to track the runtime. An account
the chain has never seen is zero and nonce zero, not an error; the live
test reads the dev phrase's account on Planck and gets exactly that. The
next nonce comes from `system_accountNextIndex`, which counts the pool.
Spendable is free less frozen; total is free plus reserved. A high-security
account carries its guardian and its delay, in blocks or milliseconds as
the pallet stores it, so the send path (#22) can route it through the
reversible-transfers pallet instead of a plain transfer the extension
would reject.
The connection manager now publishes finalized heads on a watch channel.
`balances_watch` spawns one task per chain that re-reads every open
account on each head and emits `balances:updated`; `balances` reads once.
Both refuse with `Locked` when no wallet is open.
Closes#21
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014ftBXYuba8ARhQeF74oUgW
`ChainManager::start(profile)` spawns a supervisor that tries the profile's
endpoints in order, refuses a node whose genesis is not the profile's (by
name, so a typo in an override file cannot quietly sign for the wrong
chain), records the runtime version at connect, follows finalized heads,
applies subxt's runtime updates as the chain upgrades, and on any failure
rotates to the next endpoint after an exponential backoff with full jitter,
capped at a minute. A head that fails to arrive for two minutes counts as
a failure. `status()` reports the endpoint in use, spec and transaction
version, finalized height, head age, the last error and the failure count.
Backoff is a pure type with the schedule pinned in tests. The live test
gives Planck's profile a dead first endpoint and the real second one: it
connects to the second at spec 148 with zero failures, and mainnet's
profile pointed at Planck's node is refused with "is not quantus".
Supervisors start on demand from `chain_connect`, never at boot, because a
profile whose endpoint does not exist yet (#53) would otherwise retry
forever for nobody. `chain_status` reads without starting anything.
Not yet exercised: a stream dropping mid-session and a runtime upgrade
arriving while connected. Both go through the same loop and will be
driven on the dev node in #24.
Closes#20
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014ftBXYuba8ARhQeF74oUgW
`QuantusConfig` is quantus-cli's `ChainConfig` with the signature enum
defined here: `DilithiumSignature { Dilithium87, Dilithium65 }`, variant
indices 0 and 1, each carrying signature-then-public-key as one raw array
because the account id is a hash of the key and the verifier needs the key
itself. Defining it locally keeps sp-core out of a desktop wallet.
subxt 0.44, deliberately: it is the version quantus-cli signs mainnet with,
and its extension resolver skips any extension whose type is empty, which
is how the chain's ReversibleTransactionExtension and
WormholeProofRecorderExtension are tolerated with the default set. A test
pins that both names are in the metadata and that building still works.
`sign_call` builds the v4 extrinsic offline from captured chain state,
takes the signer payload from subxt (blake2-hashed past 256 bytes, as the
runtime hashes when it verifies), signs it with a `wallet_core::Signer`
under the profile's FIPS 204 context, and hands the signature back to
subxt to assemble. The test decodes the result byte by byte: 0x84, Id
address equal to the signer's account id, the variant byte, the public key
riding with the signature, the extras, the call data as the tail.
Live acceptance against a1-planck.quantus.cat, from an unfunded account:
signed under QUANTUS_EXTRINSIC the node answers "Inability to pay some
fees", so the signature passed; signed under the empty context it answers
"Transaction has a bad signature". Ignored test, run by hand.
Metadata fixtures are live `state_getMetadata` from mainnet (spec 152) and
Planck (spec 148), 101 KB each, v14.
Closes#19
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014ftBXYuba8ARhQeF74oUgW
`wallet-core/src/profiles.toml` carries what runtime metadata does not:
genesis hash, SS58 prefix, symbol and decimals, coin type, the endpoint
list, block time, and the rule for when the FIPS 204 signing context
applies. Three profiles ship: Quantus mainnet at spec 152 with QTC, Planck
with PLK (in the wallet only to prove the multi-chain UX), and a local dev
node with an empty genesis hash that means "do not check". Endpoints are
the names decided on #20 and #53, one per chain; until those exist an
override file points a dev run at the public nodes.
The override file is the same shape with every field optional: a known id
has fields replaced, an unknown id must be complete and is appended. A
mainnet endpoint must be wss, a genesis hash must be 66 characters or
empty, a context at most 255 bytes; anything else is refused with the
profile named. Adding a fourth chain is a TOML entry and no Rust, which the
test does.
`signing_context_for(profile, spec)` and `genesis_matches(profile, hash)`
are the two pure functions the adapter (#19, #20) will call at connect.
The app loads `<app data>/profiles.toml` or WALLET_PROFILES and exposes
`chains_list`.
Closes#18
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014ftBXYuba8ARhQeF74oUgW
`wallet_core::session::Session` is the only place decrypted key material
lives between commands: one wallet open at a time, its signers and, when
the file carried a phrase, its seed. Every signature goes through
`Session::sign`, which applies the idle rule before it looks at the key, so
a stale session refuses rather than signing one last time. Time is passed
in, so the rule is tested at 59, 118 and 119 seconds without waiting.
The seed is now a heap allocation behind a wiping box. Moving an inline
64-byte array through `Some(...)` and a function argument can leave copies
in dead stack frames that no destructor visits; moving a box moves a
pointer. A Linux test unlocks with a runtime-built seed and a signer whose
secret is a second runtime-built pattern, locks, then reads every writable
anonymous mapping in /proc/self/mem and asserts neither pattern is anywhere
in the process. It passes in debug and release. The comparison copies are
XOR-masked so the test cannot find itself.
In the app: `unlock` opens a file, turns its phrase into a seed and drops
the phrase; `lock` and `session_status` do what they say; a ticker thread
applies the idle rule every five seconds and emits `session:locked` so the
lock screen appears without a click. Ten minutes until settings exist.
Closes#17
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014ftBXYuba8ARhQeF74oUgW
A new wallet's phrase is 24 words from OS entropy through the hdwallet
crate, which wipes both the entropy and the phrase's own working buffers.
Validation runs the same pinned bip39 the hdwallet crate stretches with, so
a phrase that validates here derives there; it normalises case and
whitespace and rejects the wrong count, an unknown word, and a bad checksum
with an error a person can act on.
The checkphrase is Quantus's human-readable address checksum through
qp-human-checkphrase, with the 2048-word list vendored because the crate
loads it from the working directory at runtime, which a desktop app cannot
rely on. The value for the dev phrase's ML-DSA-65 account is pinned to what
`quantus wallet view` prints.
Creation is three commands so the webview sees a phrase exactly once:
begin generates and holds it and returns the words with a four-word backup
challenge; confirm passes the challenge or refuses, then derives at the
scheme's conventional path and writes the file; cancel forgets. No command
returns a phrase that already exists. Import from a phrase and from a CLI
file, and listing, are the other commands. App state is a mutex around the
pending creation; the keystore directory is the platform app-data
directory unless WALLET_KEYSTORE_DIR says otherwise.
Closes#16
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014ftBXYuba8ARhQeF74oUgW
`wallet_data::keystore` is the CLI's format: AES-256-GCM over the JSON of
the wallet data, keyed by Argon2id under the frozen profile (m=19456, t=2,
p=1) and a 16-byte salt, with the PHC string carrying the profile and salt
and never the digest. A file whose PHC string does embed a digest is refused,
as the CLI refuses it. On open the address is re-derived from the decrypted
key and the file refused if it differs, so a file that lies about its
address cannot be opened, let alone signed with. Legacy files with no
`scheme` are ML-DSA-87; files with no `wallet_type` are hot.
The directory rules are the CLI's too: a wallet name is a plain filename,
writes go through an unpredictable temporary file and a no-clobber rename
at mode 0600, and a symlink where a wallet should be is refused.
Proof in both directions. Eight real files open here: six written by
quantus-cli 2.2.2 for the dev phrase, one per scheme and path, and the two
fixtures the extension fork tests against. A file written here lists in
`quantus wallet list` with the expected address (ignored test, run with
QUANTUS_CLI set). A test greps the written file for phrase words and secret
key bytes and finds neither.
`Keystore` is a port in wallet-core: list, open, create, import a file,
export a file. Opening yields a `Signer` and, when the file carries one, the
phrase in a wiping holder; neither leaves Rust.
Closes#15
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014ftBXYuba8ARhQeF74oUgW
`wallet_data::keys::MlDsa` implements the `KeyScheme` port for ML-DSA-65 and
ML-DSA-87 on Quantus's own crates: hdwallet for the all-hardened
`m/44'/189189'/account'/change'/index'` derivation, dilithium for FIPS 204
signing, poseidon for the account id the runtime derives from a public key.
Signing is hedged with fresh OS randomness, and an empty context means "no
context", the pre-spec-148 rule, rather than a zero-length one.
The test vectors are six addresses produced by quantus-cli 2.2.2 for the
polkadot-js dev phrase, three paths per scheme; two of them are also the
addresses inside the extension fork's CLI-wallet fixtures. A signature made
under `QUANTUS_EXTRINSIC` verifies, and the same signature under the empty
context does not, which is the mistake that would otherwise reach mainnet as
a cryptographically valid, chain-rejected transaction.
`Signer` now requires `Debug`, so every implementation has to write one, and
the one here redacts. The seed is a 64-byte wiping holder with a `Debug` that
prints nothing. SS58 lives in `wallet_core::ss58`, blake2 and base58 only;
decoding returns the prefix so a foreign address can be refused by name.
Closes#14
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014ftBXYuba8ARhQeF74oUgW
Commands now return `Result<T, WalletError>`; Tauri rejects the promise with
the serialised error, and `ui/src/api/wallet.ts` is the one place that turns
it back into a thrown `WalletError` with the same `kind` the Rust enum has.
Anything that is not a `WalletError` is a bug on one side of the boundary and
is rethrown untouched so it is loud.
Screens never call `invoke` themselves. React Query holds what Rust knows,
with retries off (a wallet must not silently retry a command that failed)
and refetch-on-focus off. CI counts the files importing Tauri's IPC module
and fails unless the count is exactly one.
The first command is `app_info`, so the window shows a version that came
across the boundary as a typed struct rather than a string.
Closes#13
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014ftBXYuba8ARhQeF74oUgW
The IPC isolation pattern is on from the first command: every message from
the main window passes through the sandboxed isolation application and is
encrypted before Rust sees it, so a script injected into the webview can read
what the UI shows but cannot forge a command. The hook passes everything
through today; the point of shipping it now is that every later command is
born inside the boundary. Both `tauri` and `tauri-build` need the `isolation`
feature, and the build script refuses to proceed if either lacks it.
Capabilities are TOML rather than JSON so each permission can carry the
reason it exists on the line above it. `tests/capabilities.rs` makes that
comment mandatory, requires a real description on every capability, and
refuses to grant anything to a window other than `main`. A capability is the
one place a plugin's reach into the system is widened, and it should not be
possible to widen it quietly.
Closes#11
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014ftBXYuba8ARhQeF74oUgW
The house shape (architecture/generic.md §1): wallet-entities for the
vocabulary and the IPC wire types, wallet-core for the four ports that are the
architecture (KeyScheme, ChainAdapter, SwapProvider, FiatRamp), wallet-data
for the adapters that will implement them, and wallet-app as a Tauri 2 shell
whose commands are one-line shims. The webview is Vite + React + TypeScript
and reaches Rust only through ui/src/api/wallet.ts, typed by what ts-rs
exports from the entities crate on every `cargo test`.
Amounts are integer base units plus decimals, serialised as strings, because
the webview has no integer wide enough and a wallet that rounds is a wallet
that lies. The webview never receives a secret; readme.md and CLAUDE.md say
why and what will bite.
Two things the scaffold learned: Tauri's `version` field takes a JSON file or
a literal, never Cargo.toml, so the release workflow stamps it; and Prettier
must skip the generated types, which carry ts-rs's own style.
Placeholder icon; the mark comes later. CI targets the rust-gtk3 runner.
Refs #1
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014ftBXYuba8ARhQeF74oUgW
