KaChat is extending its payment privacy model to the receiving side. The team says version 4.0 will let updated users share a pool of unused Kaspa addresses with their contacts, so a payment sent inside a one-to-one chat can land at a fresh address instead of the receiver's public chatting address. (KaChat on X)
The distinction matters because KaChat's current public design already protects the sender's identity address. Payments use a separate spending branch, and successful sends move change to a newly derived address. The Android implementation describes the identity address as account 0 and the spending chain as account 1, then advances the spending index after an accepted payment. (Android source) The iOS path follows the same model, deriving a never-used change address before building the payment. (iOS source)
That protects where the payment comes from, but the public code still sends it to the contact's chatting address. Android passes the contact identifier directly into payInKaspa, while iOS builds the transaction with contact.address as the destination. (Android payment path) (iOS payment path) Anyone who knows that identity address can therefore recognise the incoming payment and follow future funds held there.
KaChat's proposed pool closes that direct link. A contact with version 4.0 can advertise unused receive addresses in the background, and each one-to-one payment can select a fresh destination without exposing the chatting address as the recipient on the explorer. The sender-side spending chain and receiver-side address pool would then cover both ends of the obvious identity-address reuse problem. Users who have not updated will not provide that pool, so the improvement depends on adoption across both sides of a conversation. (KaChat on X)
The public repository does not yet support treating this as a shipped or audited feature. Android's KaChat 4.0 release is still marked as a pre-release, its published changelog does not mention the receive-address pool, and the latest public Android and iOS 4.0 branches checked after the announcement still contain the direct contact.address payment paths. (KaChat 4.0 pre-release) (Android repository) (iOS repository) The accurate status is announced and under development, not publicly verifiable as complete.
Fresh receive addresses remove a clear explorer-level identity link, but they do not create blanket transaction anonymity. Later consolidation or spending can still reveal relationships between addresses. The remaining questions - how the pool is authenticated, how addresses are marked used across devices, and how recovery avoids reuse - can only be judged when the implementation and tests appear in the public branches.
