Quantus CLI
A modern command line interface for interacting with the Quantus Network, featuring built-in quantum-safe wallet management and real blockchain operations using SubXT.
🌟 Features
- Quantum-Safe Wallets: Built with Dilithium post-quantum cryptography
- SubXT Integration: Modern Substrate client with type-safe API
- Generic Pallet Calls: Call ANY blockchain function using metadata-driven parsing
- Real Chain Operations: Send tokens, query balances, explore metadata
- Smart Type Detection: Automatic parsing of addresses, balances, and data types
- Developer Tools: Pre-built test wallets and utilities
- Modern CLI: Built with Rust and Clap for excellent UX
- Cross-Platform: Runs on macOS, Linux, and Windows
- Beautiful UI: Colorized output with emoji indicators and progress spinners
- Smart Balance Display: Automatic formatting with proper decimals and token symbols
- Password Convenience: Multiple authentication options including environment variables
- Fresh Nonce Management: Automatic nonce handling to avoid transaction conflicts
🚀 Quick Start
Installation
From crates.io
# Install the CLI tool
# The binary will be available as `quantus`
From source
# Clone and build
# The binary will be available as `quantus`
As a library
Add to your Cargo.toml:
[]
# Full functionality (CLI + library)
= "0.1.0"
# Library only (smaller dependencies)
= { = "0.1.0", = false }
First Steps
Start by exploring the available commands:
# Get help to see all available commands
# Explore specific command groups
The CLI provides comprehensive help at every level, allowing you to discover functionality step by step.
📋 CLI Navigation
Help System
The CLI provides comprehensive help at every level. Every command and subcommand supports --help:
- Main level:
quantus --helpshows all available top-level commands - Command level:
quantus <command> --helpshows options for specific commands - Subcommand level:
quantus <command> <subcommand> --helpshows options for subcommands - Deep nesting: Help is available at any depth of command nesting
This hierarchical help system allows you to discover available functionality step by step, starting from the main help and drilling down to specific command options.
Verbose Mode
Every command supports --verbose for detailed debugging information:
- Standard output: Commands show essential information by default
- Verbose output: Adding
--verboseprovides detailed execution logs, network calls, and internal state information - Universal support: Verbose mode works on any command level and any subcommand
- Debugging aid: Use verbose mode to troubleshoot issues or understand command execution flow
Global Options
These options work on every command:
--verbose/-v: Enable debug logging with detailed output--node-url <URL>: Specify node endpoint (default:ws://127.0.0.1:9944)--help/-h: Show help for any command or subcommand
Command Structure
The CLI uses a hierarchical structure:
quantus [GLOBAL_OPTIONS] <COMMAND> [COMMAND_OPTIONS] <SUBCOMMAND> [SUBCOMMAND_OPTIONS]
Structure: The CLI follows a consistent pattern where global options can be combined with any command and subcommand at any level of nesting.
Discovering Commands
Start with the main help and drill down to explore available functionality. The CLI provides helpful error messages and suggestions when you make mistakes, guiding you to the correct command syntax.
Quick Reference
Common navigation patterns:
- Start with
quantus --helpto see all available commands - Use
quantus <command> --helpto explore specific command options - Add
--verboseto any command for detailed debugging information - Use
--node-urlto connect to different nodes (defaults to localhost)
Command Reference
Wormhole (Privacy-Preserving Transfers)
The wormhole commands implement a ZK-proof-based privacy layer. Funds are sent to an unspendable account derived from a secret, a zero-knowledge proof is generated to prove ownership, and the proof is verified on-chain to mint equivalent tokens to an exit account -- breaking the on-chain link between sender and receiver.
quantus wormhole address
Derive the unspendable wormhole address from a secret. This is step one of a private transfer -- it shows the address you need to send funds to.
Output:
Wormhole Address
SS58: qDx...
Hex: 0x...
To fund this address:
quantus send --from <wallet> --to qDx... --amount <amount>
Then send funds using a standard transfer (the chain's WormholeProofRecorderExtension automatically records a transfer proof for any balance transfer):
quantus wormhole prove
Generate a ZK proof for an existing wormhole transfer. The proof demonstrates knowledge of the secret without revealing it.
--exit-account: The destination address that will receive funds after on-chain verification (SS58 or0x-prefixed hex).--block: Block hash where the transfer was included.--transfer-count: Transfer count from theNativeTransferredevent.--output: Output file path for the hex-encoded proof (default:proof.hex).
quantus wormhole aggregate
Aggregate multiple leaf proofs into a single recursive proof. The aggregation circuit pads with dummy proofs and shuffles to hide which slots are real.
--proofs: One or more hex-encoded proof files. The number must not exceednum_leaf_proofsfrom the circuit config.- Displays timing for dummy proof generation and aggregation separately.
quantus wormhole verify-aggregated
Submit an aggregated proof to the chain for on-chain verification. This is an unsigned extrinsic -- no wallet is needed.
- On success, the chain mints tokens to each exit account listed in the proof.
- The command checks for
ProofVerifiedandExtrinsicFailedevents and reports the result.
quantus wormhole parse-proof
Inspect the public inputs of a proof file for debugging.
# Parse a leaf proof
# Parse an aggregated proof
# Parse and cryptographically verify locally
quantus wormhole multiround
Run an automated multi-round wormhole flow: fund -> prove -> aggregate -> verify on-chain, repeated over multiple rounds. This is the primary integration test for the wormhole system.
--num-proofs: Number of proofs per round (1 tonum_leaf_proofsfrom circuit config, default: 2).--rounds: Number of rounds (default: 2). In intermediate rounds, exit accounts are the next round's wormhole addresses; in the final round, funds exit back to the wallet.--amount: Total amount in planck to randomly partition across proofs (default: 100 DEV).--wallet: Wallet name for funding (round 1) and final exit.--keep-files: Preserve proof files after completion (default: cleaned up).--output-dir: Directory for intermediate proof files (default:/tmp/wormhole_multiround).--dry-run: Show configuration and derived addresses without executing.
Each round performs:
- Transfer (round 1 only): Randomly partition the total amount and send to wormhole addresses derived via HD path
m/44'/189189189'/0'/<round>'/<index>'. - Generate proofs: Create a ZK proof for each transfer with randomized dual-output assignments.
- Aggregate: Combine all leaf proofs into a single recursive proof.
- Verify on-chain: Submit the aggregated proof; the chain mints tokens to exit accounts.
After all rounds, the command verifies the wallet balance matches expectations (initial - fees).
Developer Tools
quantus developer build-circuits
Build ZK circuit binaries from the qp-zk-circuits repository, then copy them to the CLI and chain directories. This is required whenever the circuit logic changes.
Add --skip-prover when you only need verifier artifacts:
--num-leaf-proofs: Number of leaf proofs per layer-0 aggregation.--num-layer0-proofs: Number of inner proofs per layer-1 aggregation.--chain-path: Path to the chain repo (default:../chain).--skip-chain: Skip copying binaries to the chain directory.--skip-prover: Skip generating prover binaries.
What it does (3 steps):
- Clears stale artifacts from the CLI's
generated-bins/directory. - Calls the
qp-wormhole-circuit-builderlibrary directly to regenerate binary files ingenerated-bins/(verifier.bin,common.bin,aggregated_verifier.bin,aggregated_common.bin,config.json, plus prover binaries unless--skip-proveris set). - Copies chain-relevant binaries (
aggregated_common.bin,aggregated_verifier.bin,config.json) tochain/pallets/wormhole/and touches the pallet source.
After running, rebuild the chain (cargo build --release in the chain directory) so include_bytes!() picks up the new binaries.
quantus developer create-test-wallets
Create standard test wallets (crystal_alice, crystal_bob, crystal_charlie) with developer passwords for local testing.
Wallet Management
# Create a new quantum-safe wallet
# Create with explicit derivation path
# Import from mnemonic
# Create from raw 32-byte seed
# List wallets
# View wallet details
# Export mnemonic
Sending Tokens
# Simple transfer
# With tip for priority
# With manual nonce
Batch Transfers
# From a JSON file
# Generate identical test transfers
# Check batch limits
Reversible Transfers
Schedule transfers with a time delay, allowing cancellation before execution.
# Schedule with default delay
# Schedule with custom delay
# Cancel a pending transfer
High-Security Mode
Configure reversibility settings for an account (interceptor + delay).
# Check status
# Enable high-security with an interceptor
# Show accounts you guard
Account Recovery
Social recovery using trusted friends.
# Initiate recovery
# Friend vouches
# Claim after threshold met
Treasury
Treasury is the account that receives a configurable portion of mining rewards. No special spend/proposal flow — just view its state.
# Show treasury account and balance
Privacy-Preserving Transfer Queries
Query transfers via a Subsquid indexer using hash-prefix queries that hide your exact address.
Block Analysis
# Analyze a specific block
# Analyze latest block
# List blocks in a range
Generic Pallet Calls
Call any pallet function using metadata-driven parsing:
Other Commands
| Command | Description |
|---|---|
quantus balance --address <addr> |
Query account balance |
quantus events --block 123 |
Query events from a block |
quantus events --finalized |
Events from the latest finalized block |
quantus system |
System information |
quantus system --runtime |
Runtime version details |
quantus metadata --pallet Balances |
Explore chain metadata |
quantus version |
CLI version |
quantus compatibility-check |
Check CLI/node compatibility |
🔧 Environment Variables
Password Management
QUANTUS_WALLET_PASSWORD: Global password for all walletsQUANTUS_WALLET_PASSWORD_<WALLET_NAME>: Wallet-specific password (e.g.,QUANTUS_WALLET_PASSWORD_CRYSTAL_ALICE)
Node Configuration
- Set via
--node-urlflag or default tows://127.0.0.1:9944
💡 Getting Started
The CLI provides a comprehensive set of commands for blockchain interaction. Start by exploring the help system to discover available functionality:
- Explore commands: Use
quantus --helpto see all available commands - Discover options: Use
quantus <command> --helpto see command-specific options - Get details: Add
--verboseto any command for detailed execution information - Connect to nodes: Use
--node-urlto connect to different blockchain nodes
The CLI supports both simple commands and complex workflows, with built-in help and error recovery at every level.
🔐 Multisig Wallets
The Quantus CLI provides comprehensive support for multi-signature wallets, allowing you to create shared accounts that require multiple approvals before executing transactions.
Key Features
- Deterministic Address Generation: Multisig addresses are derived from signers + threshold + nonce
- Flexible Threshold: Configure how many approvals are needed (e.g., 2-of-3, 5-of-7)
- Full Call Transparency: Complete transaction data stored on-chain (no blind signing)
- Auto-Execution: Proposals execute automatically when threshold is reached
- Human-Readable Amounts: Use simple formats like
10instead of10000000000000 - Smart Address Display: Automatic SS58 formatting with proper network prefix (
qz...) - Balance Tracking: View multisig balance directly in
infocommand - Expiry Validation: Client-side checks prevent expired proposals
- Deposit Management: Refundable deposits incentivize cleanup
- Query Support: Inspect multisig configuration, proposals, and balances
Quick Start Example
# 1. Create a 2-of-3 multisig (waits for confirmation by default)
# Output: 📍 Multisig address: qz... (with proper network prefix)
# 2. Fund the multisig (anyone can send funds)
# 3. Create a transfer proposal (human-readable amount)
# Note: Expiry is BLOCK NUMBER (e.g., current block + 1000)
# 4. Check proposal details (shows current block + blocks remaining)
# Output shows:
# Current Block: 450
# Expiry: block 1500 (1050 blocks remaining)
# 5. Second signer approves (auto-executes at threshold)
Available Commands
Create Multisig
# Default: Wait for transaction and extract address from event
# Fast mode: Predict address immediately (may be wrong if concurrent creation)
Propose Transfer (Recommended for simple transfers)
# Amount formats supported:
# 10 → 10 QUAN
# 10.5 → 10.5 QUAN
# 0.001 → 0.001 QUAN
# 10000000000000 → raw format (auto-detected)
Propose Custom Transaction (Full flexibility)
Approve Proposal
Cancel Proposal (proposer only)
Query Multisig Info
# Show multisig details (signers, threshold, balance, etc.)
# Show specific proposal details (includes current block + time remaining)
List All Proposals
Cleanup (Recover Deposits)
# Remove single expired proposal
# Batch cleanup all expired proposals
Dissolve Multisig
# Requires: no proposals exist, zero balance
Economics
The multisig pallet uses an economic model to prevent spam and incentivize cleanup:
- MultisigFee: Non-refundable fee paid to treasury on creation
- MultisigDeposit: Refundable deposit (locked, returned on dissolution)
- ProposalFee: Non-refundable fee per proposal (scales with signer count)
- ProposalDeposit: Refundable deposit per proposal (locked, returned after cleanup)
Deposits are visible in multisig info output:
Balance: 1000 QUAN ← Spendable balance
Deposit: 0.5 QUAN (locked) ← Refundable creation deposit
Best Practices
- Use Descriptive Names: Use wallet names instead of raw addresses for better readability
- Set Reasonable Expiry: Use future block numbers (current + 1000 for ~3.3 hours at 12s/block)
- Verify Proposals: Use
info --proposal-idto decode and verify proposal contents before approving - Cleanup Regularly: Use
claim-depositsto recover deposits from expired proposals - Monitor Balances: Check multisig balance with
info --addresscommand - High Security: For high-value multisigs, use higher thresholds (e.g., 5-of-7 or 4-of-6)
Security Considerations
- Immutable Configuration: Signers and threshold cannot be changed after creation
- Full Transparency: All call data is stored and decoded on-chain (no blind signing)
- Auto-Execution: Proposals execute automatically when threshold is reached
- Access Control: Only signers can propose/approve, only proposer can cancel
- Expiry Protection: Client validates expiry before submission to prevent wasted fees
- Deterministic Addresses: Multisig addresses are derived from signers + threshold + nonce and are verifiable
Advanced Features
Decoding Proposals: The CLI automatically decodes common call types:
)
SS58 Address Format: All addresses use the Quantus network prefix (qz... for prefix 189) automatically.
Password Convenience: Omit --password "" for wallets with no password.
For more details, see quantus multisig --help and explore subcommands with --help.
🏗️ Architecture
Quantum-Safe Cryptography
- Dilithium (ML-DSA-87): Post-quantum digital signatures
- Secure Storage: AES-256-GCM + Argon2 encryption for wallet files
- Future-Proof: Ready for ML-KEM key encapsulation
SubXT Integration
- Type-Safe API: Compile-time type checking for all blockchain operations
- Metadata-Driven: Discovers available functionality from chain metadata
- Fresh Nonce Management: Automatic nonce handling to avoid transaction conflicts
- Progress Indicators: Real-time transaction confirmation with spinners
Smart Features
- Dynamic Balance Formatting: Automatically fetches chain decimals and token symbol
- Progress Indicators: Spinners during network operations
- Error Recovery: Comprehensive error handling with helpful messages
- Development Mode: Empty password detection for test wallets
- Event Decoding: Automatic SS58 address formatting in event output
- Fresh Nonce Management: Automatic nonce handling to avoid transaction conflicts
- Transaction Retry Logic: Exponential backoff for failed transactions
- Latest Block Reading: Consistent reading from latest (not finalized) blocks
Real Blockchain Integration
- Substrate Integration: Direct connection to Quantus node via WebSocket
- Metadata-Driven: Discovers available functionality from chain metadata
- Transaction Monitoring: Real-time transaction confirmation and fee calculation
- Extensible Architecture: Macro-based extrinsic submission supports any pallet
- Event System: Query events by block number, hash, or finalized status
- Storage Operations: Direct storage queries and sudo-based storage modifications
- Reversible Transfers: Schedule and cancel reversible transactions
- Scheduler Integration: Query and manage scheduled operations
🛠️ Current Status
✅ Fully Implemented:
- Quantum-safe wallet management with Dilithium cryptography
- Real blockchain operations (send, balance, storage, events)
- Tech Collective governance (add/remove members, voting)
- Generic pallet calls via metadata-driven parsing
- Reversible transfers with scheduling and cancellation
- Scheduler integration for automated operations
- System information and runtime management
- Event querying with SS58 address formatting
- Fresh nonce management and transaction retry logic
🎯 Real-World Ready
The Quantus CLI is a production-ready tool that:
✅ Handles Real Money: All transactions are real and irreversible
✅ Quantum-Safe: Uses post-quantum cryptography for future security
✅ Developer-Friendly: Rich tooling and clear error messages
✅ Scriptable: Environment variables and flags for automation
✅ Extensible: Clean architecture for adding new blockchain features
✅ SubXT-Powered: Modern, type-safe blockchain integration
⚠️ Security Note: This tool handles real cryptocurrency. Always:
- Back up your wallet files and mnemonic phrases
- Use strong passwords for production wallets
- Test with small amounts first
- Keep your private keys secure
🔧 Development Tools
Metadata Regeneration
The project includes a script to regenerate SubXT types and metadata when the blockchain runtime changes:
# Regenerate metadata and types from the running node
What this script does:
- Updates metadata: Downloads the latest chain metadata to
src/quantus_metadata.scale - Generates types: Creates type-safe Rust code in
src/chain/quantus_subxt.rs - Formats code: Automatically formats the generated code with
cargo fmt
When to use:
- After updating the Quantus runtime
- When new pallets are added to the chain
- When existing pallet APIs change
- To ensure CLI compatibility with the latest chain version
Requirements:
subxt-climust be installed:cargo install subxt-cli- Node must be fully synced and ready
Usage:
# Use default node URL (ws://127.0.0.1:9944)
# Use custom node URL
# Show help
Output:
Using node URL: ws://127.0.0.1:9944
Updating metadata file at src/quantus_metadata.scale...
Generating SubXT types to src/chain/quantus_subxt.rs...
Formatting generated code...
Done!
This ensures the CLI always has the latest type definitions and can interact with new chain features.