Auditor and counterparty access

Designated viewers are the simplest way to satisfy compliance requirements without making user data public. They are set per intent at submission time and grant scoped read access, viewers can see the intent details, but cannot move funds, modify the transaction, or grant onward access. For step-by-step API usage, see the viewing-permissions guide. This page focuses on the operational and compliance angle.

When to attach viewers

Scenario	Recommended viewers
Institutional payroll	Internal finance / HR ops wallet, optionally external auditor
Treasury bridge transfers above reporting thresholds	Compliance team wallet
Regulated jurisdictions	Designated regulator wallet (per requirement)
B2B payments where the counterparty wants a verifiable receipt	Counterparty’s wallet

What viewers see and don’t

Action	Designated viewer
Read intent details (amount, sender, recipient, asset, chain, status)	✓
Read settlement details (destination tx hash, settled-at)	✓
Move or sweep funds
Cancel or modify the intent
Grant onward access
See other intents the user submitted

Scope is per intent. Granting a viewer access to one intent does not grant access to any others.

Default viewers for an institutional account

If your product serves an organization that needs every intent audited, configure default viewers at the workspace level so every signed intent inherits them automatically:

tachyon.intent.setDefaultViewers(["0xComplianceWallet..."]);

setDefaultViewers is a planned SDK convenience that appends default viewers to every intent.build call. Until the SDK ships, set the viewers array on each intent you construct.

Verifiable records (post-hoc disclosure)

If you need to provide visibility after an intent settles, for example, to a tax authority for the prior year, the user (or you on their behalf) can export verifiable records using their viewing key:

const records = await tachyon.user.exportRecords({
  from: "2026-01-01",
  to:   "2026-12-31",
});

Hand the resulting object to the counterparty through whatever channel you prefer. They can verify it without it being on-chain.

Operational checklist

Identify which intents need viewers attached (by amount, by category, by user role)
Configure workspace-level default viewers for any “always audit” categories
Build a UI toggle for ad-hoc viewer addition
Provide a “share receipt” flow that calls exportRecord after settlement
Document for your users which categories of activity carry default viewers

Limitations

Viewers added at submission time cannot be removed. If your compliance requirement might evolve, prefer post-hoc records, they are revocable in the sense that the user controls re-sharing.

The viewer must hold a Tachyon viewing key to read inbound disclosures (the SDK handles generation).
Default viewer lists apply only to intents signed after the configuration change, they do not apply retroactively.

Viewing-permissions guide

API-level walkthrough.

Overview

Concepts

Security

More

Auditor and counterparty access

When to attach viewers

What viewers see and don’t

Default viewers for an institutional account

Verifiable records (post-hoc disclosure)

Operational checklist

Limitations

Viewing-permissions guide

​When to attach viewers

​What viewers see and don’t

​Default viewers for an institutional account

​Verifiable records (post-hoc disclosure)

​Operational checklist

​Limitations

Viewing-permissions guide

When to attach viewers

What viewers see and don’t

Default viewers for an institutional account

Verifiable records (post-hoc disclosure)

Operational checklist

Limitations