Wallets & security
A trusted frontend can still ask for the wrong transaction
Review the final wallet request, not only the page that produced it.
Research articles and reference entries are published in English. Navigation is available in seven languages.
People & projects
In this article
- Compare intent with the request Record the selected operation, network, destination, asset and amount. Compare those with the final call data and any nested actions. Include token allowances or additional transfers introduced as part of a batch. The same button can conceal different behaviour after a compromised update.
- Check more than the screenshot A screenshot establishes what was displayed, not everything that was signed. For a reproducible finding, preserve the relevant software version and request structure. Where a simulation is used, record the state and assumptions that made it produce that result.
- Keep testing controlled Use authorised environments and funds you control. A demonstration should establish the mismatch without exposing other users. The resulting report should state the exact difference between the intended action and the authorisation produced, followed by the impact that difference permits. General claims about an insecure frontend are less useful than a specific failed boundary.
A financial interface sits between user intent and contract execution. Its appearance, domain history and familiar branding do not prove that the final transaction matches the action the user selected. The review boundary is the complete request presented for authorisation.
Compare intent with the request Record the selected operation, network, destination, asset and amount. Compare those with the final call data and any nested actions. Include token allowances or additional transfers introduced as part of a batch. The same button can conceal different behaviour after a compromised update.
Check more than the screenshot A screenshot establishes what was displayed, not everything that was signed. For a reproducible finding, preserve the relevant software version and request structure. Where a simulation is used, record the state and assumptions that made it produce that result.
Keep testing controlled Use authorised environments and funds you control. A demonstration should establish the mismatch without exposing other users. The resulting report should state the exact difference between the intended action and the authorisation produced, followed by the impact that difference permits. General claims about an insecure frontend are less useful than a specific failed boundary.
Sources
Ethereum documentation · securityTechnical reference checked 9 September 2026. The review questions are editorial analysis, not findings about a named project.