To Breakout in DeFi – Making Your Users Play Multiple Rules at Once (Unknowingly)

Disclaimer: I’m working for Term Structure, which is building TermMax, and I hold $AAVE, $TIME, and $PERP. 

In the early days of DeFi, protocols like IDEX and Dharma often struggled with the chicken-and-egg problem. Modern successful protocols solve this by allowing users to unknowingly play multiple roles simultaneously. Instead of treating borrowers, lenders, traders, and liquidity providers as separate entities, they designed systems where one user could seamlessly fill multiple roles—often without even realizing it.

In this article, we will explain the benefits of multi-role design and examine some successful protocols from the past and future to understand how their design achieves these benefits. 

The Power of Multi-Role Design

While the multi-role approach might seem like a clever technical design choice, its real power lies in the business advantages it creates. When users play multiple roles automatically, protocols can achieve rapid growth with significantly lower capital requirements and marketing costs.

Think about traditional DeFi protocols: to attract $1 million in lending liquidity, you might need to spend heavily on yield farming incentives or marketing campaigns targeting sophisticated liquidity providers (LPs). But in a multi-role system, that same $1M might come naturally from borrowers’ collateral or traders’ positions, with no additional acquisition costs.

This design approach creates several compounding benefits:

  • Zero marginal cost for additional liquidity, as it comes from existing users
  • More substantial network effects as each new user adds multiple forms of value
  • Better capital efficiency since the same assets serve numerous purposes
  • Additional revenue streams that can be shared with users to increase their returns

Below, we will examine how different protocols have implemented this approach, each with its innovative twist.

Established Successes

Let’s look at three protocols that adopted this approach: Aave v1, Perp v1, and Fluid. 

Aave v1 – Borrowers as Lenders 

ETHLend, the predecessor of Aave, tried to build an on-chain pawn shop in a peer-to-peer fashion. In this model, one borrower submits their collateral and terms, such as the interest rate, on-chain, and vice versa for lenders. 

However, it failed to gain traction because 

  1. There were only limited on-chain users back then, and 
  2. It took time for two coincidences of wants to meet. 

As such, ETHLend rebranded itself to Aave and pivoted to a peer-to-pool model. 

On Aave v1, the interest rates for lenders and borrowers are determined algorithmically. Lenders deposit into the pool and start earning interest paid by existing borrowers. The more assets deposited by the lenders, the lower the interest rate they earn and the borrowers pay.  

What makes the system efficient is that borrowers are lenders at the same time. 

Let’s say Alice wants to borrow DAI against ETH on Aave v1. She deposits ETH on Aave v1 and then withdraws DAI from the pool. Her ETH started earning yields the moment it was deposited, as the collateral now becomes part of the pool that is used to fund previous ETH borrowers. That’s why I said borrowers are also lenders. 

So, from an operator’s perspective, to kick-start such a system, you only need to list the eligible collateral, which should also have some demand for borrowing, and seed initial borrowable assets. And then, the flywheel will start itself. Thanks to the over-collateralization nature of Aave, the more borrowers it attracts, the more liquidity there will be for borrowers down the line. This is also known as rehypothecation from traditional finance (TradFi). 

Well, if you don’t live under a rock, you probably know that Aave has been the largest money market since its genesis. So, I’ll skip the hassle of explaining how dominant it is. 

Perpetual Protocol v1 – Traders as LP 

Perp v1 is the Uniswap v2 equivalent, but for perps trading. The protocol’s AMMs used the classic x*y=k formula to market-make perps markets. But that’s the end of the similarities. On Perp v1, there is no LP in the traditional sense. Instead, Perp v1’s traders are LPs themselves. 

What do you mean by that?

When a perpetual market is created on Perp v1, such as the SOL perpetual market, the team manually sets the initial price and the x and y in the vAMM without adding any assets. Suppose the SOL price on another exchange rises above the set initial price on Perp v1. In that case, traders can arbitrage by opening a long position with USDC on Perp v1’s SOL market while simultaneously taking a short position on another venue. However, this trader cannot close their positions on Perp v1 until other traders enter to push the price higher. Technically, they can close their positions, but it doesn’t make sense for two reasons:

  1. It incurs fees (which go to the Insurance Fund), and
  2. They are the only one pushing the price up, so closing their position will just revert to the market price to the initial price. 

To encourage traders to align the prices between Perp v1 and other derivative exchanges, developers implemented a funding rate system, where the greater the price difference, the higher the funding rate is set. If there aren’t enough traders on one side, let’s say the price on Perp v1 is still lower than that on Binance, while all of the open interest is long, the Insurance Fund will act as the one that pays the funding payments to the long holders.
 

