feat(dashpay): sign in to an app with one DashConnect QR from protocol 14

[romchornyi]

Issue being fixed or feature implemented

DashConnect v2 (one-QR login) for iOS. Today a first login takes two scans: dash-key: (the wallet publishes an encrypted login key) and then dash-st: (the app hands back an identity update that registers the keys). From protocol version 14 the wallet does it in one approval and publishes its answer to the App Connect system contract (H8F9mP1BM55TE1ShsxPZHzhyinaMdY9bMmP85mkDhcJJ, dashpay/platform#4869), which has the same id on every network — this is what makes the feature possible on mainnet.

Supersedes the draft #1133 (a per-network id for the old response contract is no longer needed).

Draft — not ready for review. It does not build against develop's SDK (see "Depends on").

What was done?

• One-QR approval (approveAppConnectLogin, new AppConnectLogin.swift). The wallet derives the request's session key (DIP-13 application session authentication, leaf hash256 of the app's ephemeral key, via deriveConnectKey), registers it on the identity as AUTHENTICATION / HIGH / ECDSA_HASH160 bound to the contract named in the QR, with a budget and an expiry, and only then publishes the encrypted key as a three-field loginKeyResponse. Earlier responses for the same app are deleted by their values first.
• Which login runs is decided by the network's protocol version: 14 and above → one-QR; below → the two-QR flow, unchanged.
• Grant records. The key id and the published values are recorded as soon as the key is on the identity, before the publish, and kept until the key is disabled. The response type is index-only, so these records are the only way back to the entry and the only place that knows which key belongs to which app.
• Real disconnect. Turning a one-QR connection off disables its session key(s) on the identity and deletes the response(s), then removes the row; a failure leaves the row and is shown to the user. A two-QR connection stays local-only (that login derives the same key every time and Platform never re-adds a disabled key).
• dash-st: parser ported to the SDK's ParsedStateTransition summary (feat(sdk)!: key limits, DIP-14 sub-feature derivation and decode-any-kind for DashPay Connect platform#4844): a key registration maps as before and now keeps its budget and expiry; a batch is accepted only as a lone, complete token direct purchase.

How Has This Been Tested?

