Fortify Your Ethereum Journey Web3 Pi Transaction Firewall

The world of Web3 promises a digital revolution – a decentralized future where users have greater control over their data and assets. However, this exciting frontier also carries significant, often hidden, risks. Interacting with decentralized applications (dApps) has become remarkably simple, but this ease of use can mask the complexity and dangers lurking beneath the surface.

Recent, high-profile security incidents, such as the severe attacks on Radiant Capital [1] and the ByBit [2] exchange, serve as a stark reminder that current security practices are often insufficient. [1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11] These are not isolated cases; exploits and scams regularly lead to devastating financial losses, often totaling millions, sometimes even billions, of US dollars worth of tokens across the ecosystem. In the face of these challenges, the Web3 Pi (W3P) project aims to strengthen the Ethereum ecosystem by focusing on user empowerment, security, and decentralization. We achieve this through a two-pronged approach: education and providing the right tools.

A key component of our tooling strategy is the Transaction Firewall, which we affectionately call TxFirewall. It’s a component designed to provide a critical layer of security for transactions on the Ethereum network. This article aims to explain what TxFirewall is, why it is crucial, how it functions, and the significance of its approach in the current Web3 threat landscape.

Section 1: The Perilous Landscape: Why Standard Web3 Interactions Are Risky

Interacting with the blockchain often gives the illusion of complete control. Users initiate transactions through familiar interfaces, like the popular MetaMask wallet. However, the moment a cryptographic transaction is signed, actual control over its fate is largely lost without additional safeguards. Unlike traditional financial systems where transaction reversal mechanisms or other safeguards exist, blockchain operations are inherently immutable. Once a signed transaction is confirmed on-chain, a malicious one cannot be undone. This fundamental difference opens the door to various attack vectors.

Attack Vector 1: Interface Deception (Phishing and UI Manipulation)

One of the most common threats is phishing and user interface (UI) manipulation. Attackers create fake websites that mimic legitimate dApps or, worse, compromise the front-ends of real applications. The goal is to trick the user into signing a transaction with malicious parameters – for example, a substituted recipient address, an inflated amount, or hiding the true nature of the contract function being called.

A prime example of this threat is the infamous attack on the ByBit exchange. Attackers didn’t directly break the multi-sig contract’s security. Instead, they compromised the user interface (specifically the Safe[Wallet] UI) by injecting malicious JavaScript code. This code was subtle and precisely targeted ByBit. It caused the interface to function normally in all cases except when signers were authorizing a transaction from the exchange’s cold wallet. At that moment, the interface showed them the details of a legitimate, expected transaction, while in reality, they were signing a transaction sending funds to the attackers (via delegateCall manipulation). This incident brutally exposed the critical gap between user intent and actual transaction execution after signing, showing that trusting the interface alone can be fatal.

Attack Vector 2: Address Poisoning (The “Vanity” Address Trap)

Another insidious attack is “address poisoning,” which exploits so-called “vanity” addresses. The mechanism is simple: scammers generate wallet addresses that visually resemble addresses frequently used by the victim – usually by matching the first few and last few characters. They then send transactions of zero or negligible value (e.g., 0 tokens) from these fake addresses to the victim’s address.

The goal is to “poison” the victim’s transaction history. Attackers rely on human psychology and habits. Users rarely memorize entire 40-character hexadecimal addresses. Instead, they often copy addresses directly from their wallet’s transaction history or a block explorer, cursorily checking only the beginning and end of the address. If the user inadvertently copies the substituted, deceptively similar “vanity” address and uses it when constructing and signing a transaction, the funds go straight into the scammer’s pocket. The problem is compounded by the fact that many interfaces visually shorten addresses, showing only fragments, making it even harder to spot the difference. The scale of this problem is vast – studies indicate hundreds of millions of attack attempts and losses in the tens of millions of dollars.

Attack Vector 3: Untrusted Data Sources (Compromised RPCs and Eclipse Attacks)

Every interaction with the blockchain relies on data retrieved from the network – current account states, balances, contract code. Users typically rely on RPC (Remote Procedure Call) endpoints provided by various services. Using centralized, third-party RPC providers carries risks. Such endpoints can be compromised, subject to censorship, or worse, deliver manipulated data.Decisions made based on false data when constructing a transaction can lead to catastrophic outcomes once it’s signed and sent.

