Before the Signature: What Wallets Reveal When They Check a Transaction

1. Introduction

Ledger describes Transaction Check as a review that occurs before a user approves a transaction. Its public software sends the service the account that initiated the request, the encoded transaction, and the network identifier (Ledger, “Transaction Check”; LedgerHQ). If the user rejects the transaction, the wallet does not produce a signature or broadcast it publicly. An outside analysis may nevertheless have received the proposed transaction first. Neither Ledger’s Transaction Check documentation nor its public client code states how long the service keeps a request or whether it shares that request with another organization.

In this study, Local could recognize common token transfers and approval requests from the transaction itself. Local could read the proposed action, but it could not tell whether the transaction would fail or cause asset movements hidden inside a contract without access to the current blockchain state. Services such as Tenderly accept a proposed transaction together with the relevant network and block context, then return an execution preview (Tenderly). That preview may include success or failure, errors, internal calls, and asset changes. Sending the request externally can reveal the account, counterparty, amount, spender, action, or route before approval.

This paper compares three ways to perform that analysis and asks two separate questions: how much each method can determine and how often it sends a complete proposed transaction outside the wallet. It also tests whether a fixed Hybrid rule escalates only when outside simulation adds useful information. The contribution itself is a controlled comparison, not a ready-to-deploy wallet design.

2. Background

For this study, a “complete call” means the information needed to describe the proposed transaction: the sending account, destination, transferred value, encoded function arguments, network identifier, and the fixed blockchain snapshot used for simulation. It does not include a signature, private key, fee setting, account nonce, IP address, device identifier, or any assumption about data retention. Some fields are revealing on their own. For example, the destination and the short function identifier at the start of the encoded data can indicate the intended action, while the remaining arguments can include a spender, amount, route, or deadline. Tenderly’s public API accepts a comparable set of inputs (Tenderly).

There can be more than one disclosure point. First, the wallet may send the complete call to an analyzer. Second, that analyzer may ask other services for contract code, stored data, execution traces, verification proofs, function definitions, or reputation information. A hosted blockchain node can observe those follow-up requests. If the node runs inside the same service, no new organization receives them, although the service can still record the internal request history. Ethereum’s privacy roadmap treats three questions separately: who made a request, what the request reveals, and whether the returned data can be trusted (Ethereum.org, “The Privacy Roadmap”).

3. Related Work

Earlier research shows that a wallet can expose information even when it never reveals a private key. A 2018 privacy overview distinguishes between hiding who sends a blockchain request and hiding what that person asks to see (Henry et al.). Later studies found that browser wallets can leak addresses to outside companies and link a person’s addresses with browsing activity (Torres et al.; W. Wang et al.). Ethereum’s privacy roadmap makes the same basic point: identity, request contents, and answer reliability are separate concerns (Ethereum.org, “The Privacy Roadmap”). This paper focuses on the second concern. If a wallet sends an unsigned transaction to an outside service for analysis, the request itself may reveal what the user is considering before any approval occurs.

Some tools let a wallet check blockchain information without simply trusting a provider, but checking an answer is not the same as keeping the request private. A light client is a small program that verifies parts of blockchain history using cryptographic evidence (Ethereum.org, “Light Clients”). Ethereum can also provide proofs for specific account data (Jentzsch and Jentzsch). The provider still sees which information was requested. Hiding the sender or the requested record requires additional privacy techniques, and those techniques can add delay and complexity (Ethereum.org, “The Privacy Roadmap”; Jentzsch and Jentzsch; Sednaoui). Most importantly for this study, none of them automatically hides a complete transaction sent to a simulator.

Other researchers study whether transaction previews are accurate and safe. WalletProbe tests whether browser-wallet warnings and interactions can be bypassed (Hu et al.). TxT examines when a preview is likely to match what later happens on the blockchain (Ivanov et al.). Zengo and SIMGUARD describe ways a preview can become outdated or be deliberately fooled (Zengo Research Team; X. Wang et al.). Additional proposals explore checking the blockchain information used by a simulator or changing how applications communicate with wallets (Sednaoui; Salem and Zheng). This work shows that previews can fail as well as disclose information. None of it compares the same three approaches tested here: local inspection, simulation of every transaction, and selective simulation.

4. Research Questions and Scope

