Aave also allows those will idle assets to earn a relatively safe return on capital from lenders, whose rates are determined by a curve.
We're in the phase of the market where there's a lot of retail inbounds but not enough education about the Ethereum ecosystem and DeFi.
So, let's break down the basics of some of the top protocols.
First on deck: Aave (@AaveAave), an Ethereum-based money market protocol.
A 🧵
Aave also allows those will idle assets to earn a relatively safe return on capital from lenders, whose rates are determined by a curve.
Users would hold BTC, ETH, and other assets (including many ERC-20 tokens) with no expectation of a native yield or dividends.
ETH, for instance, was long just an asset for transaction fees, as was Bitcoin.
Users can deposit a variety of assets as collateral, then use that collateral as ammo to borrow other assets to be used in DeFi or beyond.
Loans are *overcollateralized*.
1. Those looking for steady, relatively safe yield on idle assets.
2. Those that want to leverage their assets by borrowing against their holdings, then trading and spending the loan to achieve utility beyond the rate they pay.
- Find idle assets that can be lent out on Aave
- Deposit said assets
- Earn a per-block, pro-rata interest paid for by those that borrow your assets (assets are pooled, then used) from the protocol
- Find inactive, useless asset
- Deposit it into Aave
- Enable it as collateral
- Borrow desired assets from protocol
- Use borrowed assets for trading, yield farming, spending, etc.
Shorting:
A user can borrow an asset from Aave, sell it, buy it back when the price is lower, then pocket the delta.
This works because the loan is denominated in the asset(s) borrowed.
ETH natively does not produce yield.
It can be used as collateral to borrow assets that *can* earn yield.
Assuming you can earn 15% on USDC and borrow @ 5%, borrowing USDC at a 200% collat. ratio will allow for an effective yield of 5% on ETH.
Say a user is holding Wrapped Bitcoin and wants something on-chain or IRL, though doesn't want to get rid of their WBTC exposure.
A user can collateralize their WBTC, buy what they want, then pay back the loan with income or other assets to reclaim their WBTC.
Aave pioneered flash loans, a concept where anyone can borrow any amount of capital within a single block for a number of use cases.
Did a thread here in the past.
https://t.co/FRn5Pj2TFk
If you've been following DeFi or Ethereum over the past few months, you've likely heard the term "flash loan" mentioned again and again.
— Nick Chong (@n2ckchong) October 29, 2020
This new DeFi primitive has been at the core of a number of economic exploits and arbitrages.
A thread on the basics of flash loans - \U0001f447 pic.twitter.com/uOQC2tzlYl
- A user borrowed 2,048,000 USDC from dYdX
- Traded that USDC for 2,028,367 DAI in Curve's Y pool
- Traded that DAI for 2,064,182 USDC in Curve's sUSD pool
- Paid dYdX back + 2 wei
All in one block...
Profit: 16,182 USDC
Cost: $60 in gas
I'll cover:
- Interest rates
- Terms
- Liquidations
- aTokens
The more an asset is utilized, the higher the rate lenders earn and borrowers pay.
The borrow rate is always above the deposit rate.
Here's the borrow rate model for USDC / USDT.
To mitigate unexpected spikes in utilization affecting the rate one pays on their loan, users can lock in a fixed rate, so they can manage risk properly.
This rate can readjust based on market conditions.
Aave has a number of loan terms that dictate how much one can borrow, at what point they are liquidated, and how much they pay when they are liquidated.
These terms are determined by a risk team, who assess market conditions to minimize risk to protocol collateral.
Unlike traditional loans, Aave loans are liquidated autonomously when a user's loan-to-value ratio falls below certain values.
A large enough drop in the value of one's collateral will allow users to bid the collateral, sell it, then pocket a bonus.
aTokens are yield-bearing assets that accrue interest in real time, allowing one to watch their deposited assets grow by block.
It can be used by other developers to build interesting applications and use cases.
For instance...
@APWineFinance: APWine allows users to trade unrealized yield
etc.
aTokens, flash loans, etc. can all be used in tandem with other contracts to create use cases.
More from Crypto
"Blockchain technology is energy-intensive..." => No, it doesn't have to be.
Let's look at Proof-Of-Stake, an alternative to the energy-intensive Proof-Of-Work algorithm.
🧵🔽
1️⃣ A Quick Recap On Proof-Of-Work
A Proof-Of-Work algorithm requires miners to do a certain amount of work that is compute-intensive to gain access to a service or the right to do something. This algorithm, by design, also requires that the work done shall not ...
... be reusable for anything else than what it was performed for. This lies at the core of the security concept of a blockchain. To gain the right to append a new block to a chain and to get some currency as a reward, there is work to be done, and this work must be verifyable.
That work is a race between different miners. Many miners try to compete and to be the first to find the answer to a problem presented to them. This implies that a lot of energy is wasted as only the first correct solution is accepted.
You can find a more detailed thread on Proof-Of-Work
Let's look at Proof-Of-Stake, an alternative to the energy-intensive Proof-Of-Work algorithm.
🧵🔽
1️⃣ A Quick Recap On Proof-Of-Work
A Proof-Of-Work algorithm requires miners to do a certain amount of work that is compute-intensive to gain access to a service or the right to do something. This algorithm, by design, also requires that the work done shall not ...
... be reusable for anything else than what it was performed for. This lies at the core of the security concept of a blockchain. To gain the right to append a new block to a chain and to get some currency as a reward, there is work to be done, and this work must be verifyable.
That work is a race between different miners. Many miners try to compete and to be the first to find the answer to a problem presented to them. This implies that a lot of energy is wasted as only the first correct solution is accepted.
You can find a more detailed thread on Proof-Of-Work
Proof-Of-Work is the name of a cryptographic algorithm that is used for some blockchains when new blocks are to be appended to the chain.
— Oliver Jumpertz (@oliverjumpertz) April 3, 2021
Let's take a higher-level look at how this one works, shall we?
\U0001f9f5\U0001f53d
1/ ERC-20 token standard approve() has caused an unnecessary cost of $53.8M for #Ethereum and #DeFi users
This is bad. Continue reading why and how to avoid this in the future.
👇👇👇
2/ Before you go all rage on the flaws of my analysis, please read the whole Twitter thread for disclaimers and caveats.
3/ approve() is an unnecessary step of ERC-20 tokens when they interact with smart contracts.
You know this because when you do a Uniswap trade you need press two transaction buttons instead of one.
4/ Why there is approve() - you can read the history in this Twitter
5/ I queried all approve() transactions on Google BigQuery public dataset and calculated their ETH cost and then converted this to the USD with the current ETH price.
This is bad. Continue reading why and how to avoid this in the future.
👇👇👇
2/ Before you go all rage on the flaws of my analysis, please read the whole Twitter thread for disclaimers and caveats.
3/ approve() is an unnecessary step of ERC-20 tokens when they interact with smart contracts.
You know this because when you do a Uniswap trade you need press two transaction buttons instead of one.
4/ Why there is approve() - you can read the history in this Twitter
1/ I just spend my Saturday morning on a call with a crypto fund explaining to them how #Ethereum ERC-20 token approve() function works
— \U0001f42e Mikko Ohtamaa (@moo9000) August 29, 2020
I am too old for this shit. pic.twitter.com/7EYfOaRP5L
5/ I queried all approve() transactions on Google BigQuery public dataset and calculated their ETH cost and then converted this to the USD with the current ETH price.
You May Also Like
A brief analysis and comparison of the CSS for Twitter's PWA vs Twitter's legacy desktop website. The difference is dramatic and I'll touch on some reasons why.
Legacy site *downloads* ~630 KB CSS per theme and writing direction.
6,769 rules
9,252 selectors
16.7k declarations
3,370 unique declarations
44 media queries
36 unique colors
50 unique background colors
46 unique font sizes
39 unique z-indices
https://t.co/qyl4Bt1i5x
PWA *incrementally generates* ~30 KB CSS that handles all themes and writing directions.
735 rules
740 selectors
757 declarations
730 unique declarations
0 media queries
11 unique colors
32 unique background colors
15 unique font sizes
7 unique z-indices
https://t.co/w7oNG5KUkJ
The legacy site's CSS is what happens when hundreds of people directly write CSS over many years. Specificity wars, redundancy, a house of cards that can't be fixed. The result is extremely inefficient and error-prone styling that punishes users and developers.
The PWA's CSS is generated on-demand by a JS framework that manages styles and outputs "atomic CSS". The framework can enforce strict constraints and perform optimisations, which is why the CSS is so much smaller and safer. Style conflicts and unbounded CSS growth are avoided.
Legacy site *downloads* ~630 KB CSS per theme and writing direction.
6,769 rules
9,252 selectors
16.7k declarations
3,370 unique declarations
44 media queries
36 unique colors
50 unique background colors
46 unique font sizes
39 unique z-indices
https://t.co/qyl4Bt1i5x
PWA *incrementally generates* ~30 KB CSS that handles all themes and writing directions.
735 rules
740 selectors
757 declarations
730 unique declarations
0 media queries
11 unique colors
32 unique background colors
15 unique font sizes
7 unique z-indices
https://t.co/w7oNG5KUkJ
The legacy site's CSS is what happens when hundreds of people directly write CSS over many years. Specificity wars, redundancy, a house of cards that can't be fixed. The result is extremely inefficient and error-prone styling that punishes users and developers.
The PWA's CSS is generated on-demand by a JS framework that manages styles and outputs "atomic CSS". The framework can enforce strict constraints and perform optimisations, which is why the CSS is so much smaller and safer. Style conflicts and unbounded CSS growth are avoided.