A more advanced threat is an Eclipse attack. In such an attack, an adversary manages to isolate the victim’s node (potentially the one serving the user’s RPC requests) from the rest of the honest peer-to-peer network. The attacker monopolizes all of the victim’s network connections, effectively controlling the flow of information. They can then present the victim with a false view of the blockchain state, hide real transactions, or censor blocks. Although Eclipse attacks are complex, historical vulnerabilities in Ethereum clients (even if patched) show this is not a purely theoretical threat. This undermines the fundamental trust in data coming from external, unverified sources.

The effectiveness of attacks like address poisoning or UI manipulation is amplified by common user habits (copy-paste, cursory checks) and reliance on potentially unreliable external data sources. It’s not a single vulnerability, but rather a chain of weaknesses in the typical Web3 interaction flow. Securing transactions, therefore, requires a comprehensive approach addressing the data source, the user interface/verification step, and minimizing errors stemming from human habits, especially after the critical signing step.

Furthermore, many existing security tools operate reactively. Post-mortem transaction analyzers, block explorers, or fund tracing tools are valuable for forensic analysis but cannot prevent the initial loss if a malicious signed transaction gets confirmed. Due to blockchain immutability, recovering stolen funds is extremely difficult. Attacks like the one on ByBit or a successful address poisoning cause immediate loss the moment the signed transaction executes. Therefore, a mechanism that intercepts and verifies signed transactions before they are broadcast to the network offers a fundamentally different, proactive security posture.

Section 2: Web3 Pi (W3P) - Building a Foundation of Trust

The Web3 Pi project was conceived to strengthen the Ethereum ecosystem by making it easier for users to run their own independent nodes. Our philosophy rests on several key pillars: Security First, Full User Control, Free and Open Access, and crucially, No Monetization Incentives Leading to Skewed Priorities (hence, there is no custom token or fee structure designed to monetize the security solution itself).

This philosophy is fundamentally important, especially in the context of security tools. The absence of monetization incentives removes potential conflicts of interest that might tempt compromises in security. We don’t need to route transactions through a centralized, paid analysis service, nor prioritize features that increase potential revenue at the expense of user protection. Our goal is to provide tools that operate solely in the user’s security interest, remaining entirely under their control. This lack of economic conflict ensures security remains the absolute priority and enhances TxFirewall’s credibility as a pure security tool.

Running your own Ethereum node using W3P brings tangible security benefits:

• Data Sovereignty: The user gains direct access to uncensored blockchain data, bypassing potentially compromised or censoring external RPC endpoints.
• Privacy: It minimizes the leakage of metadata associated with RPC queries, which public services might collect and analyze.
• Resilience: Each additional independent node strengthens the decentralization and resilience of the entire Ethereum network. As mentioned in the introduction, advanced users might even consider running multiple W3P nodes in different locations to further protect against Eclipse attacks, although this is approaching a paranoid level of security.

In the context of security, a local W3P node, combined with tools like TxFirewall, creates the user’s personal Trusted Computing Base (TCB) for Ethereum interactions. A TCB is the set of hardware, firmware, and software components on which the security of the entire system depends. In our case, the TCB encompasses the W3P device running the Ethereum node and the TxFirewall. All critical operations – reading the blockchain state and verifying signed transactions before sending – occur within this trusted boundary. This contrasts sharply with relying on the vast, untrusted Internet and external RPC services.

Section 3: TxFirewall Deep Dive: Your Personal Ethereum Gateway

At its core, TxFirewall functions as a local proxy server that intercepts signed transactions. It acts as an intermediary between the user’s wallet (e.g., MetaMask submitting a signed transaction) and the RPC endpoint of their own W3P Ethereum node.

Technically, TxFirewall listens on a specific local port configured in the wallet. When the wallet sends an RPC request, TxFirewall intercepts it. Crucially, standard read-only requests (like eth_getBalance, eth_call, etc., used by dApps and wallets to display information) are automatically passed through directly to the W3P node without user interaction. However, the critical call containing the signed transaction (typically eth_sendRawTransaction or similar, which aims to modify the blockchain state) is intercepted and subjected to a verification process. This entire verification process happens locally on the W3P device or the user’s machine, after signing but before the transaction is broadcast to the Ethereum network, still allowing it to be rejected. TxFirewall is thus a framework that specifically enhances security after the user has signed a transaction, providing a final checkpoint for state-changing operations.

