Skip to main content
Viewing permissions let your users grant scoped read access to specific intents, to an auditor, accountant, regulator, counterparty, or their own secondary wallet. This is how confidentiality and compliance coexist.

Two ways to disclose

1. At submission time, designate viewers

Attach viewer addresses when you build an intent. Those addresses gain decryption access scoped to that intent only.
The viewers can then read this intent’s details from their own SDK session.

2. After the fact, share via viewing key

The user can use their viewing key to produce a verifiable record of any intent (or range of intents) and share it out of band, for accounting, tax, or counterparty verification.
Or for a range:
TODO: confirm exportRecord / exportRecords signatures before publish.

What viewers can do

Submission-time viewers vs. post-hoc records

Submission-time viewers cannot be removed once the intent is signed and submitted. Review the viewer list before confirming.

Patterns for integrators

Default auditor for institutional accounts

For an enterprise account, set a default viewer at the workspace level so every signed intent inherits it:
Planned SDK convenience. Until it ships, include the viewer addresses in the viewers field on each intent.build call.

Receipt for the counterparty

After settlement, hand the recipient a verifiable record:
The recipient can verify the record without it being on-chain.

Tax export for the user

Provide a button that exports a year of records:

Scope guarantees

A viewer or record consumer can only see what they were granted. Granting visibility to one intent never grants visibility to others. This is enforced cryptographically, not by application policy.

Compliance overview

Where viewing permissions fit in your overall compliance posture.