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

Smart Contracts, commonly used within the Ethereum blockchain, found its way into the banking and finance sector via decentralized FInance (deFI). The trend for cryptocurrency’s ‘Summer of 2020’ excited many veterans of the crypto-space, and newcomer alike, on what deFI could do for the future and more importantly for themselves.

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

This space gets convoluted around the time Yearn finance and Yam finance are introduced. The latter being a short-lived protocol, with a notable contract bug locking up the protocol governance. Both these protocols are operated by non anonymous individuals / developers.

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

Sushiswap, launched around the last week of August 2020 by an anonymous developer forking codes off Yam and Synthetix, triggers the next chapter. The code is well written, documented and extremely flexible. The controversial migrator function within the protocol is live tested and a successful uniswap ‘vampire’ migration is demonstrated in the first week of September, taking over a good 90% of uniswap liquidity at its peak.

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()

While some projects were badly and/or ‘ignorantly’ modified copies of ‘sushi’, with modifications introducing protocol risk down the line; a good number of these malicious clones were outright laced with ways for developers or third party to exploit the smart contract approval given by these deFI wallets.

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()

Liquidity Pairs (LP) tokens are simply tokens awarded (“minted”) to users upon provision of liquidity to a protocol. Sushiswap’s template of migrator function is another vector of exploit for the various cross protocol farming pool, where LP were given approval to a 3rd party protocol.

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

There’s various ways to get yourself to safe shores.

  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

In the course of our interaction with various available utilities in the market, we found various short comings. Some of the offering simply doesn’t work with specific wallets or addresses, and some provide only a partial historic listing of the protocols that we interacted with. This list goes on ..

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