Feature 1: Known Address Verification – Thwarting Address Scams

TxFirewall’s primary and highly effective feature is the verification against user-defined known addresses and contracts. The user configures simple text files (auth_addr.json for external wallet addresses and known_contracts.json for contract addresses) where they predefine the addresses they intend to interact with, optionally adding human-readable labels (e.g., “My Main Wallet”, “Uniswap Router Contract”).

This feature directly counters address poisoning and helps catch errors. When TxFirewall intercepts a signed transaction, it checks the recipient (to) address and the contract address (if applicable) against the user’s lists.

• If an address is on the list, TxFirewall displays the transaction details along with the user-defined label, confirming it’s a recognized destination.
• If an address is not on the list, TxFirewall flags it as unknown and requires explicit confirmation from the user, presenting the full, unfamiliar address.

This prevents the scam where a user inadvertently copies a deceptively similar but unauthorized address from their transaction history when constructing the transaction they later signed. It forces a conscious decision for unknown destinations and provides helpful context for known ones, moving beyond simple visual checks made before signing. It also safeguards against simple typos or copy-paste errors made before signing.

While a detailed analysis of the Radiant Capital attack was not possible due to the unavailability of the provided source, it’s plausible (though requiring verification) that TxFirewall’s known address verification could have prevented certain types of exploits if they involved redirecting funds via the signed transaction to an unexpected, unknown contract or wallet address.

Feature 2: Amount Verification

Currently, TxFirewall also allows for basic transaction amount verification within the signed transaction. While simple, this provides an additional line of defense against “fat-finger” errors (signing a transaction sending a much larger amount than intended) or attempts to manipulate the transaction value as part of a phishing attack before signing.

Feature 3: Contract Interaction Transparency (ABI Integration)

Standard transaction confirmations in wallets often only show the contract address and an opaque data field containing the encoded function call. TxFirewall goes a step further. It allows users to provide Application Binary Interfaces (ABIs) for known contracts in the known_contracts.json file in an additional optional field.

If an ABI is available, TxFirewall can decode the data field from the intercepted signed transaction and present the user with the human-readable name of the function being called and its parameters. Instead of just seeing the raw hex data they signed, the user might see a clear breakdown like: “Calling function transferFrom with parameters: from: addressX, to: addressY, amount: 100” or “Calling function approve for contract Z with amount: N”. This transparency is crucial. It allows the user to verify what the signed contract interaction will actually do, and spot unexpected or potentially malicious calls (e.g., an attempt to call approve instead of transfer) that might have been obscured before signing.

In the context of the ByBit attack , although the UI manipulation itself happened before signing, the increased transparency provided by ABI decoding in TxFirewall during the post-signing verification step would make it harder to hide malicious logic (like an unexpected delegateCall) within the signed transaction’s data field.

The Human Checkpoint

The culmination of the TxFirewall verification process is a user interface (accessible via a web browser) where all relevant details of the intercepted signed transaction are presented: addresses (with labels if defined), amounts, the decoded contract function (if ABI is available), and any warnings (e.g., about an unknown address). The user must explicitly approve or reject this signed transaction. This step restores user control at the final critical moment – after signing but before making an irreversible commitment on the blockchain network.

The fundamental shift TxFirewall introduces is moving the point of trust and adding a crucial verification layer after the signature. Instead of relying solely on the wallet or dApp interface during signing (which, as ByBit hack showed, can be manipulated), the transaction is matched against locally stored security parameters and policies on the w3p device before being broadcast. TxFirewall intercepts the raw signed transaction and presents its own, independent interpretation (enhanced by ABI decoding) for final approval. This adds a verification layer independent of a potentially compromised dApp front-end used for signing, focusing on the actual data within the signed transaction and user-configured policies.

Table 1: TxFirewall Features vs. Web3 Threats

Section 4: Seamless Integration, Enhanced Security

