Disclosure consent and policies
Review an audit request, share a supported proof and understand what policy grants can do.
The holder decides what to answer#
To request an audit, supply a readable program with questions about an account at a finalized snapshot. The holder imports it, reads the questions and public effects, then chooses whether to generate supported proofs. A receiving address or control of a service gives you no permission to read private history.
The app uses this holder-run audit flow. Its outputs have zero policy attachments, and its audit interface cannot issue, save or revoke disclosure grants. If your application needs standing permissions, the reference policy language describes them separately. Do not show a grant-management workflow as an available app feature.
Review the audience, questions and snapshot#
A request names its audience, optional subject, finalized snapshot, expiry and optional nonce. Its questions are closed formulas, not a request to upload unrestricted history. Before answering, check the subject and deployment, then read what each answer reveals under the chosen effect manifest.
The audit relations can prove supported positive ownership and spend-history predicates within their limits. If a program contains an unsupported question, the compiler refuses the program instead of answering only part of it. Show Yes or proven, No answer, Refused and verification failure separately. No answer does not mean the predicate is false.
How reference policies describe permission#
In the reference language, a policy gives standing consent. Each permit names one auditor, the capabilities they may ask about and an effect manifest listing the public facts an answer can reveal. Each question must fit one grant. The evaluator cannot take the audience from one grant and the permissions from another.
Policies and queries compile into separate plans and digests. A note attachment can bind a policy digest to a per-note secret salt and deployment scope while keeping it opaque onchain. A zero attachment grants no questions in that interpretation. The Pool stores the attachment as bytes; an attachment alone does not admit a request or provide a proof backend.
| Artifact or step | What it tells you |
|---|---|
| Reference policy plan | Audience, capabilities, effects and policy digest |
| Query plan | Predicates, certification requirements and evidence needed |
| Holder audit | The holder consents; the compiler produces a supported plan or refuses |
| Independent verification | Whether the answer and snapshot pass checks for that request |
When the holder changes their mind#
The holder can decline the next request or stop sharing answers. A recipient may still keep an answer already delivered and the facts it reveals. Check the request's expiry and nonce in the verifier according to its supported rules. Those checks do not promise deletion of a delivered answer.
The app has no standing-grant revocation interface. A historical revocation contract may not belong to your release. If you add a policy service, document how its attachments work with proofs, how it checks audiences and stores state, and how revocation is enforced by the independent verifier before offering grants to users.
Ask for a small, useful proof#
Ask only for the predicates your product needs and explain why each matters. Let the holder check the audience, subject, snapshot and public effects before generating proofs. Keep the original program with its answer, and provide independent verification to the recipient.
If a question is unsupported or history is incomplete, show why it was refused and what can resolve it. A screenshot, self-reported JSON or partial checkpoint cannot replace the required proof. Continue to the disclosure guide for syntax, examples and verifier commands.