Smart Contract interaction, risk and liabilities

In the web 3.0 world, one couldn’t stop to stare in awe at the vast resources, ideas and innovations a user could possibly interact with. These blockchain fueled decentralized applications (dAPPs) opens opportunities for many to interact in their own terms, in a permission-less privacy-centric ecosystem.

ver 0.1

Naive and hopeful, the first wave of deFI offerings were largely conservative and the wild west of this space hosted mainly tech savvy users and the occasional roulette whales.

One could safely navigate these deFI protocols, hosted mostly by non anonymous developers, by committing ERC-20 tokens into the various protocols, with a pretty good reassurance that these protocol owner/developers are legit, and will act in good faith, and are committed for the long run.

Apart from possible Smart Contract bugs within the committed code, the risk is single dimensional. Users were savvy and most of them use exclusive ethereum address for each protocol instance, limiting protocol exposure to a set amount of resources… all is well.

opportunities

Yam’s UI and farm code (a fork of Synthetix) were fresh and easy to work on. It is unfair not to mention Yearn’s Vault concept here, however one can find out more by doing a web search, as it’s covered extensively elsewhere. Yam’s and Yearn’s code and interface set the stage for the next big thing.

enter the masterchef

The audited sushiswap code starts ‘the wave of clones’, some with new gimmicks, while some were pointless pure copies, and then there were some that were simply bad copies. Within a few days of the launch of sushiswap, malicious code started to flood various new clones.

Around this same “spacetime”, a surge of new users flooded the deFI space, lured by the new found freedom of ‘printing assets’ effortlessly, and mainly by the wave of publicity coming from the various sushiswap dramas. Guards were down, where users hopped from one farm to another, rushed into mindless “yes to all” approval to all smart contract interaction, all in the name of chasing the ever-increasing higher APY.

By mid September, users were everywhere. Given the portability of EVM compatible code to the various other blockchains, protocols were cloned into Tron network and Binance Smart Chain (BSC). With each of these network targeting various different user groups and possibly regions of the world.

drain()

With the common ‘infinite’ token access approval given for smart contract interaction, and deFI users recycling their wallets between protocols, These exploits drained their victims’ wallets of their assets, with most exploits happening randomly after the farm is long gone. A ticking time bomb for most users.

migrator()

LP pool approval to a native protocol (example uniswap LP approved for use in uniswap pool), are mainly harmless. However a cross protocol LP approval found in many of the farms, may allow the malicious 3rd party protocol to have full access to the LP token itself, allowing it to migrate the LP token to the bad actor.

de-risk

  1. There are various ways to get yourself to safe shores.
    Never recycle/reuse the same address upon smart contract approval exposure to a protocol. It is however a mess to manage multiple addresses.
  2. Manually unapprove the smart contract one by one by going through the blockchain explorer, in search of approve() transaction.
  3. Interact with a contract approval utilities like unrekt.net.

why unrekt.net

We were motivated to produce a better utility interface in hopes of promoting complementary utilities in the dAPP ecosystem. This free-to-use utility is made available for everyone with no pay-wall, or needing to own a specific token in order to operate.

We are compatible with the following web3 wallets/client

  1. Metamask / Brave Browser
  2. Trust wallet
  3. Math wallet

Smart Contract Approval Utilities — https://unrekt.net

Twitter : https://twitter.com/getunrekt

https://unrekt.net — Ethereum and BSC Smart Contract approval toolbox