Integrating TxFirewall into the existing user workflow is designed to be as straightforward as possible while providing a significant security boost.

Configuring TxFirewall

TxFirewall is seamlessly integrated into the Web3 Pi ecosystem. There’s no need for separate installation steps like cloning repositories or managing dependencies manually. Configuration is handled entirely through a dedicated web panel within the Web3 Pi Cockpit interface.

This integrated approach simplifies setup significantly, allowing you to manage TxFirewall’s security settings alongside other Web3 Pi node configurations within a single, unified dashboard. You can access the Cockpit interface via your W3P device’s local network address on port 9090.

Configuring MetaMask

To use TxFirewall, you still need to configure your MetaMask wallet (or another compatible wallet) to send signed transactions to the TxFirewall proxy instead of directly to the Ethereum node’s RPC. This process remains the same: add a new custom network in MetaMask:

1. Open MetaMask network settings and select “Add network”.
2. Choose the “Add a network manually” option.
3. Enter the new network details:
   • Network name: Any name, e.g., “W3P with TxFirewall”.
   • New RPC URL: The address where the TxFirewall proxy is listening. By default, this is http://<hostname_W3P>.local:18500 (where <hostname_W3P> is the hostname of the W3P device, e.g., eop-1.local, and 18500 is the default proxy_port).
   • Chain ID: The ID of the network you want to connect to (e.g., 1 for Ethereum Mainnet).
   • Currency symbol: E.g., ETH.
   • Block explorer URL (optional): E.g., https://etherscan.io.
4. Save the network.
5. Select the newly added network as the active one in MetaMask.

User Experience (UX)

There’s no denying that TxFirewall introduces an extra step in the transaction sending process – the need to confirm the already signed transaction in the firewall’s web interface before it’s broadcast. We recognize this might be perceived as some friction. However, this extra step is a conscious trade-off for fundamental security. It’s the price for regaining control and having the ability to verify after signing but before making an irreversible commitment on the network.

It’s important to emphasize that TxFirewall only intervenes for actual transaction sending (intercepting the signed transaction) or potentially risky message signing operations. Simple blockchain data reads pass through transparently. Our goal is to further minimize this friction, particularly through future automation of low-risk transaction approvals.

This deliberate trade-off between smoothness and security reflects W3P’s “security first” philosophy. For critical assets, a moment of post-signing verification is a far better alternative than the risk of irreversible loss due to an attack exploiting the lack of that verification.

The Secure Data Pipeline

To fully leverage the security potential of W3P and TxFirewall, it’s crucial to ensure the entire data pipeline relies on trusted, local components. This means:

1. Configuring TxFirewall (via Cockpit plugin) to use the RPC address of the local W3P node as its target rpc_endpoint.
2. Configuring the wallet (e.g., MetaMask) to use the TxFirewall proxy URL as its RPC endpoint.

This combination guarantees that data reads come from your trusted local node (via TxFirewall) and that signed transactions are verified by TxFirewall before leaving the local environment.

Section 5: The Road Ahead: Evolving TxFirewall’s Defenses

TxFirewall’s current functionality, based mainly on whitelisting and ABI decoding of signed transactions, provides a solid security foundation. However, the Web3 threat landscape is constantly evolving, so we plan further development for TxFirewall to meet future challenges.

The Power of Simulation (Pre-Flight Check)

The most significant planned enhancement is the introduction of a transaction simulation mechanism. The concept involves taking the intercepted, signed transaction and running it in a local, safe sandbox environment that mirrors the current state of the Ethereum blockchain. This will allow predicting the exact effects of executing the transaction – what state changes will occur, which tokens will change hands and in what amounts – before it’s actually broadcast to the network.

Such a “pre-flight check” mechanism would provide a powerful defense against more sophisticated attacks. In the case of the ByBit attack, simulation could have revealed that the signed transaction, which looked like a normal transfer in the manipulated UI used for signing, would actually drain the wallet by executing malicious code via delegateCall. The simulation would show the actual, catastrophic outcome, allowing the user to reject the signed transaction, regardless of what the interface showed during signing.

