0xBeans.eth Profile picture
May 25 9 tweets 2 min read
I get like 5-10 DMs a day asking about how to get better at solidity (some even ask if Im taking interns lol).

While this may be rudimentary and somewhat "obvious" knowledge, I'll try to explain the concept that really helped me "get it" when I first started learning.
When you interact with Ethereum, a majority of the time you're transferring some sort of token from your own wallet to another.

It's common to think "transferring a token" is an actual action of sending something to someone. ie the token is actually getting "sent".
However, it's much more simple than that.

There isn't actually "3 tokens" in your wallet, it's just a number (your balance) that represent how many tokens you should have.

So when you're 'sending' a token, it's just a simple increment/decrement of the 2 wallet balances.
I know this is simple, but personally, once I REALLY understood that everything is just a number in a ledger that gets updated (that wallets and contracts can look up), I started to be able to better conceptualize how to create contracts / modify existing ERC standards.
For example, these are the 'rules' for most tokens in your wallet.

1. Your balance starts at 0 -> my_balance = 0
2. When you receive tokens, increase your balance
3. When you send tokens, decrease your balance
4. When someone requests your balance, return my_balance
So understanding that the amount of tokens you 'own' is a simple variable that returns a number based on certain rules (ie increments/decrements every time you send receive), we can do some cool things.
We can modify the rules for a token such that every time someone receives a token, we multiply their balance by 2. Or maybe take 10% of the received tokens and donate it to a DAO.

We can literally do anything since balances are just numbers calculated by arbitrary rules we set
So for my implementation of token dripping, I changed how my_balance is calculated.

Rather than my returning the actual number of my_balance when someone requests how many tokens I own, I returned my_balance + (emissionRate * length of time I started dripping).
Not sure if this is super helpful and I know it's 'common' knowledge and 'no shit the blockchain is just a ledger', but really grasping this concept helped me a ton - like it was an awakening experience for me lmao.

Maybe just me tho xD

• • •

Missing some Tweet in this thread? You can try to force a refresh

Keep Current with 0xBeans.eth

0xBeans.eth Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!


Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @0x_Beans

May 24
Im curious if theres any cool implications by fractionalizing NFTs into 1155s vs ERC20s - talking specifically about fractional ownership of NFTs

Most (if not all) fractionalization protocols split NFTs into fungible ERC20s - this causes slight disconnect between the two.
NFTs are typical viewed/bought on marketplaces but ERC20s are bought on AMMs

But fractionalizing via 1155s would let both the NFT and fractions be viewed/bought on the same marketplaces -> less context switching, more seamless?

Also you can make the 1155s look pretty too lmao
I dont see many ERC20 fractionalized shares driving a lot of volume on AMMs which makes me believe ppl are treating these fungible tokens almost as non-fungible shares (essentially holding the ERC20 like it's an NFT in their wallet).

NFTX liquidity is basically non-existent lmao
Read 4 tweets
Apr 30
Just did a brief review of the Yuga OtherDeeds contract.

Here are some interesting things I found:

First, there is a lot of logic for a Dutch Auction. Yuga clearly said they're not doing a DA but the public mint still relies on a DA pricing functions.
Unless Yuga is lying, I believe they wrote this logic previously when they did actually decide to do a DA but just left in this code when they decided not to do the DA (or just forgot).

A little weird though, I would think Yuga would've cleaned up their code before launch 🤷‍♂️
Regardless, this wont affect public mint price as they can simply make the starting DA price and ending DA price the exact same.

The only problem I see is that grabbing pricing information like this wastes gas. I would've liked to see Yuga redeploy this contract with no DA logic
Read 12 tweets
Apr 28
If you want to experience the seamlessness of not having to 'claim' tokens, and just getting tokens dripped to your wallet, I deployed a Test ERC20 that uses DRIP20 on the Goerli test net.

Add your wallet to start getting drips. You'll accumulate .25 tokens per block (~1600/day)
This is the contract goerli.etherscan.io/address/0x7947…

The token is called "mock". These tokens are worthless but its just to showcase how token dripping works.

Here are the steps to add your wallet and start getting token drips:
Switch to the Goerli test network (go into your met*mask settings to add the network).

* you need goerli eth in your wallet to pay for gas btw - go to working goerli eth faucets to claim some eth. If faucets dont work, comment and Im sure someone will send you some :) ImageImage
Read 9 tweets
Apr 4
Still nerding out so here's a little thread: 😆

First, the core insight is the fact that bitwise operation EVM opcodes uses far less gas than the arithmetic exponent EVM opcode.
Bitwise operations use 3 gas while arithmetic exponent uses variable amounts of gas dependent on the number of bytes in the exponent.

For my use case, it was about 2-3x cheaper to use bitwise ops.

Just to illustrate:

uint256 var << 14 (338 gas) vs uint256 var ** 2 (782 gas). ImageImage
Let's first start at what my initial goal was:

Essentially, I wanted each tokenID to map to a mutable set of values as well as be able to change those values.
Read 16 tweets
Mar 22
Gonna end the $APE content with 1 final thread. Let's dive into how this absolute fucking chad borrowed 5 bored apes, claimed $APE for all of them, returned the apes, and subsequently netted ~600k.

A story of how a bot looked for value where no one else did.
First we have to understand what flash loans are.

Flash loans are a DeFi concept that allow a contract to borrow large sums of money as long as the loan gets paid back within 1 txn.

If the loan isn't paid back in 1 txn, everything is reverted (as if nothing happened).
"How" this all happens in 1 txn is beyond the scope of this thread.

Typically flash loans are used for arbitrage, front running, etc. Here's an example of how you would use a flash loan if you detected an arbitrage opportunity.
Read 19 tweets
Mar 21
Here's the awaited follow up :)

I'll clarify some questions that people have asked and also go over some easy ways to prevent getting sandwiched.
How does the bot sell their coins at a higher price if the buyer already bought coins?

On DEX's, there is no buyer/seller. You're swapping tokens directly from a liquidity pool based on *math* that makes this profitable (I wont go over how DEX's work, lots of resources online).
Is this the same as front running?

Yes and no. Sandwich attacks are also known as frontrun/backruns (cause you submit 2 txns, 1 ahead and 1 behind the sandwiched txn).

However, there are other front-run attacks.

All sandwiches are frontruns, not all frontruns are sandwiches.
Read 23 tweets

Did Thread Reader help you today?

Support us! We are indie developers!

This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Don't want to be a Premium member but still want to support us?

Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal

Or Donate anonymously using crypto!


0xfe58350B80634f60Fa6Dc149a72b4DFbc17D341E copy


3ATGMxNzCUFzxpMCHL5sWSt4DVtS8UqXpi copy

Thank you for your support!

Follow Us on Twitter!