rob thijssen
1ca42fdbdf
`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
blackbeard wallet
A desktop wallet for post-quantum chains, Quantus first.
Linux, Windows and macOS; installable on Fedora with dnf.
Shape
The wallet is a Rust cargo workspace with a Tauri shell and a React webview. That split is the security model, not a convenience: every key, signature, decoded transaction and amount lives on the Rust side, and the webview only renders what a Tauri command hands it. Nothing that could serialise a secret is reachable from JavaScript.
crates/
wallet-entities/ domain types and the IPC wire protocol; exported to TypeScript
wallet-core/ wallet logic and the ports it is written against
wallet-data/ adapters behind those ports: keystore, cache, RPC, provider APIs
wallet-app/ the Tauri binary; commands are one-line shims into core
ui/ Vite + React + TypeScript webview
The ports in wallet-core are what make "any post-quantum chain" a profile
rather than a rewrite:
KeySchemeturns a seed and a path into a signer. ML-DSA-65 and ML-DSA-87 now; whatever the next chain uses later.ChainAdapterknows one chain: balances, building and submitting a transaction, watching it. The Substrate adapter is driven by runtime metadata plus a small per-chain profile (ss58 prefix, decimals, signature enum, transaction extensions, signing-context rule, coin type).SwapProvideris a swap venue. NEAR Intents first.FiatRampbuilds a provider session through a relay on our infrastructure, which holds the provider secrets, and opens it in the system browser.
The wallet is post-quantum only. Classical chains appear only as transit legs of a swap or ramp; the wallet never derives a secp256k1 or ed25519 key.
Why these choices
Quantus signs extrinsics with ML-DSA, hashes public keys with Poseidon2 for
the account id, and shields mining rewards behind a Plonky2 wormhole whose
prover is minutes of native CPU. All of that exists as Rust crates and nothing
else, so the core is Rust. Tauri is the house desktop convention
(~/git/architecture/generic.md §4) and the only shell that packages rpm, deb,
msi and dmg with a Rust-owned IPC boundary out of the box.
NEAR's post-quantum work (their MPC fork with threshold ML-DSA-87) is not yet able to sign a Quantus extrinsic, so the swap module is built and tested against chains NEAR Intents already lists, with Quantus as a registry entry that lights up when the bridge does.
Building
pnpm --dir ui install
cargo tauri dev --config crates/wallet-app/tauri.conf.json # from crates/wallet-app: cargo tauri dev
cargo test --workspace # also regenerates ui/src/api/generated
The CI gate is cargo fmt --check, cargo clippy -D warnings, cargo test,
and the webview's typecheck, lint and build. Run them before claiming done.
Work
Work is filed before it is done. Epics carry the epic label and an external
definition of done; their steps carry child, in dependency order, at
https://git.lair.cafe/blackbeard/wallet/issues. A commit that finishes a
child closes it (Closes #N); when an investigation contradicts an issue, the
correction is a comment on the issue, dated, not a surprise in a diff.