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.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.TODO: confirm
exportRecord / exportRecords signatures before publish.What viewers can do
| Read intent details | Move funds | Re-share access | |
|---|---|---|---|
| Designated viewer | ✓ | ||
| Verifiable record recipient | ✓ | ||
| Original user (via viewing key) | ✓ | ✓ (sweep) | ✓ |
Submission-time viewers vs. post-hoc records
| At submission time | After the fact | |
|---|---|---|
| When the user decides | Before signing | Anytime later |
| What the viewer sees | Live status + final settlement | Final, verifiable record |
| Revocable | No, bound to the intent at submit | Yes, disclosure is just a shared object |
| Who controls disclosure | The user | The user |
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: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.