Furthermore, this simulation engine is planned to recursively parse nested calls. For example, if a signed transaction calls a multisig wallet, and that multisig call includes data to trigger an ERC-20 transfer on another contract, the simulation won’t just show the call to the multisig. It will decode the nested ERC-20 transfer call as well, presenting the user with a complete picture of the entire chain of actions initiated by their single signature. This deep parsing significantly improves clarity, making it easier for users to understand the full consequences of the transaction they signed before giving final approval.

It’s worth noting that transaction simulation or preview is a feature offered by some other security tools and wallets, such as Rabby Wallet, Fire.xyz, Pocket Universe, or the now-defunct WalletGuard. However, TxFirewall differentiates itself through its approach: it runs locally, is entirely under user control, is free and open-source, operates after signing as a final checkpoint, and is integrated with the W3P ecosystem, relying on data from a local, trusted node.

Introducing simulation marks a significant evolution for TxFirewall. It moves from verifying known parameters within the signed transaction (addresses, amounts) to predicting the unknown outcomes of complex contract interactions initiated by that signature. Current features are effective against attacks like address poisoning, but complex contracts can hide non-obvious effects. Simulation directly addresses this by executing the code in a safe environment to reveal its actual state changes. This transforms TxFirewall from a primarily rule-based tool into a predictive one, capable of catching a broader spectrum of threats hidden within signed transactions.

Configurable Rules Engine

In the future, we plan to enable users to add their own custom logic modules for accepting or rejecting signed transactions. Imagine defining rules like: “Reject any signed approve transaction for an amount greater than X,” “Allow signed transfers only to addresses from my ENS address book,” or “Require extra confirmation for any signed interaction with a newly deployed contract.” Such an extensible system would allow for the creation of more advanced, personalized security policies operating at the final checkpoint.

Automation and Fluidity

We understand that constantly confirming every signed transaction can be cumbersome. Therefore, we aim to introduce automation mechanisms. A user could define rules for automatically approving routine, low-risk signed transactions (e.g., “auto-approve signed transfers below 0.01 ETH to known addresses”). This would make TxFirewall virtually invisible in daily use, intervening only when a threat is detected within the signed transaction, a high-risk operation is identified, or an action requires additional verification according to the user’s policy.

Section 6: Conclusion: Take Control of Your Ethereum Security

The Web3 Pi Transaction Firewall (TxFirewall) is not just another tool – it’s a manifestation of the W3P project’s philosophy, prioritizing security, user control, and decentralization. Facing growing and increasingly sophisticated threats in the Ethereum ecosystem, TxFirewall offers a proactive shield, acting as a critical final checkpoint after you sign a transaction but before it becomes irreversible on the blockchain. It protects against common and advanced attacks, such as phishing, address poisoning, and user interface manipulation that might have tricked you during the signing process.

• Proactive Post-Signing Protection: Intervenes after signing but before broadcast, preventing losses by allowing rejection of malicious or unintended signed transactions.
• Enhanced Transparency: Decodes complex contract interactions within the signed transaction, allowing users to verify what they actually signed off on.
• User Control at the Final Step: Enforces explicit verification of the signed transaction, putting the final broadcast decision back in the user’s hands.
• Local Operation: Runs within a trusted local environment, minimizing reliance on external services for this critical check.
• Alignment with W3P Philosophy: It’s free, open-source, and crucially, free from monetization incentives that could compromise its security focus.

TxFirewall is an integral part of Web3 Pi’s broader vision – creating a safer, more accessible, and decentralized Ethereum ecosystem for everyone. By empowering users to run their own nodes and providing tools like TxFirewall, we aim to put power back into the hands of individuals. While TxFirewall enhances security for all users, its rigorous, post-signing verification model becomes increasingly vital as the value of the assets being managed grows. For substantial holdings, the potential impact of a single compromised transaction is immense, making such a final checkpoint indispensable.

We encourage you to explore TxFirewall further:

• GitHub Repository: https://github.com/Web3-Pi/ethereum-transactions-firewall/tree/mgordel/refactoring
• Documentation: https://docs.web3pi.io/use-cases/transaction-firewall/
• Web3 Pi Homepage: https://www.web3pi.io/

Your feedback and community contributions are invaluable as we continue to develop both TxFirewall and the entire Web3 Pi project.

