<100 subscribers
At Gaslite, we’re enamored with one thing: really, really, really, ridiculously good-looking code. Bringing a magnifying glass to gas optimization failures is how our company was born, and it’s safe to say we’re still the only ones in the crypto space with the motto, “number go down.” Gaslite works tirelessly to make the gas lite (get it?) and to improve the overall standard for programming throughout web3. Moral of the story- we care about gas efficiency… a lot. Too much? Maybe. Obsessed? Probably. In an autistic way? Obviously.
Because we’re addicted to sharing our love for beautifully written code with the masses, we’ve compiled a 2023 Wrapped of the year’s top gas fails and gas wins, with a few egregious programming mess-ups sprinkled on top for fun. Gas bad. Gaslite good. Enjoy.
In 2023 we were perplexed to watch projects find new ways (and recycle what we had assumed were old ways) of hiking gas costs, seemingly for the hell of it.
Proof of Work Tokens
Out of the gate, VPMX released a token where users were incentivized to raise gas fees for everyone in order to receive more tokens for themselves. VPMX accomplished this gas travesty by using a “Proof of Work” token. “Proof of Work” tokens simulate a blockchain consensus mechanism that incentivizes network validation by rewarding miners for adding computational power and difficulty to the network. VPMX, created by the founder of Imageshack (lolll), allowed users to specify a “power” value. The higher the power, the higher the number of tokens the caller would mint. In other words, a user who input a power of [low number] would only receive [low number] but a user who input a power of [high number] would receive [high number]. The issue with this kind of incentive correlation is that a higher power creates more unnecessary loops and added computation resulting in higher gas costs.
(source: https://twitter.com/0xCygaar/status/1676699126682075136)
The success and noise from VPMX caused hundreds of other Proof of Work tokens to pop up. Most were dead on arrival, but POWERC20 made a splash. POWERC20 took a slightly different approach- the user had to provide a nonce (an arbitrary number that can be used just once in a cryptographic communication), and depending on the computed value of hashing the nonce with a few other values, the user was permitted to mint tokens. This resulted in thousands of users trying to mine, submitting failed transactions, and clogging the mempool, thus increasing gas for everyone. Please, let’s leave this nonce-sense behind in 2024.
(source: https://twitter.com/PopPunkOnChain/status/1734583214323155240?s=20)
NFT Whitelists
One of the most surprising things we noticed at Gaslite in (*checks notes*) the year 2023 were inefficient whitelists (???) in NFT smart contracts. To be honest, we thought that as an industry we had solved this kinda thing. There’s no shortage of resources on optimal, efficient ways to implement whitelists. (We’ve even added a comparison smart contract to the free Gaslite Core repository that benchmarks the popular whitelist implementations against one another. Please, we’re begging you, use it.) But, oh boy were we wrong. We respect consideration for end user experience, but deployers need to simultaneously consider their own gas costs. A poor whitelist implementation can absolutely break the bank for the deployer.
One example of whitelist tomfoolery was the “Magical Beings” NFT collection. We were assaulted with the horrors of Magical Beings’ contracts one day while innocently browsing through new and trending collections on OpenSea. When we pulled up their source code, our jaws dropped. Harrison audibly yelled “BLEHHHH” and started gagging at the screen. Magical Beings literally hardcoded over 200 lines adding addresses to their “isAllowedToMint” whitelist mapping in the contract. For the nontechnical folks reading this- Hardcoding the whitelist massively increased the size of their deployed smart contracts and, even worse, made the contracts extremely ugly to look at.
(source: https://twitter.com/PopPunkOnChain/status/1687105283397681152?s=20)
Another whitelist example, Machina Church, we found equally startling but for a different reason. At first glance, Machina Church’s whitelist implementation looks pretty standard… until you realize how poorly a naive mapping implementation for a whitelist scales. The deployer spent well over $6,000 to add just under 900 addresses to their whitelist. That, coupled with an inefficient for loop implementation, resulted in a waste of money the likes of which hasn't been seen since the pretty patties episode of SpongeBob. Real ones will know.
(source: https://twitter.com/PopPunkOnChain/status/1734686388975722877?s=20)
Sometimes we open crypto twitter and can’t help but audibly laugh at the absurdity of developer screw ups. We’re typically pretty quick to write a viral sh*tpost about this kinda thing (engagement + a teaching opportunity, chef’s kiss). But in case you missed any of the 2023 drama, here’s our highlight reel of coding mess-ups:
Pond0x
By far, one of the most quotable, memeable, and egregious things that we saw this year was Pauly0x’s first Pond0x token smart contract. The developer of this smart contract copy and pasted a test smart contract from Vectorized’s solady repository. This smart contract included a function called “directTransfer”, which allowed any user to transfer tokens from any user’s balance. Millions of dollars were spent and lost on day 1. The smart contract also includes a function called “_brutalize()” which does nothing, but had online publications scratching their head as to the functionality of it. We caught this quickly and put out a statement, but unfortunately thousands of users were still _brutalized().
(source: https://twitter.com/PopPunkOnChain/status/1684961007007932427?s=20)
BananaGun
BananaGun, one of the most popular telegram trading bots, launched its token in September and immediately crypto twitter discovered a fatal flaw. In the transfer function, they accidentally made their token permanently inflationary, because of a logic error where they were not deducting the full transfer amount from the sender’s balance. The BananaGun team quickly ditched the token to try again with a new smart contract. BananaGun claimed to have spent a great amount of time on the failed token, and alleged that the token contract had been audited. We hope they got a refund because even the most basic audit, or even ChatGPT, would have caught this dumb of a logic error.
(source: https://twitter.com/PopPunkOnChain/status/1702427820289634685?s=20)
Thirdweb
In December, Thirdweb vaguely dropped that their mightttt be an itsy bitsy vulnerability affecting their pre-built smart contracts ( you know, the contracts used to move millions of dollars across the space, nbd nbd). It took a bit to uncover what was actually happening under the hood. It turns out Thirdweb used a pattern in which they implemented Multicall and ERC-2771, both of which are libraries from OpenZeppelin. Separately, these 2 libraries are safe. But when used together, they create an attack vector for address spoofing. Whoops. The attack vector was created by wrapping malicious calldata within a forwarded request by using Multicall’s “delegatecall” to manipulate the “_msgSender()”, meaning any user could call any one of Thirdweb’s affected deployed contracts and “spoof” their identity to any address that they wanted.
It's hard to take responsibility for your actions but we were happy to see Thirdweb do just that.... Just kidding. They actually blamed the whole thing on "a security vulnerability in a commonly used open-source library in the web3 industry." To us, that's kind of like drinking alcohol with your Tylenol then blaming the bodega where you bought both items for your liver damage. Anyway, back to Thirdweb. To mitigate this dumpster fire, Thirdweb released a migration tool that helped projects affected by the vulnerability. Unsurprisingly, the migration tool was extremely expensive to use, requiring some users to spend tens of thousands of dollars from their own pocket. Yikes.
While there were plenty of sighs, groans, and banging our heads against the wall in 2023, there were also a lot of pretty awesome developments in web3 that have managed to keep us starry-eyed for the future of blockchain programming. Please remember that we’re silly little developers, not silly little financial advisors. Our technical praise IS NOT financial advice.
Solady: LibZip
Solady, maintained by Vectorized, is a collection of gas-optimized solidity snippets. We could write an entire manifesto about how incredible Solady is but for the sake of not coming on too strong we’ll focus on one of the newest Solady libraries- LibZip. Libzip is a library for generalized calldata compression and decompression, which could massively change the way we develop on L2 networks. L2 networks inherently have cheaper computation costs than mainnet Ethereum but the most expensive part of L2 transacting is posting calldata back to mainnet. LibZip was developed to address this cost; it allows developers to easily and quickly compress their calldata to reduce the L1 calldata cost. It’s short and simple, and we HIGHLY recommend that every developer add it to their toolbox.
(source: https://gist.github.com/Vectorized/9befa4022edd2a11afd23d2c200f52bd)
ERC1155P
One of our favorite lesser-known technical advancements this year was ERC1155P, developed by 0xjustadev. ERC1155P introduces reduced gas costs for people that are minting, swapping via burn, and buying multiple ERC1155 tokens in a single transaction. This implementation is substantially more gas efficient than OpenZeppelin and Solmate’s implementations. Oxjustadev’s unique approach adds a slight gas premium on the first transfer, but ultimately benefits collectors since every subsequent transaction saves gas. Unlike other implementations, the original minter is not the only user that benefits from the optimization. At a high level, 0xjustadev achieved this level of optimization by packing balance data for multiple tokens into a single storage slot. Other optimizations include assembly and unchecked math. TLDR if you launch an ERC1155 collection without using ERC1155P you're a bozo.
(source: https://twitter.com/0xjustadev/status/1620571581583065089?s=20)
CryptoPunks721
CryptoPunks are an OG NFT collection- so OG that they actually pre-date the ERC721 standard, which is honestly iconic… but not so great for compatibility. CryptoPunks can’t be natively traded on popular marketplaces without being wrapped first. Luckily, our good friend, 0xQuit, fixed that with CryptoPunks721. CryptoPunks721 is a gas efficient and safe way to wrap CryptoPunks. The wrapper uses CREATE2 for deterministic addresses, so users can safely stash their punk even before deploying the stash. It also supports batch wrapping and unwrapping, so users can wrap and unwrap multiple Punks in a single transaction. We were super excited to see new and efficient functionality built around one of the oldest and most iconic digital collectibles. Hats off to Quit and the CryptoPunks team.
(source: https://twitter.com/0xQuit/status/1737556089254875231)
LimitBreak’s ERC721-C
The topic of NFT Royalties always seems to spark a debate around here. (Fun fact- back in our hackathon days we once *attempted* to build some on chain hierarchical NFT royalties. Didn't go so hot for us.) In May, LimitBreak debuted ERC721-C, a new NFT standard with the goal of ending the NFT royalty debate once and for all. ERC721-C includes logic at the transfer level that does not allow royalty bypassing for exchanges that do not handle royalty payments to creators. In conjunction with Payment Processor, LimitBreak’s ERC721-C compatible marketplace protocol, royalties are strictly enforced and allow developers to easily build programmable royalty features into their collection’s smart contracts. Nice.
Frame
Another NFT royalty project, Frame, announced its seed raise in December. Frame is an L2 where royalties are built in at the network level. Coupled with its raise, Frame announced an initial airdrop of $FRAME to every address that had traded an NFT on Ethereum in the last 2 years (bear market builders rejoice). We’re excited to see our friends at Frame (especially our favorite crackedddd developer @0xcygaar) execute their roadmap to make a creator-friendly royalty system in 2024. (disclosure: Harrison is both an investor and an advisor to Frame, Erin is neither an investor nor advisor but still thinks Frame is pretty dope)
(source: https://twitter.com/frame_xyz/status/1737146524541538658)
Gaslite Drop
Last but not least, we’d like to shamelessly self-promote a little something we cooked up here at Gaslite. In September, we introduced Gaslite Drop to the world. Gaslite Drop is currently the MOST gas efficient way to bulk transfer Native Network Tokens, ERC20, ERC721, and ERC1155 (source: 0xpolarzero’s benchmark report). We developed Gaslite Drop from the ground up with a highly opinionated and highly optimized approach to airdrops. Since launch, we’ve continued to support the app with more features like airdrops to Friendtech holders and airdrops to tweet replies. Gaslite Drop is fully open source and fully free to use. It was our first step towards building a collection of highly optimized public goods for everyday use cases. The source code for Gaslite Drop, as well as all of our other public goods can be found in the Gaslite Core GitHub repository. Okay okay we’re done patting ourselves on the back.
Hopefully this post brought you on a spiritual journey filled with laughter, tears, introspection, and self-discovery. That’s what we’re here for (also we’re here for gas optimization auditing and solidity development consulting so hit us up to avoid an appearance on next year’s list). We’re praying everyone has learned from 2023’s mistakes, but something tells us 2024 will bring with it even worse programming fails. In the meantime, we’ll be doing our part to make sure the code we touch is so clean you can eat Thanksgiving dinner off of it. Follow us on this year’s journey @GasliteGG.
Ⓒ Pop Punk LLC. All rights reserved.
Gaslite