In other words, on Perp v1, the counterparty for each trade is other traders. As for the Insurance Fund, it acts as a counterparty only for funding payments. 

Perp v1 was the fastest-growing derivative DEX at the time and was the largest one in its prime, in terms of trading volume (even higher than Dydx v1!). However, due to its design flaw, the protocol imploded around 2021. 

Fluid – Borrowers as LP 

Fluid by InstaDapp is a money market and a DEX 2-in-1. It is unique because the platform’s borrowers also act as DEX LPs (in addition to acting as lenders). 

Huh? How does that work? 

If you read before, you know that Aave v1 merges the line between a borrower and a lender. Fluid takes this one step further by making borrowers LPs on their decentralized exchange (DEX). 

Let’s say Alice wants to borrow USDC against wstETH on InstaDapp.
She deposits her wstETH into a Smart Collateral Vault and then withdraws USDC from Fluid’s pool. In the same transaction, part of the deposited wstETH is swapped into ETH, and both are deposited into the DEX on Fluid. The ETH-wstETH liquidity will then facilitate swaps in either direction and as liquidity for borrowing. 

The existence of an internal DEX not only diversifies Fluid’s revenue stream but also helps reduce the effective interest for the borrowers, as the fees earned from their collateral negate some, if not all, of the borrowing interest. 

Since the introduction of Smart Collateral Vault in late 2024, Fluid has been one of the fastest-growing protocols. Its TVL skyrocketed after the feature was introduced. Heck, we can even see some large positions migrating from Aave to Fluid.   

Fluid is the fastest ever to hit $10 billion in volume on Ethereum. Source: https://x.com/troyharris__/status/1887489634612940952

The Next Wave

But are there any upcoming projects with similar attributes mentioned above? Yes, there are two, afaik. 

TermMax – ███████

TermMax is the Uniswap v3 for fixed-rate lending and borrowing. 

You can borrow and lend with range orders and one-click to open a levered position on the protocol. By default, the loans on TermMax are at fixed rates with maturity dates. However, borrowers can repay at any time through the AMMs. 

TermMax utilizes three types of tokens internally:

  1. FT (Fixed-rate Tokens): ERC-20 tokens granting holders the right to receive interest (paid by the borrowers) after maturity. Users receive FTs when they successfully lend their assets.
  2. GT (Gearing Token): ERC-721 tokens representing a borrower’s positions (leveraged or not), detailing collateral and debts.
  3. Vault Token: ERC-4626 standard tokens represent vault share, which is not applicable for this article. 
This section will be updated when the feature is live. Stay tuned. Trust me - it would be fun :)

Timeswap v3 – Lenders as Options Underwriters

Timeswap is an Oracle-free, fixed-rate borrowing and lending platform. There is a concept on the platform called “Transition Price”. No, it’s not about the amount of money that you pay to transition your gender. It’s about the price, which, if surpassed, lenders will receive borrowers’ collateral instead of the asset they deposited.

Let me use an example on Timeswap v2 to explain. 

Say Charles wants to lend 1000 USDC in the following market, where borrowers use $PENDLE as collateral.

A screenshot on Timeswap where it shows a pool consisting $PENDLE and $USDC.

There are two possible outcomes on the maturity date:

  • If $PENDLE is above $2.8: Charles receives 1008 USDC (principal + interest). 
  • If $PENDLE is below $2.8: Charles receives 360.2611 $PENDLE (≈ 1008/2.8). 

If you’re financially savvy enough, you probably feel this is more like an option protocol disguised as a fixed-term money market. Because it is! In the example above, Charles is, in fact, underwriting a put option where the option buyer (the borrowers) can sell $PENDLE at $2.8. In return, Charles receives premiums in the form of interest on the loan. 

Timeswap developers will provide a UI for options trading and looping in their next iteration, Timeswap v3. Although the trading volume for on-chain options is abysmal, I’m still quite excited about Timeswap v3, as a single liquidity can serve both borrowers and option buyers.

Conclusion

The lesson for teams building new DeFi protocols is clear: Don’t just think about attracting different types of users – find ways to make each user unknowingly play multiple roles. 

This approach solves the bootstrapping problem, strengthens network effects, and creates more efficient markets. The most successful protocols don’t just build better products—they design clever systems where users fill multiple roles at the same time.

Work smarter, not harder. 

Leave a Comment

Your email address will not be published. Required fields are marked *