In a world where digital asset security is paramount, tools like TxFirewall, combined with the solid foundation of a personal W3P node, allow users to navigate the Web3 space with greater confidence and peace of mind. Take control of your Ethereum journey today by adding this essential post-signing security layer.

Resources

1. Radiant Capital Post-Mortem, https://medium.com/@RadiantCapital/radiant-post-mortem-fecd6cd38081
2. The ByBit Heist and the Future of U.S. Crypto Regulation - CSIS, https://www.csis.org/analysis/bybit-heist-and-future-us-crypto-regulation
3. In-Depth Technical Analysis of the Bybit Hack | NCC Group, https://www.nccgroup.com/us/research-blog/in-depth-technical-analysis-of-the-bybit-hack/
4. ByBit Hack: Exploiting Smart Contracts to Drain Funds - A Deep Dive on How it Happened, https://lukka.tech/bybit-hack-deep-dive/
5. The Bybit Hack: Following North Korea’s Largest Exploit | TRM Insights, https://www.trmlabs.com/post/the-bybit-hack-following-north-koreas-largest-exploit
6. Sygnia’s Investigation into the Bybit Hack: What We Know So Far, https://www.sygnia.co/blog/sygnia-investigation-bybit-hack/
7. Collaboration in the Wake of Record-Breaking Bybit Theft - Chainalysis, https://www.chainalysis.com/blog/bybit-exchange-hack-february-2025-crypto-security-dprk/
8. Bybit hack: phishing involved, plus how to prevent similar hacks (updated) - Ledger Insights, https://www.ledgerinsights.com/bybit-hack-phishing-involved-plus-how-to-prevent-similar-hacks/
9. The largest theft in history - following the money trail from the Bybit Hack - Elliptic, https://www.elliptic.co/blog/bybit-hack-largest-in-history
10. The Safe Wallet Hack That Led to Bybit’s $1.4B Heist - Cyfrin, https://www.cyfrin.io/blog/safe-wallet-hack-bybit-exploit
11. Digital Assets Brief: Bybit Hack Underlines Importance Of Cyber Resilience - S&P Global, https://www.spglobal.com/ratings/en/research/articles/250225-digital-assets-brief-bybit-hack-underlines-importance-of-cyber-resilience-13426701
12. Web3 Pi - Your Ethereum Node on Raspberry Pi, https://www.web3pi.io/
13. Address poisoning scams | MetaMask Help Center, https://support.metamask.io/stay-safe/protect-yourself/wallet-and-hardware/address-poisoning-scams/
14. Address Poisoning Attacks and Trezor, https://trezor.io/support/a/address-poisoning-attacks
15. Blockchain Address Poisoning - arXiv, https://arxiv.org/html/2501.16681v1
16. (PDF) Blockchain Address Poisoning - ResearchGate, https://www.researchgate.net/publication/388459687_Blockchain_Address_Poisoning
17. Characterizing Ethereum Address Poisoning Attack - ACM SIGSAC, https://www.sigsac.org/ccs/CCS2024/assets/pfaubmkaccs2024submissions/new/p986-guan.pdf
18. Exploring the Nuances of Address Poisoning - Merkle Science, https://www.merklescience.com/blog/exploring-the-nuances-of-address-poisoning
19. Anatomy of an Address Poisoning Scam - Chainalysis, https://www.chainalysis.com/blog/address-poisoning-scam/
20. Sender Beware: Address Poisoning Spreads to Ethereum and Fake Tokens, https://knowledgebase.merklescience.com/security-risk/sender-beware-address-poisoning-spreads-to-ethereum-and-fake-tokens
21. Vanity Gone Rogue: The Rise of Exploits Targeting Custom Blockchain Addresses - ISACA, https://www.isaca.org/resources/news-and-trends/isaca-now-blog/2024/vanity-gone-rogue-the-rise-of-exploits-targeting-custom-blockchain-addresses
22. Zero Transfer Phishing - Part 1 - Attack Analysis - Coinbase, https://www.coinbase.com/blog/zero-transfer-phishing-part-1-attack-analysis
23. Eclipse Attacks on Monero’s Peer-to-Peer Network - Network and Distributed System Security (NDSS) Symposium, https://www.ndss-symposium.org/wp-content/uploads/2025-95-paper.pdf
24. (PDF) Ethereum Eclipse Attack Detection based on BG-XGBoost - ResearchGate, https://www.researchgate.net/publication/380804497_Ethereum_Eclipse_Attack_Detection_based_on_BG-XGBoost
25. Eclipse Attack Detection for Blockchain Network Layer Based on Deep Feature Extraction, https://www.researchgate.net/publication/359933134_Eclipse_Attack_Detection_for_Blockchain_Network_Layer_Based_on_Deep_Feature_Extraction
26. Ethereum Eclipse Attacks - Research Collection, https://www.research-collection.ethz.ch/bitstream/handle/20.500.11850/121310/eth-49728-01.pdf
27. Tikuna: An Ethereum Blockchain Network Security Monitoring System - arXiv, https://arxiv.org/pdf/2310.09193
28. Low-Resource Eclipse Attacks on Ethereum’s Peer-to-Peer Network - Cryptology ePrint Archive, https://eprint.iacr.org/2018/236.pdf
29. Blockchain Technology and Related Security Risks: Towards a Seven-Layer Perspective and Taxonomy - MDPI, https://www.mdpi.com/2071-1050/15/18/13401
30. How to Spot and Prevent an Eclipse Attack | NCC Group, https://www.nccgroup.com/us/research-blog/how-to-spot-and-prevent-an-eclipse-attack/
31. Researchers Explore Eclipse Attacks On The Ethereum Blockchain - Bitcoin Magazine, https://bitcoinmagazine.com/business/researchers-explore-eclipse-attacks-ethereum-blockchain
32. Eclipse Attacks on Bitcoin’s Peer-to-Peer Network - SYSSEC, https://syssec.kaist.ac.kr/~yongdaek/courses/ee817/Presentation/Elipse%20Attack%20on%20Bitcoin.pdf
33. List of 87 Blockchain Security Tools on Ethereum (2024) - Alchemy, https://www.alchemy.com/list-of/blockchain-security-tools-on-ethereum
34. The Top 10 Smart Contract Security Tools | CoinMarketCap, https://coinmarketcap.com/academy/article/e9280720-d596-4565-9a3b-034b77ee1d11
35. Transaction Firewall - Web3 Pi, https://docs.web3pi.io/use-cases/transaction-firewall/
36. Privacy and Security - Rabby Wallet Official Guides, https://support.rabby.io/hc/en-us/sections/11150564479503-Privacy-and-Security
37. Rabby Wallet: A Secure Multi-Chain Storage Solution - BitDegree, https://www.bitdegree.org/crypto/rabby-wallet-review
38. A Complete Beginner’s Guide to Rabby Wallet - CoinGecko, https://www.coingecko.com/learn/how-to-use-rabby-wallet
39. Rabby Wallet, https://rabby.io/
40. Fire Web3 security tool - Learn Crypto, https://learncrypto.com/tools/fire
41. Fire Wallet browser extension: shows what happens by clicking a smart contract in a human readable format - is it legit? Pro and cons analysis : r/CryptoCurrency - Reddit, https://www.reddit.com/r/CryptoCurrency/comments/10lu18r/fire_wallet_browser_extension_shows_what_happens/
42. Fire - Web3 Chrome Extension Product Information and Latest Updates (2025), https://www.producthunt.com/products/fire-web3-chrome-extension
43. Pocket Universe: Overview, Reviews, Related Apps & FAQs - Ethereum Ecosystem, https://www.ethereum-ecosystem.com/apps/pocket-universe
44. Pocket Universe - Chrome Web Store, https://chromewebstore.google.com/detail/pocket-universe/gacgndbocaddlemdiaadajmlggabdeod
45. Pocket Universe - We protect your web3 assets, https://www.pocketuniverse.app/
46. Pocket Universe - Bali - Justin Phu, https://www.justinphu.dev/blog/pocket-universe-chapter-2-bali
47. Wallet Guard: Protect Your Crypto, https://www.walletguard.app/
48. Securing Web 3.0: Empowering Users with Wallet Guard - Chainalysis, https://www.chainalysis.com/customer-stories/wallet-guard/