This study asks three practical questions. First, how well can each method explain what a transaction requests and what will happen if it runs? Second, how often does each method send the transaction’s full details to an outside service? Third, does Hybrid make that choice well: sending the details when simulation would help and keeping them inside the wallet when it would not? The six concrete checks used to answer the first question are described in the next section.

The study covers a limited situation. The outside analyzer is assumed to follow its stated process, although it can learn from the transactions it receives and can sometimes be wrong. The study does not examine deliberate attacks, long-term data storage, compromised devices, interface design, signing, or public broadcast. It also treats a failed transaction as an execution result rather than a security warning. In this paper, an unpredicted asset movement means only that Local could not see the transfer before the transaction ran; it does not imply theft or deception.

5. Methodology

The test used 60 simulated transactions covering six common situations: direct transfers, token transfers, spending permissions, swaps, lending, and more complicated contracts. Of the 60 simulated transactions, 36 were set up to succeed and 24 to fail without changing any blockchain records. Ethereum calls this kind of failure a revert. The test also included 23 predefined warnings spread across 20 transactions. Because the mix was chosen for testing, it does not represent ordinary wallet use.

Local examined only the transaction and reference information already stored with the analyzer. It could recognize transfers of Ether, Ethereum’s native currency, and common ERC-20 token actions. ERC-20 is a widely used format for tokens on Ethereum. Local could also recognize requests to let another account spend tokens and compare visible addresses with a simulated watchlist used only for the study. If it could not understand a transaction, it answered “unknown” instead of guessing. It contacted no outside service. This simplified baseline does not describe every production wallet.

Full represented an outside simulation service. It received every transaction in full and tested it against the same frozen copy of the blockchain. The test environment was built with Hardhat, a standard development tool for Ethereum applications. It showed whether a transaction succeeded, failed, or moved assets. The starting conditions were reset after every case so all transactions faced the same test. Nothing was signed or sent to the public Ethereum network.

Hybrid started with Local. It sent the transaction to Full only when Local did not recognize it or when answering the question required running it. The decision rule and test materials were fixed before the study began. Hybrid had to decide whether to send each transaction before seeing the simulator’s answer.

Each method was judged separately on six practical questions. An answer could be correct, wrong, or “unknown.” The study also recorded whether the full transaction was sent outside the wallet. A simulation counted as useful when it answered something Local could not. Before testing, Hybrid’s target was to overlook no more than two useful simulations and to keep its miss rate below 10 percent among transactions it did not send.

I first tested whether Local recognized the transaction and could describe the action it requested. I also checked whether it could identify a watched address or an unlimited spending permission from the call itself. The remaining questions concerned information that normally becomes available only after execution: whether the transaction succeeded and whether it caused an asset movement Local had not predicted. Whenever the transaction alone did not support an answer, Local was expected to report the outcome as “unknown.”

The methods produced their answers before they were compared with a separately written answer key. An early test exposed a missing check for whether the sender had enough funds. I kept that failed result, corrected the check, and reran the unchanged cases. Three reruns produced the same answers. Full was scored against the independent answer key like the other methods; it was not treated as automatically correct.

6. Results

Full provided a useful check on the test setup. It correctly identified whether all 60 transactions succeeded or failed and recorded every expected asset transfer. It found 22 of the 23 warnings and added no false warnings. These results apply only to the constructed test cases.

Figure 4 separates three results that should not be combined. Local shared no complete transactions but could not predict whether any would succeed. Full received all 60 transactions and predicted all 60 outcomes. Hybrid received 39 and predicted those 39, leaving 21 unanswered. The warning totals use a different count: Local found 11 of 23, Full found 22, and Hybrid found all 23. No method added a false warning. Finding warnings is not the same as predicting outcomes.

All three methods handled questions that could be answered from the transaction itself. Differences appeared when current blockchain information was needed. Local could not determine whether transactions would succeed or reveal asset movements hidden inside a contract. Hybrid could answer those questions only for the 39 transactions it sent to Full. Two mistakes were especially instructive: Full overlooked a spending warning in a transaction that failed, while Local wrongly cleared a watched address that became visible only after the contract ran.

