Defi safety: how NOT to lose money to hacks

My crypto journey is a transition from a fearlessly reckless ‘defi degen’ to a paranoid, overly cautious defi minimalist. With sheer excitement, I plunged headfirst into the world of DeFi, going as far as investing simply because the graphics looked adorable. I eagerly delved into its vast possibilities, driven by curiosity, yet not fully comprehending the risks that intertwined with every interaction. Unsurprisingly, I got rugged several times — economic attacks, tokens plummeting to zero, stablecoins losing peg. I was lucky enough to avoid falling victim to wallet or smart contract hacks. I managed to survive, after all. My survival in this wild west was nothing more than a balanced portfolio management — allocating only a limited portion to what some might consider “risky” ventures. Of course, what constitutes “risky” is a matter of personal judgment. In my case, my risk tolerance gradually dwindled until I reached a point where I only engage with immutable protocols and swiftly revoke any permissions granted after every transaction. It’s been a journey of survival and self-discovery.

Those setbacks were paying tuition for my crypto education. Each rug pull I experienced was a valuable lesson. As my knowledge accumulated, I had a profound realization: every interaction with a protocol carried the potential of being a ticking time bomb. It was at that moment that I decided to step back and reevaluate my involvement in DeFi. I came to understand that success in this realm isn’t solely about the profits you make; it’s also about minimizing losses. In the end, it’s not just about how much money you earn; it’s equally important how less money you lose.

This article is not an exciting “how-to-make 100x” read. I’m here to guide how not to lose money, not how to make money. Now I will navigate a typical defi user journey and uncover every twist and turn.

Frontend risk

Step one in the user journey is visiting the website. Be on high alert because we’re about to encounter the notorious phishing trick! It is an old scam that lasts long enough to pave its way into web3. Detecting a phishing website is like taking a simple eye-sight test, it’s not rocket science. Find the difference:

Everyone with physically well-enough eyes can avoid the scam. All you need to do is take a deep breath, slow down, and double-check those scammy names. Don’t forget to look out for that glorious “https” in the website’s URL. It’s your trusty shield against the sneaky scammers out there. Let’s start safe! Things are going to be more complex.

Once you’ve successfully navigated through the treacherous sea of phishing websites and found yourself on a legitimate platform, prepare yourself for the next set of challenges that lie ahead. Are you ready to connect your wallet, sign messages, and give token approvals? These are all typical transactions that nearly every protocol requires users to perform before they can engage in further transactions. Now, here’s where things get a little nerve-wracking. Unless you’re a super hardcore tech wizard, chances are you’ll find yourself in a position where you must “blindly” trust what you’re signing. It’s like venturing into the unknown, with a leap of faith. The question is, can you truly trust every line of code and every request that pops up before you?

Land mines here start from the frontend risk. Picture this: hackers lurking in the dark corners, ready to inject malicious scripts that can disrupt the normal behaviour of the dapp. They play a treacherous game, and the abnormalities they introduce can be as subtle but significant as changing the very smart contract you’re supposed to interact with. Ensuring frontend safety should primarily be the responsibility of project builders. Some projects choose to leave the creation of the frontend to the community, evading the burden of frontend security. Well, it’s a convenient way for them to avoid the direct responsibility that comes with it.

So, what frontend security solutions are out there? Is it even possible to have an immutable frontend, impervious to any alterations? It’s a call for project builders to step up and prioritize user safety, providing robust frontend security solutions that protect us from lurking threats.

Token Approval

Now let’s talk about Token Approval. This is a transaction that leaves me no sleep at night.

Token approval, in simple terms, is when you grant permission to a smart contract to interact with and spend your tokens on your behalf. This approval is often required before you can engage in various DeFi activities, such as swap, providing liquidity, or staking. Now, here’s where the anxiety kicks in. Granting token approval involves trusting that the smart contract will only perform the intended actions and not abuse its privileges. But what if things go awry? What if the contract is maliciously upgraded and starts misusing your approved tokens?

One major risk is that malicious actors could exploit vulnerabilities in the smart contract’s code, enabling them to drain your approved tokens without your consent. This could result in significant losses. Additionally, the scope of approval might be broader than you initially anticipated, changing the contract’s logic to manipulate your tokens in unexpected ways. To add to the unease, the risks can extend beyond technical vulnerabilities. Projects with ill intent might deliberately upgrade the contracts to deceive users or engage in rug pulls. The risks associated with token approval extend beyond the moment you initially grant the approval. In fact, they persist until you revoke that approval. It’s like leaving a door open, inviting trouble to enter anytime. The uneasiness remains until you take that crucial step of revoking the approvals. That’s why I can only sleep if I revoke the approvals.

