). This means the logic for WETH is contained in a simple smart contract on the Ethereum blockchain. WETH wraps 1:1 over ETH and allows you to more easily use ETH in various dApps.
Notice the balance mapping on line 32, this is the mapping that stores how much WETH every user has.
Let's look at the core functions: deposit, withdraw, and transferFrom.
The deposit function (line 38) is quite simple. You get as much WETH as the ETH you're depositing. On line 39, the balance of the user is increased by how much ETH they sent in the transaction.
Withdraw (line 42) is also pretty simple. The contract first makes sure your balance is less than or equal to the withdrawal amount. After that, it decreases the user's WETH balance and sends that amount of ETH back to the user.
TransferFrom (L63) is pretty similar. It first checks that the user has sufficient WETH to transfer. It then does an approval check (L69-72) if someone other than the user is transferring. Finally, the balances of the source and destination accounts are adjusted.
As we can see here, it's not possible to have more/less ETH in the contract than was deposited. The code dictates that whatever ETH you've deposited into the contract will be available to withdraw. If you see any comments of WETH insolvency, you can safely ignore them.
• • •
Missing some Tweet in this thread? You can try to
force a refresh
The file I'll be analyzing is InvisibleFriends3D.sol.
Here's what I liked:
#1 The use of ERC721A. For those that aren't familiar, this an optimized ERC721 implementation that does really well for batch minting (among other things). In the IF case, you could mint 1 NFT for every IF you own which is a perfect use case for 721A.
It's extremely easy to create a "spoof" token to trick users into thinking a real token has been transferred.
In fact, it only took 16 lines of code to create this fake USDT token below.
Here's how spoof tokens work and how you can avoid being fooled going forward 🧵:
First of all, what are "spoof" tokens?
They're fake ERC20 tokens that scammers will create to mimic a real token. The goal is trick users into buying the spoof token. You'll often see spoof tokens pop up during airdrops or major crypto events (like the FTX fiasco).
Here's the link to the fake USDT I created: goerli.etherscan.io/token/0xc772b1…. As you can see, the token name and symbol can be set to anything. Good spoof tokens will often involve a lot of fake transfers/airdrops to further deceive users.
With the events from the past week, It's become clear that being able to read a block explorer is an important skill to have. Doing so will allow you to understand what's happening on-chain without needing to trust anyone else.
Here's a simple guide on how to read Etherscan 🧵:
I'm going to break down two common types of transactions that happen on the ethereum blockchain:
- transfers of ETH
- transfers of ERC20 tokens
You've probably heard this term thrown around a lot. You've probably also heard of WETH. Let's go over what these words mean in simple terms so you gain a better understanding 🧵:
If you haven't already, check out one of my previous threads on what exactly an ERC is:
In simple terms, an ERC20 token is a "fungible" token. How is this different from a "nonfungible" token?
Every ERC20 token is exactly the same - there are no unique traits to any of them. You can trade one for another and you wouldn't see a difference. The value is the same.
. This goes over a more optimal approach to the problem.
The solution I'm showing you here takes advantage of a reentrancy loophole.
Reentrancy attacks happen when a function in Contract A makes a call to Contract B. Contract B then recursively calls Contract A, and normally takes advantage of the state not changing.
. The goal is to mint 150 NFTs in an efficient manner.
There are a couple ways to do this challenge: I did it using a reentrancy attack and a simple loop. I'll go over the 2nd method since it's more efficient and simpler.
We start with an empty contract and want to use this contract to mint from the NotRareToken (NRT) collection. The first approach that comes to mind is looping 150 times, calling mint(), and transferring the token back to the caller in each iteration.