Hybrid missed the target set before testing. Of the 39 transactions it sent outside the wallet, 33 gained a useful answer and six did not. Of the 21 it kept local, 15 needed no simulation, but six would have gained a useful answer. Hybrid therefore shared some transactions unnecessarily while keeping others private at the cost of an unanswered question. All six misses involved ordinary-looking transactions whose result depended on current blockchain information.

Two cases explain why a requested action and the actual result must be reported separately. One transaction asked for unlimited token spending but failed before doing anything. Full recognized the failure yet missed the risky request; Local and Hybrid kept the warning. In another case, the true recipient was stored inside a contract and became visible only when the contract ran. Local lacked that information but incorrectly reported that no watched address was involved. The appendix explains both cases.

Hybrid sent every swap, lending, and complex-contract case to Full but sent only three of ten cases in each simpler group. The detailed breakdown confirms that the rule made unnecessary requests and also missed useful ones. Because the groups were created for testing, the pattern does not represent ordinary wallet activity.

Tests using different Local information, subgroup comparisons, three reruns, and a separate recalculation all supported the same conclusion: Hybrid sometimes shared a transaction without gaining an answer and sometimes kept one local when simulation would have helped.

7. Discussion

When a wallet lacks the information needed to support an answer, it should report that the outcome is unknown. Local followed that rule in most cases, but it incorrectly cleared the stored-recipient transaction even though the recipient remained hidden until execution.

Hybrid protected some information by keeping 21 transactions local, but it could not reliably tell which cases needed simulation. It missed six useful answers and sent six transactions that gained nothing. Preserving every warning did not compensate for the unanswered questions.

A useful preview should distinguish the action a user is being asked to approve from the result predicted by simulation. It should also acknowledge any outcome the available information cannot determine. It should also record why it sends a transaction outside the wallet. This study supports that design principle but did not test a production interface.

Outside simulation may create more than one privacy exposure. The simulator may rely on blockchain-data providers, contract databases, or reputation services, and each additional request can reveal something. Cryptographic checks can show whether returned information is correct, and privacy tools can hide parts of a request, but no single technique protects identity, request contents, and accuracy at once (Ethereum.org, “The Privacy Roadmap”; Jentzsch and Jentzsch; Sednaoui).

Evaluations should therefore report four results separately: requested actions, predicted outcomes, unanswered questions, and information sent outside the wallet. Counting requests alone does not show how revealing they were, whether the sender was hidden, or how long a service kept them.

8. Limitations

This small study used deliberately balanced, simulated transactions. Its percentages do not represent what real wallet users encounter. It tested only three warnings: watched addresses, unlimited spending permissions, and asset movements Local did not predict. It did not test every scam, token behavior, user intention, or possible financial loss.

The study recorded only whether the full transaction was sent to an outside simulator. It did not measure the amount of data sent, connection to an IP address, delay, data storage, later use, or interface design. It also did not test signatures, hardware enforcement, or public broadcast. Because Ledger’s public materials do not describe every production detail, this is not an audit of Ledger’s service. Local also had an advantage because its reference material and watchlist were stored in advance.

The figure 39 out of 60 means only that Hybrid sent 39 complete transactions in this particular test. It is not a general privacy score. One transaction may reveal more than another, and a transaction kept local may still depend on outside software.

The repeated runs used the same code, scenarios, and answer key. They show consistency rather than independent replication and the conclusions apply only to the questions and decision rules tested here.

9. Conclusion

In this test, Full predicted every outcome but received every transaction. Hybrid sent fewer transactions and kept all warning labels, but it made poor choices about when to use simulation: six requests added nothing, while six cases kept local missed useful answers. The results should not be reduced to a single security score. A wallet may detect a risky request without knowing whether the transaction will succeed, and it may obtain a better prediction only by disclosing the proposed call to an outside service. The study does not show that the tested Hybrid rule is ready for real users.

Appendix A. Three Diagnostic Boundary Cases

Case 1: A spending-permission request that failed

The transaction asked the user to let another account spend an unlimited amount of a token, but it failed before changing any blockchain records. Local and Hybrid kept the warning because they read the request itself. Full saw that the transaction failed but missed the warning because it considered only what actually happened. A good analyzer should report both.

Case 2: A recipient hidden inside a contract