The recent Sushiswap hack manifested the uneasiness of token approval in real life.

In my minimalist defi lifestyle, I limit my activities mostly to Uniswap, the immutable and reputable biggest exchange. However, when Uniswap introduced Permit 2, I had to reassess my exposure to it. Permit 2 is an improvement over the original ERC-20 standard, allowing for a more efficient and user-friendly way to approve token transfers. However, it transfers the approval object to the Permit2 contract, which requires centralized management and imposes higher security standards. Associated risks are unauthorized individuals gain access to users’ signed messages and use them to carry out malicious actions, and Replay Attacks, which involve malicious actors intercepting a signed message from one context and replaying it in another in unintended ways.

What’s the solution then? A protocol that does not need token approval!

I’m so grateful to find one, DeGate, who does not require token approval at all! DeGate is an order book DEX on Ethereum and built with an application-specific ZK-rollup. When you deposit assets into your DeGate account, they swiftly become available for placing orders and executing transactions. Here’s how it works: you initiate a deposit transaction on Ethereum mainnet, which gets included in a block and confirmed after 12 subsequent blocks. Once confirmed, the DeGate node promptly credits the deposited amount to your DeGate account balance. This means that you can immediately utilize these assets for trading and other operations.

In this process, token approval is not required. Instead, DeGate employs a unique off-chain transaction process. Once your on-chain deposit transaction is confirmed, the Operator, who manages the DeGate’s ZK rollup, initiates an off-chain transaction. This transaction undergoes several phases, including block inclusion, block production, proof generation, and updating assets in the Merkle tree. Finally, this off-chain transaction is rolled up on-chain, completing the deposit process. Such a relief. Not needing token approval cuts the tail risks once and for all.

Admin Key risk

I’ve mentioned several times the hacks caused by smart contract’s malicious upgrade . This evil manner is made possible with a smart contract’s admin key.

In smart contracts, an admin key represents a special privilege granted to the persons with it. It acts as a master key, providing control and authority over the smart contract and its functionalities. With an admin key in hand, its owner(s) hold the power to make critical changes, upgrades, or even disable certain features within the smart contract. The admin key is a centralized authority. In the wrong hands, this centralized authority can be exploited, jeopardizing the security and integrity of the entire system.

The risks of having an admin key are two folds: from inside and outside of the project team.

Inside the team, developers who possess the admin key can turn evil and act maliciously to alter the smart contract’s logic to make it against users.

Outside the team, a compromised admin key can be exploited by bad actors, allowing them to manipulate the smart contract, steal funds, or carry out fraudulent activities.

If the admin key falls into the wrong hands, it becomes a single point of failure, potentially leading to significant financial losses. The presence of an admin key can introduce a lack of transparency and accountability. Users may be unaware of the actions taken by those in possession of the admin key, making it challenging to assess the risks and trustworthiness of the smart contract.

The common practices for mitigating the risks of admin key are implementing multisig and time locks for upgrade. But they have limitations and far from ideal to protect users.

Multisig involves requiring multiple authorized parties to sign off on important transactions or changes. This distributes the decision-making power and adds an extra layer of security. However, even with multisig, there is still a level of centralization and reliance on a select group of individuals.

Time locks introduce delays in implementing upgrades or changes to the smart contract. This provides a window of time for users to assess and react if any malicious or undesirable actions are attempted. But to be honest, it is impractical for individual users to actively and consistently monitor smart contracts for alterations.

The effective solution of admin key risk? Having no admin key!

Having no admin key takes power off the hands of the project team, preventing any malicious upgrades from internal or external actors. This eradicates the risk of key compromise or misuse. Protocols without an admin key are immutable. They are governed by predefined rules and once initiated, they can never be changed. Transaction execution is solely governed by code, exemplifying the principle of “Code is the law.”

However, protocols without an admin key also come with drawbacks. Immutability can lead to inflexibility in bug fixes and optimizations. Upgrading to a new version often requires deploying an entirely new set of codes and necessitates asset migration to the updated version. This process introduces additional challenges and potential disruptions for users and the protocol.

Which protocols are without an admin key?

The only ones I know are Uniswap and DeGate. These protocols go all-in in trustlessness.

TLDR — Takeaways

Stay alert for every transaction.

Double, triple check URLs, social accounts and HTTPS.

Opt for protocols without admin keys for enhanced security and peace of mind.

Revoke token approval after every transaction. For trading purposes, use DeGate, which does not require token approval at all.