Add ML-DSA-65 cold signing support and NEAR integration

[illuzen]

Summary

Part 1: ML-DSA-65 cold wallet signing

• The cold signing QR flow now accepts both ML-DSA-87 and ML-DSA-65 signature responses. The scheme is detected from the response length (7219 bytes for 87, 5261 for 65), so no wire-format or QR envelope changes are needed — cold devices can add ML-DSA-65 signing later without protocol coordination.
• quantus cold-sign-sim signs with whichever scheme the wallet uses.
• Added verify_ml_dsa_65 alongside the existing 87 verification in src/chain/signing.rs (shared via macro).

Part 2: NEAR integration (quantus near)

NEAR protocol v85 added ML-DSA-65 access keys, so a Quantus ML-DSA-65 wallet can directly control a NEAR account. New subcommands:

• show-key — print the wallet's NEAR public key (ml-dsa-65:<bs58>) and its on-chain handle (ml-dsa-65-hash:<bs58>).
• create-account — create a NEAR sub-account whose only access key is the Quantus wallet's ML-DSA-65 key, funded/signed by a parent account's ed25519 credentials (near-cli JSON format). After creation it verifies via view_access_key_list that exactly one full-access key exists and it matches the wallet.
• keys — list an account's access keys.
• send — transfer NEAR, signed with the wallet's ML-DSA-65 key (pure FIPS 204, empty context, over sha256 of the borsh-encoded TransactionV0).

Implementation uses minimal hand-rolled borsh wire types pinned to nearcore's layout (validated with hand-built byte goldens plus independently computed sha256/sha3 golden vectors) and a small JSON-RPC client with a protocol-version preflight — no heavy near-* crate dependencies.

Part 3: NEAR multisig from cold wallets

Roadmap only (no code) — documented in the planning doc; will build on the cold-signing scheme detection from Part 1.

Testing

• 373 lib tests pass, including new borsh golden vectors, key/handle vectors, ML-DSA-65 signing roundtrips (cross-checked against the upstream ml_dsa_65 verifier), and cold-signing scheme-detection tests.
• ./clippy.sh clean.
• quantus near --help smoke-tested. Live testnet account creation not yet exercised (needs a funded parent account).

Made with Cursor

[n13]

Reviewer model: GPT-6 Sol

Verdict: Request changes. The NEAR wire layout and ML-DSA-65 signing path match the protocol reference, but the transfer command can report success without a successful transaction outcome.

• P2 — Reject missing or non-successful send_tx outcomes (src/near/rpc.rs:81,208-215; src/cli/near.rs:409-411). call() converts an absent JSON-RPC result to null, and send_tx() only rejects status.Failure. A 200 response with no result, or a result with missing/unfinished status, therefore returns Ok; near send then prints “Transfer finalized” even though no finalized transfer was confirmed. Require a present result and an explicit successful final execution status before returning Ok; reject unknown/unfinished shapes and cover those cases in an RPC test.

Validation: git diff --check and pinned cargo +nightly-2026-08-31 fmt --all -- --check passed. Eight focused NEAR tests and the ML-DSA-65 cold-signing test passed. The local library suite passed 372/373 tests; the unrelated batch-verifier test requires generated circuit binaries excluded by SKIP_CIRCUIT_BUILD=1. On GitHub, format, security, analysis, and macOS build/test passed; Ubuntu build/test and examples were pending at review time.

[illuzen]

Addressed the review: send_tx now only returns Ok for an explicit finalized success — the result must be present, status must be SuccessValue (a Failure, missing, or unstarted status is rejected), and final_execution_status must be FINAL. Anything else errors with a hint to check the explorer before retrying, so near send can no longer print "Transfer finalized" without a confirmed finalized transfer. Added 7 unit tests in src/near/rpc.rs covering the accepted and rejected outcome shapes. Full lib suite passes (380 tests) and ./clippy.sh is clean.

[n13]

Reviewer model: GPT-6 Sol

Verdict: Approve. The previous send_tx false-success finding is resolved. The current head rejects missing, failed, unfinished, and non-final execution outcomes before near send or create-account can report success. I found no blocking issues in the current diff.

Validation: git diff --check, cargo +nightly-2026-08-31 fmt --all -- --check, and SKIP_CIRCUIT_BUILD=1 cargo clippy --all-targets --locked -- -D warnings passed. All 15 focused NEAR tests and both cold-signature response tests passed. The NEAR key sizes, handle derivation, and wire tags were checked against NEP-645 and nearcore. A funded live account-creation test was not available. At posting time, GitHub format, security, and analysis checks had passed; macOS, Ubuntu, and examples were still running.