Transaction Governance
Wallet Transaction Evidence Requirements
Wallet transaction evidence requirements define what reviewers and signers need to see before a transaction can move from request to approval. Instead of relying on chat summaries or verbal context, teams should require purpose proof, destination validation, execution previews, and escalation notes that match the transaction’s actual risk class.
What does this control solve?
Wallet transaction evidence requirements define what reviewers and signers need to see before a transaction can move from request to approval. Instead of relying on chat summaries or verbal context, teams should require purpose proof, destination validation, execution previews, and escalation notes that match the transaction’s actual risk class.
Evidence requirements should support risk classification, pre-signing review, and high-risk approval policy so each transaction is judged on documented context rather than memory or urgency.
Control map
What controls should teams define first?
- Require the evidence package to match the transaction risk class so high-risk actions are not reviewed on the same thin context as ordinary operations.
- Separate evidence that explains business purpose from evidence that proves execution context, because both can fail independently.
- Make simulation output reviewable by humans, not just present in tooling, so signers can compare expected effect to stated purpose.
- Document escalation or exception reasoning inside the transaction record so later reviewers can understand why normal controls changed.
| Evidence category | What it proves | Who depends on it | Failure if missing |
|---|---|---|---|
| Business purpose evidence | Why the transaction exists and which process it serves | Reviewers and signers assessing intent | Transactions are approved on vague summaries |
| Destination and counterparty evidence | Why the receiver, contract, or route is expected and trusted | Reviewers checking execution context | A familiar asset moves to an unfamiliar endpoint |
| Simulation or execution preview | What state change the transaction is expected to cause | Signers validating effect before signature | Calldata is approved without effect-level understanding |
| Escalation and exception notes | Why extra controls or overrides are required | Escalation owners and later reviewers | Exception-risk activity looks like routine approved work |
How should teams operationalize it?
Evidence requirements should support risk classification, pre-signing review, and high-risk approval policy so each transaction is judged on documented context rather than memory or urgency.
transaction_evidence_requirements:
baseline:
- business_purpose
- destination_context
elevated:
- simulation_output
- signer_expectation_match
exception:
- escalation_note
- override_scope
Within this cluster
Source context
Frequently Asked Questions
Why are evidence requirements different from approval rules?
Approval rules decide who must approve a transaction, while evidence requirements decide what information those approvers and signers must actually review before their approval is meaningful.
What evidence should always exist before approval?
There should always be a clear business purpose, destination context, and enough execution context for reviewers to understand what the transaction is supposed to do.
Should evidence scale with transaction risk?
Yes. Higher-risk transactions need deeper evidence packages, including richer execution previews, stronger destination validation, and clearer escalation notes.
What happens when evidence is incomplete?
The transaction should be blocked, narrowed, or escalated rather than approved on assumptions that reviewers cannot support with documented context.