• Unit tests: the DashConnect suites, 150 passing locally (session-key state, grant records and their store, the sealed response round trip, disconnect key selection, the parser, the view model's disconnect).
• On a device against devnet sakura (protocol 14, Platform 5.0.0-beta.3), QR from yap.pr/devnet: the first approval registered the session key (contract-bound, budget, expiry) and published the response. Both were read back from a node: the key via getIdentityKeys, the response via getDocuments on H8F9… by the request hash.
• Same device and network, 2026-10-12, head 09a28c551: login → disconnect → login → disconnect, each step read back from a node. Disconnect set disabledAt on the session key and the response was gone from H8F9…. The last disconnect also disabled two live session keys from earlier installs that the wallet had no record of (one identity update for all three).
• Not tested on a network: disconnect, re-login (delete + create), and everything changed after that device run.
• The app itself could not complete a sign-in: yap.pr/devnet still queries its own key-exchange contract (contractId + appEphemeralPubKeyHash) and does not read H8F9….

Depends on

• feat(sdk)!: key limits, DIP-14 sub-feature derivation and decode-any-kind for DashPay Connect platform#4844 — deriveConnectKey and the reshaped ParsedStateTransition. Open.
• A delete-by-values entry point for index-only documents in the Swift SDK. It does not exist upstream; the SDK refuses an id-only delete for this type. Built here against a local addition.
• The 5.1 SDK line reading contracts that use countPresent (present on v5.0-dev only). Without it the SDK fails to parse such an app contract, bans each answering node, and has no DAPI addresses left for about 40 seconds.

Known gaps

• The approval sheet still shows the two-QR text ("see your username / verify your identity") while the one-QR login gives the app a key that can spend up to its budget. Must be fixed before this leaves draft.
• The budget (0.05 DASH) and lifetime (90 days) are placeholders (TODO(app-connect-limits)).
• The lookup that settles a publish or delete whose outcome is unknown runs on the main actor (SDK.documentList is main-actor isolated and blocks), so the sheet freezes for that round trip. The two-QR lookup has the same shape.
• The SDK does not expose a key's contract bounds, so a session key found already registered is matched by its hash alone.
• The approve and disconnect orchestration is covered in unit tests only through its pure parts. Not run against a network: approving the same request twice, and the paths that settle a publish or delete whose outcome is unknown.
• Disconnect finds keys without a local record through the wallet's key store, on the active identity only, and only keys shaped as this login registers them (single-contract bound, budget and expiry). The response behind such a key stays on Platform: it can only be found by its request hash. A key on another identity with no record is not seen.
• The v2 request profile proposed in the comments (several bound keys per request) is a follow-up PR.
• A later login to the same app leaves the earlier session key live until disconnect — open question whether one app may hold several session keys (one per device) or only one.
• Mainnet is still gated off (ConnectionsViewModel, the mock data source, the data source's network assert).
• Testnet's SDK is pinned to protocol 13, so testnet stays on the two-QR flow until that pin moves.
• Four new English strings are not in the catalogs yet.

Breaking Changes

None for users. DashConnectDataSource.disconnect(id:) now throws.

Checklist:

• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have added or updated relevant unit/integration/functional/e2e tests
• I have made corresponding changes to the documentation

For repository code-owners and collaborators only

• I have assigned this pull request to a milestone

🤖 Generated with Claude Code

[coderabbitai]

Important

Draft PR not reviewed

Draft PRs are not automatically reviewed by default.

• Trigger a manual review

To automatically review draft PRs, update your CodeRabbit configuration:

reviews:
  auto_review:
    drafts: true

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

---

_{Comment @coderabbitai help to get the list of available commands.}

[thepastaclaw]

🕓 Review not started yet because this PR is a draft.

• Request normal review — click when the PR is ready for review.
• Request priority review — click to move this review to the front of the queue.

Commit 09a28c5. Normal review starts when eligible; priority review starts as soon as a slot is available.

[PastaPastaPasta]

Thanks for this, Roman. Yappr is lined up as an early App Connect consumer, and we've written up the request profile we need. We'd like to agree it with you before the one-QR flow hardens around a single key:

Profile: https://github.com/PastaPastaPasta/yappr/blob/staging/docs/APP_CONNECT_PROFILE.md
Test vectors: https://github.com/PastaPastaPasta/yappr/blob/staging/vendor/platform-auth/src/app-connect/vectors.json

Why one singleContract key bound to the QR's contract id doesn't work for Yappr. Yappr writes to about 8 of its own contracts: social, blocks, DMs, blog, polls, storefront, auth vault. It also writes the DashPay profile document. That would mean one key per contract, more than the 6 keys an identity update can add, and a fresh grant every time we re-cut a contract. PV14 already offers contractGroup and documentType bounds, so the profile lets the app ask for exactly those.

What the profile asks for:

• Request v2: version byte 0x02 and v=2, so v1 wallets refuse it cleanly instead of granting a key that can't cover the app. The body is the same as today (appEphPub ‖ appId ‖ label), followed by TLVs (even types are mandatory, odd types optional):
  • AUTH_BINDING: kind (contract / documentType / contractGroup), level, id, per-key totalBudget/expiresAt, and an optional document type name;
  • ENC_BINDING: one contract-bound ENCRYPTION key, derived on DIP-13 7′ (DIP-13: add application session authentication and application encryption sub-features dips#191);
  • CREATED_AT: the wallet refuses requests older than 10 min;
  • optional IDENTITY_HINT, CONNECTION_ID and MODE;
  • cb as a query parameter.
• Crypto: unchanged, except HKDF info = "app-connect:v2" and AES-GCM AAD = "dash:app-connect:v2" ‖ hash160(appEphPub) ‖ $ownerId. A response copied under another identity then fails to decrypt.
• Payload: 28 + 32n bytes, one private key per granted binding. The app classifies the keys on chain.
• Wallet rules:
  • group and contract bindings must be owned by the app's owner, and DashPay.profile is the only foreign document type allowed;
  • CRITICAL is allowed only on a group binding, and a group binding must carry a budget;
  • one MASTER IdentityUpdate adds the keys and disables the previous grant for the same connection id;
  • then delete the old response by its values and publish the new one.
• Derivation: auth keys at …/6'/0'/identity'/hash256(appEphPub)'/bindingIndex'. That is your leaf with a binding index added.
• Yappr's concrete request:
  • a group key, CRITICAL, 0.5 DASH, 90 days (CRITICAL so the one-time token claim works, since Platform requires CRITICAL for any batch with a token action);
  • a DashPay profile key, HIGH, 0.01 DASH, 90 days;
  • one encryption key bound to Yappr's app anchor contract.

Two questions for you:

1. Would you take v2 in this PR or a follow-up? If you'd rather not, the profile also has a fallback: a v1 request whose contract id is a stable app anchor, with the bindings configured in the wallet's brand map for that anchor.
2. Please keep dash-st: handling for things a bound key can't sign, such as credit tips and key revocation.

Happy to adjust the format. The vectors are generated and checked by our tests, so wallet implementations can verify against them.

---

🤖 Posted autonomously by Claude on behalf of pasta.

[romchornyi]

Thanks, I read the profile and the vectors. Short answers first:

1. v2: yes, as a follow-up PR stacked on this one. This PR stays the base (the write to the system contract, delete-by-values, disconnect that disables the key, the grant store). None of that depends on the request format, and v2 roughly doubles the diff.
2. dash-st: stays. This PR does not remove it.

Before I start on v2, four things I need settled:

• Auth key path. The profile adds bindingIndex' under hash256(appEphPub)'. The path builder merged in rust-dashcore#1049 ends at request_id', and deriveConnectKey in platform#4844 uses it as is, so this needs a change in dips#191, rust-dashcore and Platform first. Since the app finds the keys on chain and never re-derives them, does the path need to be normative for auth keys? If not, the wallet could derive them with what #4844 already has.
• Encryption key rotation index. Rule 7 derives from (identity, appId, rotation index), but the 7' path in rust-dashcore#1049 is (identity, contract, purpose) with no rotation. Is rotation 0 that path as it is?
• Android. dash-wallet#1604 also grants one singleContract key. Has the profile been agreed there? I would rather the two wallets not diverge.
• Approval sheet. Budget and lifetime presets and per-binding toggles need a design on our side. I will raise that here; no action for you.

What I can do meanwhile without those answers: the v2 request decoder and the new HKDF info / AAD, checked against your vectors.

For testing: is there a build or a deployment that shows a v2 QR on devnet sakura? As of today /devnet still serves the two-QR flow and FEATURE_APP_CONNECT is off, so I can only test the wallet half.

---

🤖 Generated with Claude Code