docs(dashpay): sync specs to the implemented state of this PR

Make the DashPay design docs match what actually shipped on this branch:
- SYNC_CORRECTNESS_SPEC (Spec 0): REVIEWED→IMPLEMENTED — both stages shipped
  (paginated/high-water request sync + id-keyed contact-profile cache), durably
  persisted to both the SQLite persister and SwiftData.
- CONTACTINFO_FORMAT_SPEC (Spec 1): the §4 contactInfo reject/block field marked
  DEFINED-but-NOT-ADOPTED — R1 resolved ignore as local-only, so it is not carried
  on contactInfo; the shipped codec is alias/note/displayHidden/acceptedAccounts.
- BLOCK_SPEC: PAUSED→SUPERSEDED — replaced by the implemented per-sender, reversible,
  local-only Ignore (Spec 2); the contactInfo cross-device route was rejected (R1);
  cross-device deferred to a future encrypted profile field (contract track).
- SPEC.md: added a 2026-06-18 status block mapping the Part-0 gap table (G1–G15) to
  its resolution, plus accountReference (keep-ours) and the account-index path fix
  (upstream rust-dashcore#813 via dashcore bump PR #3936). Points at TODO.md as the
  authoritative item-by-item status.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Author: shumkov

docs/dashpay/BLOCK_SPEC.md

@@ -1,14 +1,22 @@
 # DashPay "Block sender" — design spec
 
-Status: **PAUSED (2026-06-17)** — superseded in sequence by the cross-device
-rework. This single-device design is 4-lens reviewed (§0 R1–R10) and stays valid,
-but we now do block (and reject) **via `contactInfo`** so they sync across devices.
-New order:
-1. **`docs/dashpay/CONTACTINFO_FORMAT_SPEC.md`** — migrate privateData CBOR→DIP-15
-   + define the reject/block field. *(written, needs review)*
-2. **(TODO) reject → on-chain** via that field — must resolve the R1 non-established
-   privacy question first.
-3. **(this, revisited) block via `contactInfo`** — cross-device.
+Status: **SUPERSEDED (2026-06-18) — replaced by the implemented local-only Ignore.**
+This single-device design is 4-lens reviewed (§0 R1–R10) and stays valid as the
+reference, but the **shipped** feature is the simpler per-sender, reversible
+**Ignore** (= block) in `docs/dashpay/SYNC_CORRECTNESS_SPEC.md` / Spec 2 — see the
+TODO. The intermediate plan to carry block/reject **via `contactInfo`** for
+cross-device sync was **REJECTED**: R1 found that a `contactInfo` about a
+*non-established* sender leaks *who* you ignored (its public `$createdAt`/`$updatedAt`
+correlate with the inbound `contactRequest`'s timestamp via the public indexes), and
+the DIP-15 ≥2-contacts ambiguity gate doesn't cover a fresh non-established sender.
+What actually landed:
+1. **`CONTACTINFO_FORMAT_SPEC.md`** — privateData CBOR→DIP-15 varint. **IMPLEMENTED**
+   (carries alias/note/displayHidden/acceptedAccounts; does NOT carry ignore — R1).
+2. **Ignore = per-sender, reversible, LOCAL-ONLY.** **IMPLEMENTED** across all layers
+   (changeset, FFI, SwiftData, *and* the SQLite persister's `ignored_senders` table).
+3. **Cross-device ignore** — deferred to a future **encrypted field on the `profile`
+   document** (contract / governance track), whose update timing is conflated with
+   normal profile edits so it doesn't leak the per-sender existence/count. Not built.
 
 Owner: platform-wallet / swift-sdk
 Relates to: `docs/dashpay/SPEC.md` (G5 rejection), the existing per-request

docs/dashpay/CONTACTINFO_FORMAT_SPEC.md

@@ -95,9 +95,18 @@ bump locks old readers out. So:
 - decoders MUST be **tolerant**: read the fields the known minor defines, ignore
   trailing bytes; on an unknown **major**, discard.
 
-## 4. The reject/block fields (define here, populate later)
+## 4. The reject/block fields — DEFINED but NOT ADOPTED (R1, resolved 2026-06-18)
 
-Appended after `acceptedAccounts`, present from **minor 1**:
+> **Resolution.** This field was the proposed cross-device carrier for
+> reject/block. It is **not implemented** and is **not part of the shipped DIP-15
+> codec** (which carries only `aliasName` / `note` / `displayHidden` /
+> `acceptedAccounts`). Per R1, a `contactInfo` about a *non-established* sender
+> leaks *who* you ignored (the timing-correlation argument below), so **Ignore is
+> local-only** (Spec 2) and cross-device sync is deferred to a future **encrypted
+> field on the `profile` document** (contract / governance track) — NOT to
+> `contactInfo`. The design below is retained for reference only.
+
+Appended after `acceptedAccounts`, present from **minor 1** (design only — unused):
 
 | # | Field | Type | Meaning |
 |---|-------|------|---------|
@@ -109,19 +118,22 @@ the "both set" ambiguity, and extends cleanly (e.g. 3 = muted). `displayHidden`
 (field 3) stays as-is for backward DIP-15 compat; `relationshipState` is the
 richer superset we read first when present.
 
-**Scope boundary (critical):** this spec only **defines** the field + its
+**Scope boundary (critical):** this spec only **defined** the field + its
 encoding. *Whether and how* a `contactInfo` is created to carry it — especially
-for a **non-established** declined/blocked sender — is the **privacy question
-(R1 from the block review)** deferred to Spec 2/3:
+for a **non-established** declined/blocked sender — was the **privacy question
+(R1 from the block review)**, **RESOLVED (2026-06-18): not via `contactInfo` at
+all.** Ignore is local-only (Spec 2); cross-device goes through an encrypted
+`profile` field later. Kept for context:
 
 > A `contactInfo` *about a non-contact* is a brand-new on-chain document whose
 > existence + `$createdAt` can be timing-correlated with the inbound
 > `contactRequest` (public `userIdCreatedAt` index) to re-identify *who* you
 > blocked — even though `encToUserId` is encrypted, and the ≥2-contacts gate
-> (dip-0015.md:697-699) can't cover a non-contact. **Spec 2 must resolve whether
-> non-established reject/block is carried per-sender (leaky) or in a single
-> owner-scoped self-encrypted list (bounded leak), or only for established
-> contacts (no leak, partial coverage).** This format spec is agnostic to that
+> (dip-0015.md:697-699) can't cover a non-contact. **Spec 2 resolved this: a
+> per-sender `contactInfo` is leaky (above) and even a single owner-scoped list
+> on `contactInfo` still signals "an ignore happened", so ignore is kept
+> local-only and cross-device is deferred to an encrypted `profile` field whose
+> update timing is conflated with ordinary profile edits.** This format spec is agnostic to that
 > choice — it just provides the field.
 
 ## 5. Padding / 48-byte floor

docs/dashpay/SPEC.md

@@ -11,6 +11,27 @@
 > and lays out the remaining work + test plan. It is *not* a greenfield design —
 > it is a finish-and-polish plan.
 >
+> **Status update (2026-06-18) — the finish-and-polish work is essentially done
+> on `feat/dashpay-m1-sync-correctness` (PR #3841).** Resolution of the Part-0 gap
+> table: **G1, G2, G12, G13, G14, G15** (the P0 sync/wire/key-purpose blockers) and
+> **G3, G6, G7, G8, G9, G10** — all **DONE** (M1–M4). **G5** reworked and shipped as
+> a per-sender, reversible, **local-only Ignore** (Spec 2) across every layer incl.
+> the SQLite persister; cross-device sync deferred to a future encrypted `profile`
+> field (contract track — the `contactInfo` route was rejected for the R1 leak).
+> **G11**: the `network/` layer now has unit coverage; the live cross-client e2e
+> ride PR #3549 and stay blocked on devnet funding. **G4** (watch-only ECDH) is
+> **deferred** with an amended design (needs xpub hooks, not just an ECDH hook).
+> Three follow-on specs were written and **implemented** this pass:
+> **`SYNC_CORRECTNESS_SPEC.md`** (Spec 0 — paginated/high-water sync + contact-profile
+> cache + durable persistence), **`CONTACTINFO_FORMAT_SPEC.md`** (Spec 1 — privateData
+> CBOR→DIP-15 varint), and Spec 2 (Ignore). Also resolved: `accountReference`
+> byte-order (**keep ours** — recipient-ignored one-time pad, no interop break) and
+> the friendship-path `account'` hardcode (fixed upstream in **rust-dashcore#813**,
+> pulled in via the dashcore bump **PR #3936**). Remaining is all blocked on external
+> resources (devnet funding for e2e/UAT; contract governance for cross-device ignore
+> + DoS filter; an upstream rust-dashcore change for multi-account). See
+> [`TODO.md`](./TODO.md) for the authoritative item-by-item status.
+>
 > **How to read.** Part 0 is the TL;DR. Parts 1–2 are reference (protocol +
 > architecture). Part 3 is the current-state inventory. Part 4 is the prioritized
 > gap/bug list. Part 5 is the work plan. Part 6 is the Swift UI design. Part 7 is

docs/dashpay/SYNC_CORRECTNESS_SPEC.md

@@ -1,16 +1,23 @@
 # DashPay sync correctness — contact requests **and** profiles (mirror Android `PlatformSyncService`)
 
-Status: **REVIEWED** (5-lens multi-agent review folded in — see §9; ready to implement)
+Status: **IMPLEMENTED (2026-06-18)** — both stages shipped on
+`feat/dashpay-m1-sync-correctness` (PR #3841), 5-lens review (§9) folded in first.
+Stage 1 = paginated retrieve-all + per-identity high-water cursor + 10-min overlap
+at a 15s cadence (`network/contact_requests.rs`); stage 2 = id-keyed
+`contact_profiles` cache for established + pending senders (`network/contact_info.rs`,
+`accessors.rs`). Both are surfaced in the UI and **durably persisted** through the
+changeset pipeline to *both* backends (SQLite persister + SwiftData); the high-water
+cursor stays in-memory by design (a cold restore does one safe full re-fetch).
 Owner: rs-sdk / platform-wallet
 Priority: **FIRST** of the DashPay correctness track (ahead of the contactInfo
 format migration and the ignore feature).
 
 This spec covers **two consecutive stages of the same Android sync loop**:
 
-| Stage | Android (`PlatformSyncService`) | Us today | This spec |
-|-------|--------------------------------|----------|-----------|
-| 1. Contact-request fetch | `updateContactRequests()` — incremental, paginated, high-water | present but **broken** (truncates at 100, no high-water) | fix it |
-| 2. Contact-profile fetch | `updateContactProfiles(userIds)` — batch `whereIn $ownerId` | **absent** (we sync only our *own* profile) | add it |
+| Stage | Android (`PlatformSyncService`) | Us before | Delivered |
+|-------|--------------------------------|-----------|-----------|
+| 1. Contact-request fetch | `updateContactRequests()` — incremental, paginated, high-water | present but **broken** (truncated at 100, no high-water) | **fixed** — retrieve-all + high-water cursor |
+| 2. Contact-profile fetch | `updateContactProfiles(userIds)` — batch `whereIn $ownerId` | **absent** (synced only our *own* profile) | **added** — id-keyed cache, established + pending senders |
 
 Neither is an optimization: stage 1 is a **correctness bug** (real requests are
 permanently buried) and stage 2 is a **missing feature** (contacts have no name