Suma retweeted
PLEASE STOP FUCKING WITH ETHEREUM WITHOUT ASKING THE PEOPLE WHO BUILD ON IT: FIVE REASONS I AM TIRED
[feat. Wildcat Labs, a company that is filled with Ethereum die-hards and works exclusively on code that has originated over a billion dollars of economic activity for the chain, but these are my opinions not that of Labs itself etc]
---
REASON ONE: Our entire market deployment flow breaks on day one of Glamsterdam
Wildcat's core product involves a borrower creating a market that they've specified the way that they determine is best for them. That includes the core market itself (interest rate, underlying asset, debt token name), and a separate configuration (through hooks) granting access to the market and its functions (i.e. who can deposit, can debt be transferred, are withdrawal requests subject to a fixed-term tenor and so on).
In our currently deployed, immutable V2 code, what used to be a single transaction bundling those things together goes from 8.6M gas to ~62-71M, which means we can't fit it into a 60M block (don't you dare 'but ackshually' me, I am coming back to this).
Nothing in our contracts changed: the chain reprices bytecode deposits by 7.65x underneath already-audited code. We only have a workaround because our factory happens to expose the two halves separately, so we need to boot out an SDK and frontend release, plus pray folk are using a wallet that will sign a 35M gas field.
Every borrower's first market to date used a call that will no longer fit in a block as-is (I said I'm coming back to it).
The reason I am starting to... express opinions, is that this is the second time in a year that the execution layer has changed what a deployed contract costs to use (EIP-7825's cap in Fusaka, now state gas), and each time the burden of discovering it lands on us, the teams developing applications that drive economic activity on the chain, and we have to do it by replaying our own history on a testnet.
[This is going to be a long post. I am Not Pleased.]
---
REASON TWO: We are relying on social consensus for any hope of relief
The repricing aspect is consensus: at the fork, every validator must enforce it. The gas limit - the thing that would make a ~70M transaction possible post-Glamsterdam - is a validator-set preference with no mainnet schedule.
Sepolia was handed 200M, and things look fine over there. Hoodi had its 200M yeeted out the airlock the day the fork was postponed. So, the testnet that "proves" the fork works runs with over three times the headroom of mainnet, but the fork's own design assumes a headroom that nobody has committed to.
For a protocol that needs to tell institutional borrowers what a market costs to open, Wildcat's honest answer after Glamsterdam has to be "it depends on a social campaign to change validator config files," and that isn't a dependency that a credit product should carry. We are engineers, not lobbyists.
It also means Wildcat's capacity planning is hostage to the same ACD calls that are currently stalled on a security review of the very EIP that created the problem.
You know what, Ameen, you are a core dev now. Why not.
---
REASON THREE: As-is, Safe App deployments of mainnet Wildcat markets fail after the fork
Safes are the default custody mechanism for exactly the borrowers Wildcat wants, and just over a third of V2 markets (29 of 82) were deployed via one.
Under EIP-8037, the GAS opcode no longer reports the reservoir, so a Safe's execution check (GS010) can never be satisfied for a transaction that needs more than the execution cap.
On either deploy entrypoint: the core market itself or its hooks.
Historical Wildcat Safe deployments set safeTxGas to zero and survive. The Safe App and safe-apps-provider path set it from the estimate... and die. :)
We can patch our own route (send safeTxGas 0, which our testnet branch already does), and we will. What nobody owns is the default: every Safe App on Ethereum that lets the provider fill safeTxGas from an estimate above ~16.4M dies in the same way.
This is not Wildcat's bug, nor is it Safe's in any useful sense.
It is a consensus change that silently invalidates a safety check in the most widely deployed smart-contract wallet on Ethereum, with no deprecation path, and as of today nobody owns fixing it. Building on a platform where our users' wallets can be broken by a gas-accounting EIP is something that every single protocol team should be screaming things that would get us put on trial in The Hague about.
---
REASON FOUR: Every single part of the tooling stack currently assumes tx.gas stops before the reservoir
Fusaka taught Ethereum developers that a transaction cannot exceed 16.78M, and so tooling calcified around that number because... why wouldn't it? It's not even a year old yet!
As it stands, geth's default 50M RPC cap can't estimate the combined deploy of a Wildcat V2 market, and public nodes cap eth_call the same way.
Even our own release ceremony prices contract deployments statically at 200 gas per byte against the 1,530 already live on Sepolia (our simulation gate catches it, the planner doesn't).
Glamsterdam now says the gas field can be 4.29 billion, with the part above 16.78M living in a reservoir that neither GAS nor most estimators nor any wallet UI understands yet.
When our V2.5 audit is done and it's time for us to deploy the necessary factories, the install is sixteen transactions and about six blocks' worth of gas, at most one big creation per block, and every wallet and integrator that Wildcat touches has to re-learn gas at the same time.
With no shared reference implementation.
None of this is Wildcat's code, all of it is Wildcat's outage, and the execution layer will have shipped two contradictory gas models in consecutive forks.
Masterful gambit.
[and this last one's just me being me about my most hated and well-known bugbear]
---
REASON FIVE: Code bytes are now 96 percent of what one of our markets costs to deploy, but the spec is still moving
I have spent coming up ten years - near enough since its introduction - begging for the death of EIP-170, and I genuinely don't know why I dared to believe that anything except a monkey's paw would answer me.
At 1,530 gas per byte, the cost of deploying a V2.5 market (when it launches) is almost entirely the price of copying 23 KB of bytecode into state. A lender’s first deposit to a Wildcat market costs about 3x the gas it would pre-Glamsterdam, because every fresh storage slot went from 22,100 gas to 110,020.
EIP-7954's promised 64 KB contracts are capped in practice at about 38 KB by a 60M block, so the one concession to builders in this fork - the one I have been asking for since my age first started leading with a 3 - is muted on mainnet until the aforementioned social campaign gets the gas limit bumped to 200M. Which we have to take on faith right now.
Meanwhile, the refill and reservoir semantics of EIP-8037 are under review, Hoodi is unscheduled and mainnet has no date, which means that Wildcat Labs just paid six figures to get Wildcat V2.5 into external audit against gas semantics that may change before it ships.
The cost - and the apparent lesson - of being an early, careful team on Ethereum is that you run the risk of needing to audit twice: once against the chain you deploy to, and once against the chain it becomes.
---
WHAT WE ARE DOING ABOUT THIS: Upcoming SDK and frontend releases will, defensively and until we can safely revert to type, split market creation into two transactions and send safeTxGas 0 on the Safe App route. Existing markets will keep running. Lenders will be affected in cost only: first touches (first deposit, opening a withdrawal request, first approval) about 2-3x, everything else 1.1-1.6x. What we cannot do is make a 65M transaction fit in a 60M block.
That part is on you lot, the social layer.
Further to the above, Wildcat Labs will happily send an invoice for an audit rebate to anyone willing to provide it if we end up having to re-check things for V2.5 once semantics are finalised.
Mind you, we'd provide an EOA, as we're a bit wary of anything contract-based right now.
Enjoy your Sundays.
Imagine getting smoked by a new L2 within weeks, from a near impregnable position, because you just couldn't bring yourself to say " Ethereum" ¯\_(ツ)_/¯
43
Suma retweeted
I updated my 2023 roadmap diagram to overlay where the items that were there sit in the current Strawmap ( strawmap.org/ ).
In general, a lot of overlap, but:
* Some things got reshuffled in order (eg. quantum safety up-prioritized)
* Some things deprioritized (eg. VDFs; many EVM improvements)
* Some things replaced with superior constructions (eg. Verkle -> unified BT -> PBT; state expiry -> new state types)
What's most striking, however, is that some completely new things are in the strawmap that are NOT in this diagram, because they were not in the 2023 roadmap at all. These reflect changing priorities.
Notably:
* First-class attention to strong privacy. This covers: keyed nonces and recent roots, aspects of FOCIL, lean privacy pool & wormholes
* Aggressive scaling in the context of post-quantum. This covers: leanSPHINCS signatures and aggregation, zkzk frames (see ethereum-magicians.org/t/eip… )
* Lean-ification of the spec, to assist in formal verification (full FV of everything is only possible because of modern AI)
* Blob and gas futures (this idea just didn't exist back in 2023)
* Native rollups (SNARKs were nowhere near mature enough to even consider this back in 2023)
* A more open design space for the "future of the EVM". zkzk frames already implies that the protocol will expose to users some ISA that's not the EVM - current leading candidates are leanISA and RISC-V. These ISAs are more simple, modern and efficient than the EVM. Once they're there, why not expose them to developers everywhere? (And then, why not turn the EVM into being an IR on top of that ISA, instead of an enshrined feature massively complicating the base protocol?) Though much of the deeper exploration here is too early even for the strawmap.
* New state types are not just a replacement for expiry, they're a fundamentally different paradigm to how Ethereum does scaling
A common theme in scaling, found in both state types and zkzk frames (both new ideas), is that instead of trying to maximally scale ALL ethereum activity, we try to create specialized mechanisms that have more restrictive properties that make them more scaling-friendly, while supporting the heaviest loads incurred by users and applications today (eg. token transfers, swaps) and tomorrow (eg. privacy protocols).
The other common theme is treating STARKs and AI-accelerated FV as first-class objects, that we are okay betting the technical future of Ethereum on. There are recursive STARKs in many layers of the protocol, one particular primitive (the "aggregate to union verified dependencies" primitive) is expected to be used in *three* places in the protocol: EL, CL and DL. This can only be safe with formal verification, which is itself only feasible with modern AI tools.
In general, many steps forward in maturity. And a huge amount of hard work by many dozens of Ethereum researchers and developers on all of these features.
Ethereum will be quantum-safe. Ethereum will put users' privacy first. Ethereum will be secure. Ethereum will be censorship-resistant. Ethereum will be highly performant and scalable while satisfying the above. And Ethereum will be Lean.
Suma retweeted
I can't imagine anyone choosing to build with, or use L0 after all this.
Prior to the rsETH/L0 incident, I never fully understood the difference in tech between CCIP vs L0. So I wasn't going to avoid L0 if a multichain token was only supported as an OFT.
But now, I'd do everything imaginable to avoid L0 OFTs. Security matters, and second to that, actions matter in a situation like this. Their reaction to the whole debacle tells me all I need to know.
Aave could have turned its back on users and said "sorry it's not us, it's on them" but they rallied the troops around the situation to make things right. Or maybe Aave is just too big to fail and everyone's simply acting rationally to save the crown jewel of DeFi. No matter what, Aave has shown the type of leadership we all expected in the end. It's what we needed in this moment and I'm eager to see their plan fully executed.
Despite my initial disappointment with Kelp for their role in causing so much pain, I still empathize with their painful situation as a builder. I'm not excusing them but there's a reason I invest over building. Nothing's harder than building. At least, I give them credit for taking responsibility to donate a large portion of their treasury to help fill the ETH hole.
There is no textbook procedure as to how to handle all this, but in my opinion, L0 has royally fucked it up. I rarely see things so black and white but I'd stay away from L0 after all this.
They're hugely accomplished builders in the space but for the huge role they aim to play, you want to know if something ever goes wrong, that a protocol, team, and founder will be accountable to their users.
I would assume L0 has listened carefully to lawyers about making more statements, and if that is the case, it's a huge blunder. You've been totally rerated by DeFi users as completely untrustworthy in a world that relies so heavily on investor confidence and trust.
Despite all this, the ZRO price has held up well. ZRO still has a low float (25% of FDV) with some big unlocks coming in June that will more than 2x the circulating supply. The promise of a new L1 must be partially why the token hasn't dumped more dramatically following this incident. There's also so little liquidity to be sold.
I can't help but be extremely frustrated and disappointed with L0's response. And keep in mind, I'm lucky I have no funds at stake against rsETH collateral.
Suma retweeted
France is passing a law forcing anyone who holds more than €5k euros in a crypto wallet to declare it to the tax authorities . This is the same government that had an IRS agent SELL the data of people who declared crypto to criminals, who then went on to kidnap their families and cut fingers off.
🔴 Les contribuables français qui détiennent au moins 5000 € sur des wallets en self-custody vont devoir le communiquer au fisc
L'Assemblée nationale a adopté hier un texte dans le cadre du Projet de loi relatif à la lutte contre les fraudes sociales et fiscales.
Concrètement, cela concerne tous les utilisateurs de wallets de type @Ledger, @Rabby_io, @MetaMask, @DeblockApp_FR ou équivalent, qui ne délèguent pas la custody de leurs assets à une plateforme régulée.
C'est une extension significative du périmètre déclaratif, jusqu'ici limité aux comptes détenus sur des plateformes.
Le législateur aligne progressivement le traitement fiscal des crypto-actifs sur celui des comptes bancaires à l'étranger.
Le seuil de 5 000 € et les modalités pratiques seront précisés par décret.
Suma retweeted
I can’t think of anything worse you could do for Ethereum than alienating people like lightclients, banteg and many others who have poured their heart and soul into Ethereum for years in favor of a bunch of kids who do ketamine in basements in Bed Stuy.
Suma retweeted
A pledge like this isn't an affirmation of commitment, it is a test
Loyalty tests are used by abusive managers to justify firing people who dissent
Tests do not align the org to a direction, they create fear and distrust of leadership
Suma retweeted
Replying to @banteg
EFer perspective: It doesn't seem productive to bring topics into the public space while they can still be resolved internally.
Suma retweeted
btw no one is forced to sign any mandates at the @etheriumfndn.
we're just doing it for the fun. so should you.
Replying to @_Enoch
I don’t trust a select group of people who were successfully coerced into saying the right words under threat of unemployment to be able to uphold CROPS or build anything that upholds CROPS and neither should you.
Orgs are what they do, not what they say they do.
The EF has done far more to undermine its mandate than uphold it.
No amount of circlejerking and checkbox clicking can change this.
Excluding people who do not grandstand is against CROPS.
Demanding subservience is against CROPS.
Valuing those who conform and will sacrifice their own views and opinions and nuance in order to remain part of the in-group is against CROPS.
The Ethereum Foundation, steward of almost a trillion dollars in value, published a mandatory all-hands doctrine that reads like a Brooklyn polisci trust fund kid’s first ketamine journal entry. It cites Mohist city gate defense theory, uses “armamentarium” unironically, and closes with Dante in Italian. The document is explicitly about freedom from coercion. Employees have to sign it today or they’re fired. Vitalik endorsed it. This is a thing that is actually happening. It is meant to last 1000 years. You have until the end of the day. Anyway, if you get fired, come work with us at @ethcforg.
Suma retweeted
The EF should spin out a team comprised entirely of those who refuse to sign the mandate.
Ironically it would be the most CROPS & mandate aligned team in the whole of Ethereum, more so than the remaining EF.
Suma retweeted
Imagine someone getting fired from the EF over not internally agreeing to a mandate inspired by Milady philosophy. That would be insane.
The solution is to let actions speak louder than any mandate.
Replying to @benjaminion_xyz @potuz_eth
Well, I guess nobody is really forced. Everyone has a choice. It's just presumably an employment precondition.





























