Wallet Transaction Evidence Requirements

What Does the Evidence Model Require Reviewers to See?

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.

Which Evidence Categories Should Teams Capture?

• 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.

How Should Teams Judge Approval Quality on Evidence?

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

Which Evidence Should Every Transaction Carry Before Signing?

Cyproli recommends a baseline evidence package for every wallet transaction, with deeper packages for elevated risk. The baseline starts with business purpose: a human-readable statement of why the transaction exists and which process it serves, written so a reviewer can judge intent without decoding calldata. The baseline continues with destination context: who or what receives the funds, why that receiver is expected, and what account or contract role it plays. The third baseline element is a signed amount and asset summary that matches what reviewers will actually see in the wallet. These three elements are cheap to produce and catch the most common failure, which is a transaction approved on a vague description that nobody re-checked against the technical payload. Teams that treat purpose and destination as optional context are approving transactions on memory, and memory is exactly what an attacker exploits.

How Should Evidence Requirements Scale with Transaction Risk?

Evidence depth should track risk class rather than applying one fixed package to every action. For routine low-risk transactions, a compact purpose and destination note is enough. For elevated transactions that move large value or change wallet authority, teams should add simulation output so signers see the expected state change, signer expectation matching so each approver confirms the effect before signing, and destination verification from an independent source where possible. For exception transactions that override normal limits, the evidence package should include the escalation note, the override scope, and the identity of the owner who authorized the exception. Scaling evidence this way keeps low-risk operations fast while forcing high-risk actions to prove themselves. A transaction that cannot produce the evidence its risk class demands is a signal that the action does not actually fit its classification.

What Makes Destination Validation Different from Amount Review?

Amount review confirms the value moving, while destination validation confirms the receiver is the receiver the team intended. The two checks fail independently: a correct amount to a wrong address is still a loss, and a trusted address receiving an unexpected amount is still an anomaly. Destination validation should confirm that the address matches the beneficiary named in the business purpose, that the address has the expected type (contract versus externally owned account) for the action being taken, and that the address has not recently changed in any maintained beneficiary registry. For bridge or cross-chain transfers, destination validation also covers the target chain and the receiving account there. Teams should treat destination validation as a distinct review step with its own owner, because it is the evidence category most likely to catch a swapped address or a compromised routing path that amount review would never see.

How Should Teams Capture Evidence Without Slowing Down Operations?

Evidence collection fails when it becomes friction, because teams respond by copying text or skipping fields. Cyproli recommends building evidence capture into the transaction request form rather than collecting it afterward. The requester states the business purpose, picks the destination from a pre-approved beneficiary list where possible, and attaches the relevant ticket or process identifier as part of the request, so reviewers see context in the same view where they make the decision. Simulation output should be attached automatically from the signing tooling rather than pasted by hand. Escalation notes should be structured fields with owners rather than free-text commentary. This approach makes evidence a byproduct of the existing workflow instead of an additional step, which is the only way evidence requirements survive real operating pressure.

What Happens When Evidence Conflicts with the Transaction Payload?

A conflict between stated evidence and the actual payload is the highest-value detection in the entire evidence model. When the business purpose says a payroll transfer but the calldata targets a contract with no payroll function, or when the destination in the note differs from the destination in the request, teams should treat the mismatch as a potential malicious or stale submission rather than a documentation error. The review response should be to block, escalate, or return the transaction with a specific reason, never to approve on the assumption that the evidence is simply outdated. Cyproli recommends logging every evidence-to-payload conflict as its own incident signal, because repeated mismatches reveal either a broken process or an attacker testing whether reviewers actually read the context in front of them.