The intended recipient was stored inside the contract rather than written directly in the transaction. It became visible only after the contract ran and produced a token transfer. Local could not see the recipient beforehand but still said no watched address was involved. It should have answered “unknown.” Full and Hybrid saw the recipient because they simulated this case.

Case 3: A direct transfer that failed

The transaction proposed a direct transfer of Ether but failed. Local and Hybrid recognized the transfer yet could not know its outcome without running it. Full simulated the transaction and identified the failure. Thus, recognizing a transaction type is not the same as knowing it will succeed.

1. Ethereum.org. “Light Clients.” Ethereum.org, updated 25 Feb. 2026. ethereum.org/developers/docs/nodes-and-clients/light-clients. Accessed 30 Aug. 2026.
2. Ethereum.org. “The Privacy Roadmap for Ethereum.” Ethereum.org, updated 24 Aug. 2026. ethereum.org/roadmap/privacy. Accessed 1 Sept. 2026.
3. Henry, Ryan, Amir Herzberg, and Aniket Kate. “Blockchain Access Privacy: Challenges and Directions.” IEEE Security & Privacy, vol. 16, no. 4, 2018, pp. 38–45. doi.org/10.1109/MSP.2018.3111245
4. Hu, Xiaohui, Ningyu He, and Haoyu Wang. “WalletProbe: A Testing Framework for Browser-Based Cryptocurrency Wallet Extensions.” arXiv, arXiv:2504.11735, 16 Apr. 2025. arxiv.org/abs/2504.11735
5. Ivanov, Nikolay, Qiben Yan, and Anurag Kompalli. “TxT: Real-Time Transaction Encapsulation for Ethereum Smart Contracts.” IEEE Transactions on Information Forensics and Security, vol. 18, 2023, pp. 1141–55. doi.org/10.1109/TIFS.2023.3234895
6. Jentzsch, Simon, and Christoph Jentzsch. “EIP-1186: RPC-Method to Get Merkle Proofs: eth_getProof.” Ethereum Improvement Proposals, 24 June 2018. eips.ethereum.org/EIPS/eip-1186
7. Ledger. “How Ledger Hardware Wallets (Signers) Work.” Ledger Academy, updated 19 June 2026. ledger.com/academy/…how-ledger-hardware-wallets-work
8. Ledger. “Transaction Check.” Ledger Academy, updated 26 May 2026. ledger.com/academy/glossary/transaction-check
9. LedgerHQ. “EthereumTransactionCheckLoader.ts.” Device SDK TypeScript, GitHub, commit 24045b8, 28 Aug. 2026. github.com/LedgerHQ/device-sdk-ts
10. Salem, Moody, and Tina Zheng. “ERC-7946: Unidirectional Wallet Uplink, aka UWULink.” Ethereum Improvement Proposals, 10 May 2025. eips.ethereum.org/EIPS/eip-7946
11. Sednaoui. “Trust Minimized Transaction Simulation Using State Proofs.” Ethereum Research, 15 Jan. 2026. ethresear.ch/t/trust-minimized-transaction-simulation-using-state-proofs/23857
12. Tenderly. “Simulate Transaction.” Tenderly Documentation. docs.tenderly.co/api-reference/simulator/simulate-transaction. Accessed 30 Aug. 2026.
13. Torres, Christof Ferreira, Fiona Willi, and Shweta Shinde. “Is Your Wallet Snitching on You? An Analysis on the Privacy Implications of Web3.” 32nd USENIX Security Symposium (USENIX Security 23), USENIX Association, Aug. 2023, pp. 769–86. usenix.org/conference/usenixsecurity23/presentation/torres
14. Wang, Weihong, et al. “The Masks We (Think We) Wear: Privacy Threats of Browser-Extension Wallets in the Web3 Ecosystem.” Proceedings on Privacy Enhancing Technologies, vol. 2026, no. 3, 2026, pp. 523–37. doi.org/10.56553/popets-2026-0094
15. Wang, Xiaocan, et al. “Blockchain Transaction Simulation Phishing.” arXiv, arXiv:2607.28747, 30 July 2026. arxiv.org/abs/2607.28747
16. Zengo Research Team. Web3 Transaction Simulation White Paper. Version 1.0, Zengo, Feb. 2025. zengo.com/…Web3-Transaction-Simulation-White-Paper-Final.pdf