Tracking: Dash Platform usernames and DashPay contacts in dash-qt (--enable-platform-gui)

[PastaPastaPasta]

What / why

Dash-QT has long lacked first-class Dash Platform support: usernames (DPNS), DashPay profiles, and contact-to-contact payments — the feature set of the DashPay mobile wallets — without coupling Dash Core to Platform.

A complete, working implementation exists and has been E2E-tested against live testnet Platform (usernames registered, profile published, contact request sent/accepted, payment to a contact-derived address received): PastaPastaPasta#67 is the canonical reference implementation. It is far too large to review as one PR, so it is being landed as a train of small, individually reviewable PRs across two repos (dashpay/platform and dashpay/dash), tracked here. This issue is the living map: where we are, where we're going, and the design decisions made along the way.

History: the original reference was PastaPastaPasta#49 (~17.9k lines of pure C++, including hand-ported GroveDB proof verification, protobuf/bincode codecs, and vendored BLAKE3). On 2026-08-07/08 the architecture pivoted (see decisions log): the hand-written C++ reimplementations were replaced with the canonical Platform Rust crates, and Platform itself was refactored upstream to be embeddable transport-free. #49 remains open only as provenance; #67 supersedes it.

Where we are (2026-08-12)

State	PR	What it is
✅ Merged	#7511	DIP-14 256-bit child key derivation (Derive256)
✅ Merged	dashpay/platform#4344	dapi-grpc transport feature — verifier dependency tree drops 407 → 339 crates; no tokio/hyper/rustls in embedder graphs
✅ Merged	dashpay/platform#4345	Proof-vector regression corpus for rs-drive-proof-verifier
🟢 Open	#7580	Optional Rust + cxxbridge build foundation (successor to #7109) — CI green, awaiting human review
🟢 Open	#7581	Wallet Platform key provider, data records, DIP-15 friendship seams
📝 Draft	dashpay/platform#4335	Carrier branch for the remaining upstream slices (queries split, decode, builders)
🧪 Reference	PastaPastaPasta#67	Canonical reference implementation — security-hardened, full testnet E2E proven; rebases onto #7580 once it merges

Architecture (current)

