Defense 2: FailSafe Blockchain Reconnaissance

First contact with the attacker. As noted earlier, the attacker’s goal at this point is either to directly learn the user’s private key, or convince the user to sign a transaction of the attacker's choice. A myriad of tried and tested social engineering attacks are available, and just as in the Web2 world, even if rejected by 99% of users, the 1% success rate can make the endeavour highly profitable.

At this stage, a FailSafe user is protected by several countermeasures. When the user encounters the attacker’s dApp, if the user is using a client that is directly integrated with FailSafe Blockchain Reconnaissance (FBR) service (e.g., like FailSafe chrome plugin or a proxy RPC URL), the attacker’s request is likely to be rejected outright. The FBR maintains an up to date database of black listed addresses; this includes sanctioned addresses, fraudulent/rugpool contracts. Risk profiles are also constructed based on historical as well real time transaction driven behaviour anomalies/patterns. For unintegrated clients, the FBR companion is available to the end user via direct address entry/lookup.