Wallet Reception Providers

Recall that only senders and recipients need and should know most details of a transfer. The only exception to this is that all participants must know that no transfer between any parties violates ZEC scarcity by double spending or other counterfeiting exploits.

Because transfers are non-interactively (see Usability (Footnote 1)) generated by senders, sending wallets must directly use their WDAP to persist that information locally. However, they must later learn that a transfer was finalized.

However, recipients must come to learn relevant details of a transfer, including:

  • a payload including:
    • the amount of ZEC and associated messages for the transfer, and
    • any cryptographic information necessary to control the received ZEC with their spend authority,
  • and that the transfer occurred and is finalized.

In traditional Zcash shielded transfers, this data is all encrypted and posted globally to the blockchain which provides global data availability to all wallets. This violates the principle of unifying scalability, data availability, and privacy by sacrificing the first for the latter two.

In Zcash MSPA, by contrast, a sending wallet transmits the payload directly to the recipient's Wallet Reception Provider (aka WRP), which enables scalability by leaving all data specific to sender and recipient out of global state tracking.

WRP Requirements

A WRP must:

  • be highly available to receive transfers at any time,
  • persist an incoming transfer in the receiving wallets WDAP,
  • submit any necessary data to the consensus layer to ensure it is finalized,
  • then (and only then) notify the receiving wallet at the earliest possible time.

This design is aimed at achieving two essential goals:

  • First, by being highly available, a WRP enables transfers to any recipient at any time, regardless of if the recipient's wallet UI is active.
  • Second, by persisting the payload in the recipient's WDAP prior to finalizing a transfer, the WRP & WDAP ensure consistency of the payment protocol by avoiding the case where consensus finalizes a transfer that cannot be retrieved by a receiving wallet.