paint-brush
Your Airdrop 'Dust' Can Finally Be Useful—Thanks to This Ingenious Protocolby@menaskop
335 reads
335 reads

Your Airdrop 'Dust' Can Finally Be Useful—Thanks to This Ingenious Protocol

by menaskopNovember 26th, 2024
Read on Terminal Reader
Read this story w/o Javascript
tldt arrow

Too Long; Didn't Read

The ERC-6551 proposal could really help the web3 community move toward truly decentralized liquidity.
featured image - Your Airdrop 'Dust' Can Finally Be Useful—Thanks to This Ingenious Protocol
menaskop HackerNoon profile picture

Thanks to an article on Hackernoon and my research work, I came across a number of projects in the NFT 2.0 space, and today, I invite you to explore one of them together: presenting DAO Envelop and our shared stance on decentralized and fragmented liquidity.


Specifically, in the first part, we'll discuss decentralization, and in the second, we'll move on to fragmentation. So, let's get started!

Introduction

The blockchain trilemma suggests that decentralization, security, and performance cannot fully coexist at 100% simultaneously. Many blockchain solutions focus on performance: Solana, Ton, Aptos, and others. TPS (transactions per second) has become a key metric for the market. Far fewer blockchains prioritize security, and in this sense, Bitcoin remains the unrivaled leader.


But what about decentralization, the very principle that everything was originally built around? Of course, we have Ethereum’s million validators and tens of thousands of Bitcoin nodes, but does decentralization end there? It seems not.

Decentralization levels

In our view, decentralization can be broken down into several aspects or, more accurately, levels, if we combine various networks, ecosystems, protocols, and decentralized applications into a unified whole:

  1. Technical decentralization: This relates to how many pools are mining a coin within a blockchain with a PoW consensus, how many validators and sequencers are in PoS networks, how many nodes exist in a particular ecosystem, or how a dApp is built—whether it uses a decentralized backend (IPFS, blockchain, etc.) or something else.
  2. Organizational decentralization: This usually refers to DAOs: is a protocol, a specific application, or even a service governed by a Decentralized Autonomous Organization, or by someone or something else? This can range from low decentralization, where everything is run by a company, to medium decentralization (which Sushi Labs recently adopted), or the highest level, where a DAO has a sufficient number of participants (thousands or more). For a network, this can be reflected in the number of wallets and a fairly even distribution of their balances (where whales don’t control 50% or more).
  3. Legal decentralization: This means that an entity doesn't belong to any one jurisdiction but adheres to universally recognized principles and norms of law and ethics. While most fall under this category today, not all have the same approaches to implementation.
  4. Economic decentralization: Arguably the most complex, because while everyone is focused on technical decentralization, many have worked hard to achieve legal neutrality and community-level decentralization. Yet in the economics of dApps, protocols, and entire networks, a single metric has become dominant—TVL.


We understand that it's easier to determine a system's importance based on the amount of locked funds, but this carries three major forms of deception:

  • First, we assess not crypto-TVL but its fiat value in dollars, thereby undermining the conceptual beauty of crypto-finance.
  • Second, TVL is often a reflection of whales, and it can be manipulated, as seen in numerous examples, ranging from zkSync's recent analysis to meme-coins and meme-tokens, where manipulation is the norm (although this is not the norm for the market as a whole).
  • Third, hacking protocols has become simpler and more frequent. Look at the statistics of DeFi hacks over the past three years and recall the high-profile cases, including the hacks of Harmony, Binance bridges, and many others, where losses reached tens or even hundreds of millions. In 2023 alone, the total exceeded $5.7 billion, and around $3 billion in 2022.


To shed even more light on the situation, we invite you to review the statistics below.

Direct correlation: TVLs are hacks

Graph #01. Hacks by DeFiLama statistics:

What gets hacked most often? Not a comprehensive list:

  1. CEXs;
  2. Bridges;
  3. AMMs (DEXs);
  4. Lending protocols;
  5. Other.


Let's see an example of bridges hacking (Graph #02):


$1.3 billion in direct losses: and that’s not all, it’s just for 2022. $1,300,000,000 is an entire market, and there are also rug pull schemes, direct scams, and other activities that revolve around TVL. The larger something is, the greater the desire to steal from it.


Alright, the problem is clear. But is there a solution? There is, and not just as an idea, but in its implementation as well.

Decentralized liquidity

To start with, a bit of theory: we can try to describe several approaches to decentralized liquidity (DL), and from there, conclude that there are at least a few methods for practical DL implementation:


  1. Creating pseudo-pools in a 'many-to-many' relationship: In this case, using provided approvals, we collect a pool (for example, DAI), but we do not disclose the participants of the pool until the transaction is complete (and with zk-mechanics, even afterward). Then, we open another pool, say for USDe, and when the sum reaches a specified amount (which only the exchange parties know), the funds are deducted and transferred using a decentralized oracle. This approach has proven to be complex in execution, although several MVPs are available for hands-on experience. The biggest issue here is creating a source for starting collections—some sort of conditional page, even within IPFS, where participants can technically create various pools.
  2. Creating wNFTs and other vaults (Vaults/Collateral): These essentially represent wNFT collections, each of which is a micro-pool. This approach is much easier to implement than the first and is accessible to everyone through the development of no-code tools that can be used in a 'wNFT smart contract factory & template design' bundle. This approach will be demonstrated further in the article.
  3. Developing a platform where payment peers (PP) can meet: Payment peers could be any entities—individuals, companies, or bots—that can conduct various payments, whether fiat or cryptocurrency. The decentralization aspect here is that each PP contributes its own collateral and risks only that, unlike the standard DeFi approach where 100% of LP capital is frozen. PP, on the other hand, generates revenue on 100% of the capital without freezing all of it (e.g., 90% is in circulation, and only 10% serves as collateral). This approach has also been implemented and tested, but we will discuss it separately.


