Disclosures & Risks

The risks you should be aware of when using Harpie.

For the best interest & safety of our users, we've provided a list of edge cases and risks that the team is aware of.

Working together with the Harpie community and the larger security community, we hope to address and eliminate many of these concerns as time moves forward.

Edge cases

The following are situations where we wouldn't be able to intervene on behalf of a user at the current moment:

• An attack that occurs through a private mempool/Flashbots RPC

  • see our FAQ

  • Although we don't see these types of attacks as large threats, we are building tools at the wallet-level to circumvent this vulnerability

• A relevant edge case related to the above is the case of a pre-signed transaction being transmitted by a hacker through Flashbots RPC. At this point, this remains the most difficult vulnerability to handle.

  • At this point, Harpie is building up a detection algorithm that we can integrate with wallets to prevent this type of attack across the industry. That being said, this form of attack is extremely rare, and likely will not become a common attack vector for some time.

• Protocol-level attacks (such as the Beanstalk attack) where an attacker steals tokens that users have deposited into that protocol

  • At this point, Harpie does not prevent these large-scale attacks, but we, along with the security community as a whole, are working to stop these threats.

• If you personally use a private mempool or Flashbots RPC to send day-to-day transactions through your wallet

  • At this point, Harpie cannot serve users using private mempools or Flashbots Protect RPC.

• If an address you've added to your trusted network or approved turns out to be a malicious actor

  • To solve this, we curate lists of the most commonly-used protocols, so many users won't have to create their own trusted networks.

• Specifically for private key theft:

  • Private keys are ultimately the deepest form of access into a wallet: Harpie is able to stop naive private key thieves, but advanced private key thieves may be able to change your recipient address

  • To solve this, we're developing 2-factor authentication features to our changeRecipientAddress function, so you can use a second factor to prevent this type of attack

• If your transaction is included at the end of block formation. Our response time is a fraction of a second, but there is a small probability we may not be quick enough to be included in the same block as yours

  • To solve this, we're constantly working on improving our time-to-block, including using special gateways, maxing out our server efficiency, and optimizing our data-processing algorithms.

Risks

Exercise caution when interacting with a smart contract or blockchain application. Even after extensive auditing, smart contracts always have a vulnerability risk. Before interacting with a dApp or smart contract, make sure to do research on its trustworthiness. Check if a dApp has been publically audited or been a part of a security breach before using it.

Why would I use Harpie if there's ways around it?

Harpie is by no means a comprehensive security product, and there are edge cases like the above that can cause it to fail. That being said, we cover almost all of the theft that occurs today, and we're poised to cover even more as we move forward.

Our philosophy is to catch the 99.9% of theft that exists today, and to start the arms race for the last 0.1%. The cracks of Harpie only begin to show when we talk about the most sophisticated of thieves able to exploit those vulnerabilities—those well-versed in MEV and low-level Ethereum nuances. These types of attackers, while scary, are an overwhelming minority: a 2020 report by the United States FBI shows that almost all cybercrime stems from high-volume, low-finesse social engineering attacks like phishing and confidence fraud.

Although the release of Harpie marks the start of the crypto consumer security arms race, we find that we're poised to make a solid stand. We plan to integrate our detection algorithms in as many places as we can, and through that, remove the possibility of mempool obfuscation. We also don't stand alone: we're invested in and connected with the best of the Ethereum security community.

While there has never been a security product with a 0% failure rate, we think we're close to it, and we're poised to get exponentially closer to 0 as we move forward. We think that the question for a long time won't be "how will Harpie deal with attackers?" but rather "how will attackers respond to Harpie?"