• Compile-time optional GUI feature: --enable-platform-gui. dashd and dash-cli link zero Rust in any configuration; default developer builds do no Rust work at all. For the final v24 release, dash-qt release builds ship with Platform GUI enabled (decision 2026-08-12), so Guix reproducibility with the flag on is a release gate.
• Rust (canonical crates, not reimplementations): proof verification, response decoding, and state-transition/document construction are done by the real dashpay/platform crates (dpp, drive verify, grovedb verify), pinned by revision and bridged via cxx (rust/platform — an interim location, see End state). Built with panic = "unwind" so malformed bytes from remote nodes surface as catchable C++ exceptions rather than aborting dash-qt.
• C++ keeps what Core should own: gRPC-Web/HTTP1.1/TLS (mbedtls) transport; evonode endpoint selection, ban/backoff and cross-node retry from the locally synced deterministic masternode list; wallet signing seams; Qt GUI.
• No trusted intermediary: every query uses prove=true. Verification runs through the upstream FromProof machinery with a ContextProvider fed locally synced LLMQ Platform quorum keys from C++ — the trust anchor is unchanged from the original design; only where the check executes moved. Platform quorum signatures are checked in Rust against local keys, never against a remote key service.
• Additive wallet/node seams: DIP-13/14/15 key derivation, sign-only interfaces (raw keys never cross the FFI — Rust computes signable digests, C++ signs), asset-lock transaction creation, opaque per-wallet platform data records, DIP-15 friendship receiving-keychain import. The contact's own receiving chain is deliberately never imported — its scriptPubKeys must not be IsMine, or payments to the contact decompose as payments-to-self; contact destinations are derived statelessly from the stored xpub.
• Correctness pinning: byte-exact fixture equivalence against Rust-generated vectors (31/31 C++ suite cases, 32/32 crate tests on the reference), the upstream proof-vector corpus (test(sdk): add proof-vector regression corpus for drive-proof-verifier platform#4345), and the live-testnet E2E harness.

End state (target)

Where everything should live when the train is done:

1. No first-party Rust wrapper code maintained in dashpay/dash. All wrapper/FFI logic lives upstream in dashpay/platform; Core pins a released upstream revision plus a thin bridge. The in-repo rust/platform crate is explicitly interim. The mechanism — a new minimal rs-platform-primitives-ffi package vs. adapting the existing rs-sdk-ffi/ContextProviderCallbacks surface — will be decided by building a target-state E2E prototype, not by RFC debate.
2. Request construction moves to Rust (dash-platform-queries): today C++ still hand-builds some request bytes (protobuf field encoding, CBOR where-clauses, contested-resource bincode). That drift surface goes away when Core consumes the upstream query core.
3. Seed-only recovery of Platform state is implemented (see Release gates).
4. Core's pin points at merged, released upstream code — not a draft branch.

Plan — dashpay/platform track

• dapi-grpc transport cargo feature for types-only consumers — feat(sdk): add transport feature to dapi-grpc for types-only consumers platform#4344 (merged 2026-08-11)
• Proof-vector regression corpus for rs-drive-proof-verifier — test(sdk): add proof-vector regression corpus for drive-proof-verifier platform#4345 (merged 2026-08-09)
• dash-platform-queries crate split from rs-sdk (transport-free query core: DocumentQuery, aggregate proof helpers, DPNS free functions) — refactor(sdk)!: extract transport-free query core into dash-platform-queries platform#4388 (open 2026-08-12)
• Client-side GetDocumentsRequest → DocumentQuery decode + pure DPNS/DashPay document builders — refactor(sdk): shared wire-request decode and pure DPNS/DashPay document builders platform#4389 (open 2026-08-12, stacked on refactor(sdk)!: extract transport-free query core into dash-platform-queries platform#4388)
• Close out feat(sdk): transport-free verification and query core for embedders platform#4335 once all slices have landed
• FFI home: target-state E2E prototype → decision (rs-platform-primitives-ffi vs. adapt rs-sdk-ffi) → implementation
• Hygiene: dpp license metadata, unpinned vsss-rs branch="main", MSRV policy
• Offline-clean tenderdash proto path upstream (Core currently solves this with a hash-pinned TENDERDASH_DIR depends source)

Plan — dashpay/dash train

Each PR carries its own build-system, lint, and CI increments.

Foundations

• feat: add DIP-14 256-bit child key derivation (Derive256) #7511 — feat: DIP-14 256-bit child key derivation (Derive256) (merged 2026-08-12)
• build: add optional Rust and CXX bridge support #7580 — build: optional Rust + cxxbridge component support (--enable-rust, depends toolchain/vendoring, linux64_rust CI lane)

Wallet/node seams (additive; stubbed when the flag is off)

• feat(wallet): add Platform key provider, data records and DIP-15 friendship keychain seams #7581 — feat(wallet): DIP-13/14/15 platform key provider, opaque platform data records, DIP-15 friendship keychain seams
• refactor: node interface seams (Platform endpoints, quorum keys, islocks) — refactor: expose masternode Platform endpoints, quorum keys and islocks via node interface #7591 (open 2026-08-12)
• feat(wallet): seed-only Platform state recovery (identity rediscovery via proof-verified queries, descriptor recreation + rescan, pay-cursor reconstruction, recoverable preorder salt) — required before the wallet wave completes (decision 2026-08-12)

Platform client (linked only into dash-qt)

• feat: C++ transport (gRPC-Web/TLS/mbedtls, endpoint selection/retry) + thin Rust verification adapter pinned to the upstream transport-free core

GUI

• feat(qt): platform service, identity registration, username flow, dashboard, profile editing
• feat(qt)/feat(wallet): friendship keychain import, contacts, contact requests, send-to-username

Release enablement

• build: enable Platform GUI in release dash-qt builds; Guix reproducibility with the flag on across all release targets

Release gates (v24)

• Guix build testing: deterministic Guix builds with Platform GUI enabled (Rust toolchain, vendored crates, mbedtls, protoc all through depends/Guix, offline). Required because release builds ship enabled.
• Seed-only recovery implemented and covered by functional tests (full-backup restore, mnemonic-only restore, recovery at each identity-registration stage). Current state: all key material is seed-derivable; identity record, contact state, pay cursors, and the random preorder salt are not — that gap is what this gate closes.
• Malformed-input fuzzing of the verify_*/decode_* bridge surface (attacker-controlled bytes from remote evonodes).
• DAPI transport authentication decision: TLS to evonodes is currently unauthenticated by design (reads are proof-gated; broadcast parsing has been hardened). With the GUI on by default in release builds, the certificate-pinning/authentication story needs an explicit decision before final v24.
• Source distribution completeness: flag-on builds from release tarballs (known: platform/recoveryplan.h missing from the reference branch's dist tree).

Timeline (v24)

• RC1 target: Thu/Fri Aug 20–21 (feature cutoff ~Aug 18). Bar for RC1: the full train merged, compile-time flag available.
• Final v24: Platform GUI enabled by default in release dash-qt builds.
• Critical path note: seed-only recovery is the only item on the RC1 path that is not yet implemented somewhere; it starts now.

Decisions log

• 2026-08-01 — IsMine watch-only guard deferred. Extracted as fix(wallet): report public-only descriptors in signing wallets as watch-only #7510, then closed: nothing in the series consumes it — the friendship receiving chain imports as a private descriptor and the contact's chain is never imported. Returns alongside any future xpub-only import work.
• 2026-08-01 — DIP-14 compatibility-mode semantics. feat: add DIP-14 256-bit child key derivation (Derive256) #7511 treats sub-2^32 indexes as raw BIP32 index space (hardened flag folded into the high bit on the private side; public side rejects high-bit indexes as BIP32 does). The DIP's Compatibility section and published test vectors require this interpretation (vector 2 only reproduces under it).
• 2026-08-01 — No QWizard. Registration flow is QDialog + QStackedWidget because depends/Guix Qt is built with -no-feature-wizard.
• 2026-08-07 — Rust crates over C++ reimplementations (the pivot). ~6,300 lines of hand-written security-critical C++ (GroveDB verifier port, bincode/DPP codecs, vendored BLAKE3) would have had to track consensus-critical upstream behavior byte-for-byte by hand, forever. Replaced with the canonical crates behind a cxx bridge (+498/−6,306 on the reference branch), with PR Update README.md #49's own fixtures as a byte-exact conformance harness. Supersedes the earlier "vendor BLAKE3 / port GroveDB" plan (waves 1/3 of the original train).
• 2026-08-08 — Refactor upstream instead of duplicating (per Platform maintainer feedback). Rather than carrying wrapper code in Core, Platform itself was made embeddable: dapi-grpc grew a transport feature (feat(sdk): add transport feature to dapi-grpc for types-only consumers platform#4344 — Cargo features aren't target-scoped, so transport must be opt-in or it forces tonic's stack onto wasm consumers), rs-sdk is being split (dash-platform-queries), and verification runs through upstream FromProof + ContextProvider over locally synced LLMQ keys — which let Core delete its own quorum-sig verification C++.
• 2026-08-08 — panic=unwind for the bridge. verify_*/decode_* parse attacker-controlled bytes deep inside a large dependency tree that cannot be exhaustively audited for panics; unwind converts residual panics into catchable C++ exceptions instead of aborting dash-qt. dashd is unaffected (links no Rust).
• 2026-08-11 — Keep mbedTLS transport; Drogon rejected for now. feat(rest): move REST server to libbitcoin_query, switch to Drogon as an optional dependency, add helper to directly serve disk contents #7220 pins Trantor with TLS=none (cannot reach https DAPI at all); Drogon's client cannot cancel in-flight requests and parses untrusted lengths unboundedly. Core's transport keeps its 32 MiB cap, absolute deadlines, and cancellation. A clean swap seam exists at GrpcWebUnary() if this is ever revisited.
• 2026-08-11 — build: add optional Rust and CXX bridge support #7580 supersedes build: add rudimentary support for Rust components in build system, crate vendoring, patch loader paths to Guix store locations #7109, preserving the original build-work provenance, rebased and made genuinely opt-in with its own CI lane.
• 2026-08-12 — Asset-lock seam not extracted from the fork. Merged feat: asset lock tx v2 with basic RPC support + tests #7294 (asset lock v2) supersedes it; the fork's version would silently emit v2 payloads pre-activation.
• 2026-08-12 — Platform GUI ships enabled in final v24 release dash-qt builds. DashPay must be usable by end users in v24, not a compile-time easter egg. RC1 bar is the full train merged; release enablement (incl. Guix) follows as its own gated step.
• 2026-08-12 — Seed-only recovery is pre-merge for the wallet wave, in v24. "Your recovery phrase restores your wallet" must hold for Platform state before the wallet wave completes.
• 2026-08-12 — FFI end state: upstream, mechanism TBD. Wrapper logic moves to dashpay/platform and Core pins a released revision; whether that is a new minimal primitives-FFI package or an adaptation of the existing rs-sdk-ffi surface will be settled by a target-state E2E prototype.

Status detail (2026-08-12)

• build: add optional Rust and CXX bridge support #7580: CI green, all automated-review threads resolved, mergeable — awaiting human review. One pre-review fix is queued: macOS deployment-target propagation into Rust artifacts (Rust currently falls back to the host SDK version instead of OSX_MIN_VERSION), plus trimming speculative cross-target entries.
• feat(wallet): add Platform key provider, data records and DIP-15 friendship keychain seams #7581: open, CI mostly green, latest automated review round under triage.
• feat(qt): back Dash Platform GUI internals with real grovedb/drive/dpp crates PastaPastaPasta/dash#67: canonical reference; currently conflicts with develop (branched before build: add optional Rust and CXX bridge support #7580's hardening) — rebase planned after build: add optional Rust and CXX bridge support #7580 merges.
• feat(sdk): transport-free verification and query core for embedders platform#4335: draft carrier; next slice to extract is the dash-platform-queries split.
• Review assignment (2026-08-12 dev sync): kwvg reviews the DashPay series, starting from the foundations.

[PastaPastaPasta]

Seed-only recovery of Platform state — design answer

Raised at the 2026-08-12 dev sync (kwvg): DashPay wallet data is stored as opaque per-wallet records — how does mnemonic-only recovery restore Platform state? Investigated against both the current implementation and the mobile wallets' shared recovery policy (rs-platform-wallet, the crate behind dashwallet-ios/android). Design below ships in v24 with the wallet wave; implementation is on the reference branch (PastaPastaPasta#67) first, then extracted into the train.

What is derivable from seed alone: every private key (identity auth m/9'/coin'/5'/0'/0'/i'/k', asset-lock funding, DIP-15 friendship chains). What is not: the local records — identity id/state, contact set, payment cursors, and the DPNS preorder salt (CSPRNG).

Recovery flow (auto-probe on wallet load when a seed exists but no identity record; bounded ~20s, never blocks wallet function; mirrors mobile's policy):

1. Identity: scan MASTER auth keys (key index 0, identity index gap limit 5) via the proof-verified getIdentityByPublicKeyHash query, with a three-way outcome — found / proven-absent / network-incomplete — so an outage is never misreported as "no identity". Materialize the full on-chain key set with per-key verification against published pubkeys.
2. Username: namesOfIdentity (+ contested-state check) rebuilds the registration record.
3. Contacts: contact requests fetched in both directions (the sent side is what turns established contacts back from bare incoming requests); xpubs decrypted via the seed-derived ECDH keys; friendship receiving keychains re-imported as private descriptors.
4. Rescan from the earliest contact-request core height, so pre-restore inbound DashPay payments appear.
5. Payment cursors: rebuilt by matching derived outbound scripts (5× the DIP-15 gap = 100 per contact, scriptPubKey-based) against wallet tx history.

Documented limitation (same as both mobile wallets): an in-flight DPNS registration (preorder broadcast, domain not yet) is not recoverable seed-only — the salt is random. A REGISTERED identity recovers fully; mid-registration needs the full backup. Follow-up idea recorded, not v24: derive the salt deterministically (e.g. HMAC of an auth key and the normalized label) — consensus-transparent, would make even mid-registration state recoverable, and no client does it today.

Full backup/restore (backupwallet/restorewallet) remains the complete-state path and is unaffected.

---

🤖 Posted autonomously by Claude on behalf of pasta.

[PastaPastaPasta]

Guix reproducibility confirmed for the Rust/Platform-enabled build.

Two independent builders built commit c9d6fbd459d9 with PLATFORM_GUI=1 HOSTS=x86_64-linux-gnu — the GitHub-hosted ubuntu-24.04-arm runner (workflow run 31720606525) and a local OrbStack container — and all three artifacts are bit-identical, including the debug tarball:

ee1a85a060178923b6eb10a84d3781a087103b1393657be3f726a2199f8c3701  dashcore-23.1.8-1380-gc9d6fbd459d9.tar.gz
620f0b732db138ac637001266e488c6e80437858a36e417a1c3ec06d190ec64a  dashcore-23.1.8-1380-gc9d6fbd459d9-x86_64-linux-gnu-debug.tar.gz
c1033b0e6a92968a4e41766fdc41db1329ebc5f1625875457f8ddc4eef078f4e  dashcore-23.1.8-1380-gc9d6fbd459d9-x86_64-linux-gnu.tar.gz

Scope of the claim: both builders are aarch64 hosts cross-compiling to x86_64-linux-gnu, so this proves host-to-host reproducibility between independent environments, not yet reproducibility across differing build architectures — an x86_64-host run of the same commit would close that gap.

Getting there required five bring-up fixes on this branch, all of which are Guix-environment issues rather than Rust-integration ones: patchelf and zlib added to the Guix manifest (the prebuilt rust toolchain's ELF interpreter fix silently skipped without patchelf, and rustc needs libz at runtime), lbzip2 added (mbedtls is the first .tar.bz2 depends package to reach the Guix path), the rustc sysroot lib dir on LD_LIBRARY_PATH for cargo build scripts (the Guix ld wrapper strips RPATH by design), and an archive rescan for the cxxbridge↔dashrust mutual references.

One latent hazard worth recording: Rust does not get a --remap-path-prefix equivalent to the C++ -ffile-prefix-map. It cannot bite in the standard flow because every builder compiles at the same in-container path, but a builder using a non-canonical mount point would see a differing debug tarball while the stripped tarball still matched.

---

🤖 Posted autonomously by Claude on behalf of pasta.