Now, let’s try to describe DL in a specific implementation.

Implementation

“Keeping in mind all said above we can exactly name at least two the 'bottlenecks' of the Envelop protocol (older versions): (i)the entire collateral for wNFTs was stored in a single contract. This also led to additional costs, as (ii)the contract had to maintain a registry of issued wNFTs, including the composition and volume of collateral for each wNFT.


To move toward truly decentralized liquidity (DL), we need to conceive its ideal model. In our view, the more addresses with a non-zero balance of a given asset are exists, the higher its degree of decentralization takes place. From this perspective (storage location), a multitude of EOAs that have approved the use of a certain amount of a particular asset forms an ideal pool (see point 2.1 above).


However, EOAs themselves have architectural limitations. For example, EOA 1 cannot delegate to another EOA 2 the right to spend its balance of the native network coin (in an EVM network).


More than a year ago, an interesting proposal for improvement was submitted to the Ethereum community: ERC-6551: Non-fungible Token Bound Accounts. The authors suggested using a Minimal Proxy Contract (ERC-1167) as a smart wallet, with an NFT confirming ownership of this wallet.


In the new version of the Envelop protocol, we tried to take another step forward—and a slight step to the side :). We decided not to complicate the proxy contract itself but instead turned its implementation into an NFT contract with a single token: the Envelop Singleton NFT.


Thus, in the new version of the Envelope protocol, wNFT is the both simultaneously: a pool and a wallet . Additionally, there is no longer reason to maintain a collateral registry for each wNFT.


Everything were ever transferred to this contract address will be considered as the collateral for the wNFT.


This wNFT structure allows for the construction of new properties and mechanisms for DeFi dApps, including pools.


For example, Most of readers familiar with trouble to manage balances of low-liquidity tokens received from various airdrops. Even if you’re lucky enough to find a pool where you can sell this 'dust,' the cost of gas for approval + swap will likely make the transaction costly.


If you participate in such activities with an Envelop wNFT wallet, the cost of transferring ownership of all these assets would be reduced to the cost of transferring your wNFT (which, as a reminder, is a wallet-as-well) to another address.


Now, imagine transferring such wNFT with 'dust' to the balance of another wNFT wallet. Logically that could be called a pool. But actually the balances of all assets are distributed. Like a Christmas tree with ornaments, each ornament represents a wNFT wallet.


All these 'ornaments' hang on the same tree, wNFT wallets belong to one wNFT pool. We could extend this Christmas metaphor further when Santa comes into the picture, but we’ll leave that enjoyable task to our readers. Let's just note that the balance records in ERC20 contracts did not change during "hanging toys on the Christmas tree"...


Of course, this is just a rough draft of the architecture. But we hope we've managed to explain the idea. This is why we believe the Envelop Protocol V2 is a step toward TRUE DL”.

Explanatory charts

#03: DL's overall defense scheme:


The essence of the scheme is that we gradually increase the complexity of DL (decentralized liquidity):

  1. First, we create an equality where 1 wNFT (1 smart contract) = 1 pool.
  2. Then, we add a decentralized oracle, which makes decisions in negative scenarios (for example, if a critical vulnerability is discovered and time is needed to address it).
  3. Finally, we add a decentralized time oracle, which makes the pools asynchronous and allows the use of a portion of them in one iteration to hedge risks.


Of course, this approach won’t protect us from 0-day vulnerabilities, but it doesn’t need to. It is aimed at preventing a much larger number of classic attacks, which are the primary source of harm for DeFi projects and the broader crypto ecosystem.


Additionally, standard security measures are also applicable here, from open-source code and community audits to security audits by leading firms, and incorporating protective mechanisms already developed in DeFi.


In addition to the external protection scheme - there is also an internal one. #04:

The essence of the scheme is that, at each step, we add layers of protection:

  1. First, we introduce encryption for cross-liquidity.
  2. Then, we encrypt the Collateral wNFT (micro-pool).
  3. Next, we decentralize the Oracle (essentially turning it into a decentralized arbitrator and escrow).
  4. After that, we add a condition mixer so that it’s unclear which micro-pools were used in any given transaction.
  5. Finally, we introduce one-time keys, where the exchange of these keys constitutes the DL exchange, and only in the final transaction do we close the entire exchange chain, making censorship of the transactions—and especially their hacking—extremely difficult and unlikely.


Of course, both external and internal layers, as we repeat, can be hacked, like anything in this world, but it’s far more difficult than with centralized liquidity. We demonstrated this in the diagram. Chart #05 DL vs. CL (Trust & Time):

The essence of the two graphs above is that trust in centralized protocols grows faster over time, but as a result, we end up with high TVL figures, meaning that a single hack can devastate the entire ecosystem. The old rule of 'not putting all your eggs in one basket' doesn’t apply here and is even rejected. At the same time, we can look at these same graphs from a different perspective.


#06 DL vs. CL (Liquidity & Time):


As we can see, the increase in liquidity in this case is more evenly distributed and even in case of overlapping of a number of projects, applications, protocols, services - remains at a much higher level of decentralization than in the case of CL (centralized liquidity).

Perspectives and Reflections

In our opinion, the near future will see liquidity decentralization on one hand and fragmentation on the other, leading to increased competition—both of which will play a key role in shaping ecosystems.


In light of this, we will further explore the second aspect (liquidity fragmentation). For now, that's all—stay tuned!


P.S. Interestingly, while this article was being written (over the course of 3 months), Squarespace was hacked, impacting hundreds of crypto projects of various scales. A clear example of liquidity decentralization in action!