Defense 3: FailSafe Interceptor Service

Fortune is on the attacker’s side thus far. The victim proceeded without leveraging FBR, being lured into sharing the seed phrase or signing a transaction of the attacker’s choice. At this point all that remains is to submit the transaction so that its effect will be reflected as part of the next block of the public ledger. The attacker may choose to submit to any participating network node to be queued up with other pending transactions in the public memory pool (the holding area used to prioritise, and order proposed transactions for the next block on the ledger).

At this stage, the FailSafe Interceptor Service (FIS) is on standby. While monitoring a low latency stream of ingress mempool transactions, FIS filters for transactions that FailSafe users partake in. Once detected the counterparty address is passed to FBR. If a threat is detected, FIS attempts to make the attacker’s transaction revert. It should be noted that FIS intervention may also be triggered by transaction policy limits that are part of the user’s FailSafe configuration (e.g., max value allowed to be transferred in a given time period, etc.).

To intercept, FIS submits a new transaction into the pool that transfers the assets in play to another address owned by the user (e.g., the cold wallet address). Most importantly this new transaction will have a slightly higher gas price than that being paid by the attacker, which results in being placed ahead of the attacker's transaction, in the execution order. When it comes time to execute the attacker's transaction, it will revert and not become part of the ledger as the user will have an insufficient balance at that point. Note: the same principle applies to NFTs (ERC-721).

To improve the odds, the attacker may choose to pay a transaction fee premium and bypass the global memory pool altogether through so-called ‘private transactions’. These are aggregated in bulk via intermediaries (see Fast Protect) and included by miners in the next mined block) on the blockchain.

To close down this avenue to fraudsters and apply the above techniques, we are exploring an “exceptions list” mechanism, where end users will be able to add their own Web3 address to this list. Mempool service providers such as BloxRoute would then filter out private transaction requests where the source address is a member of this list.

Additionally, throughout the lifecycle of the transaction the user is alerted with real time push/message notification and further advice on possible next remediation steps (if any can be taken by the user).