Skip to main content

Register your viewing key on-chain

What this lets you do​

Publish your viewing public key into the on-chain keystore contract. Once registered, senders can encrypt note payloads directly to you: no need to share secrets out-of-band, no need for you to do anything per incoming payment. Your discoverNotes() just finds them.

Constraints & limits​

  • Two on-chain transactions: setAuthPolicy and setViewingKey, both signed by your wallet. The gas is a one-time cost that varies with network conditions.
  • Public: the pairing of your viewing pubkey and wallet address is permanently on-chain. Anyone scanning the chain can know "address X has registered for shielded receives."
  • Per-address: registration is keyed by your EVM address, so moving to a different wallet means registering again with that wallet's derived viewing key. That is separate from rotating keys on the same wallet: you can rotate your revocable key in place without re-registering.
  • X25519 format: the viewing pubkey must be 32 bytes.

What it unlocks next​

  • Discoverable mode for private transfers sent to this address, so senders no longer need to pass you the noteSecret.
  • Payment requests with tag-targeted on-chain delivery.

How to use it​

// Check first to avoid paying gas twice. The session knows its own
// ownerAddress, so this method takes no arguments.
const registered = await session.isKeystoreRegistered();
if (!registered) {
    const result = await session.registerKeystore();
    // result contains both tx receipts (setAuthPolicy + setViewingKey)
    console.log("registered:", result);
}

Trade-off to think about: registration adds public surface (everyone can see that your address uses Privacy Pools) in exchange for receive-side UX (no OoB hand-off per payment). For payroll-style "I send to lots of people, they don't all want to register," consider the receipt model instead, where recipients claim their notes from the receipt without registering.

Behind the scenes​

SDK call session.registerKeystore()
Contract methods Keystore.setAuthPolicy(...) then Keystore.setViewingKey(...)
On-chain effect setAuthPolicy inserts your auth-policy leaf into the keystore tree, and setViewingKey records your viewing pubkey in the separate viewingKeys(address) mapping (the viewing key is not a tree leaf). Future prepareTransfer calls with recipientDiscoveryData: {evmAddress: you} then resolve your viewing key and use discoverable mode.