ً

@sterlingcrispin @VannaCharmer @cobie @dannyryan sorry no i am new to CT

@lightclients @VannaCharmer @cobie @dannyryan you might not be familiar with CT but there's an endless ongoing joke that essentially anyone remotely resembling cobie is mistaken for cobie and he's changed his profile picture dozens of times over the years encouraging the bit

It's hard to believe this is a real photo

@sterlingcrispin @VannaCharmer @cobie cobie frame isn't built like that unfortunately. that's a @dannyryan build

@VannaCharmer @cobie frame mogging as usual

@kaanuzdogan it’s the era of abundance, you can do everything

@lightclients I've been hoping someone with deeper decompilation and LLM knowledge to pick this up, or someone who will really use this in a war room etc.

Interesting but can we do better? Can we just feed a model the whole Sourcify dataset with 24M verified contracts (3M unique) and get better results? Dataset is published daily in Parquet format (link below). Who has knowledge/ideas around this? 👀

@trent_vanepps @pranshurastogii @PushChain come get your boy

@pranshurastogii unfortunately this is not true - can you share where you came across this? and LLMs seem particularly stuck on hallucinating that this feature is coming you can see the current proposed Hegota features here forkcast.org/upgrade/hegota

Stateless Ethereum is coming with the Hegota hard fork late 2026. This enables everything Ethereum has been bottlenecked on: - higher gas limit - near-zero validator storage - trustless light clients on phones - rainbow staking goes live - cheaper L1↔L2 proofs

@0xlsr if we can improve some ux while we're here, that's great. many have said that a downfall of 7702 or others is the lack of a standardized / default account. it's somewhat of a side quest to PQ, but we want make frame tx the best it can be across many dimensions

@0xlsr sure it's possible to solve without AA, but it perpetrates the same 2 class account structure and the problems associated with it. i see frames as the "right" long term solution for the protocol. anything else feels like a shortcut

all the native AA arguing, from the perspective of fixing wallet UX, seems a little silly. what exactly do people think native aa will fix that can’t already be addressed? what is broken? native, purpose-built wallet flows can (and, when teams are willing to build them, do) work great. serious question: what is left? apps? eip-5792 exists and enables batching and sponsorship for wallets that support it. think we need to get more specific on what we’re trying to fix and work more directly with wallets and apps if we actually want to see potential benefits realized.

@andrewhong5297 execution is unfortunately complex. it’s turing complete after all

First time looking at the frame tx spec, feels like a code smell that there are so many different configurations/fail cases. I personally liked the dx of the tempo tx a lot. Takes inspo from solana model which does it well with instructions. Execution needs to be easier to reason about, not more complex.

@nixorokish "sign in" 🤣🤣🤣

can i expense this

@norswap @gakonst It has been examined thoroughly: eips.ethereum.org/EIPS/eip-7562

Frames is awesome but I think @gakonst is right that the mempool implications should be examined. Like the worst case: someone floods the mempool with frames txs using the same gas-intensive paymaster. Nodes have to spend lots of resources to simulate. Even if the ingress node performs this check, you can always flashbots a tx that kills to paymaster top of block after its been gossiped. Now you have a bunch of deadweight txs in the mempool that need to be revalidated either by all nodes or by all the block builders at least. Is this ok in practice? Mitigable with simple web2-style spam heuristics? (this was easier when the risk was on a centralized bundler, the mempool dynamic makes this very hard imho)

please do not greenlight eip8141, if we want pq accounts we can do it another way but eip8141 is just bad about mempool validation rules and will put us into erc7562 land which is terrible add the validation rules to the eip and examine holistically eip8141 is a mistake as-is

@evankaloudis AI is actually useful though

Everyone accepts that AI agents will run 24/7 on your devices. But suggest running a Lightning node and suddenly it's "unrealistic." It's the same thesis.

@philipliao_ @VitalikButerin This I’m not sure why rabby would be against. They can make it is as simple as they like

@philipliao_ @VitalikButerin not on hand, but i can explain it: once and EOA sets code, the EOA could call themself with a tx directly to execute a call (or batch) without additional signature verification, since that’s done via the outer tx. The contract could be very simple and just do batching

Now, account abstraction. We have been talking about account abstraction ever since early 2016, see the original EIP-86: github.com/ethereum/EIPs/… Now, we finally have EIP-8141 ( eips.ethereum.org/EIPS/eip-8141 ), an omnibus that wraps up and solves every remaining problem that AA was intended to address (plus more). Let's talk again about what it does. The concept, "Frame Transactions", is about as simple as you can get while still being highly general purpose. A transaction is N calls, which can read each other's calldata, and which have the ability to authorize a sender and authorize a gas payer. At the protocol layer, *that's it*. Now, let's see how to use it. First, a "normal transaction from a normal account" (eg. a multisig, or an account with changeable keys, or with a quantum-resistant signature scheme). This would have two frames: * Validation (check the signature, and return using the ACCEPT opcode with flags set to signal approval of sender and of gas payment) * Execution You could have multiple execution frames, atomic operations (eg. approve then spend) become trivial now. If the account does not exist yet, then you prepend another frame, "Deployment", which calls a proxy to create the contract (EIP-7997 ethereum-magicians.org/t/eip-7997-det… is good for this, as it would also let the contract address reliably be consistent across chains). Now, suppose you want to pay gas in RAI. You use a paymaster contract, which is a special-purpose onchain DEX that provides the ETH in real time. The tx frames are: * Deployment [if needed] * Validation (ACCEPT approves sender only, not gas payment) * Paymaster validation (paymaster checks that the immediate next op sends enough RAI to the paymaster and that the final op exists) * Send RAI to the paymaster * Execution [can be multiple] * Paymaster refunds unused RAI, and converts to ETH Basically the same thing that is done in existing sponsored transactions mechanisms, but with no intermediaries required (!!!!). Intermediary minimization is a core principle of non-ugly cypherpunk ethereum: maximize what you can do even if all the world's infrastructure except the ethereum chain itself goes down. Now, privacy protocols. Two strategies here. First, we can have a paymaster contract, which checks for a valid ZK-SNARK and pays for gas if it sees one. Second, we could add 2D nonces (see docs.erc4337.io/core-standards… ), which allow an individual account to function as a privacy protocol, and receive txs in parallel from many users. Basically, the mechanism is extremely flexible, and solves for all the use cases. But is it safe? At the onchain level, yes, obviously so: a tx is only valid to include if it contains a validation frame that returns ACCEPT with the flag to pay gas. The more challenging question is at the mempool level. If a tx contains a first frame which calls into 10000 accounts and rejects if any of them have different values, this cannot be broadcasted safely. But all of the examples above can. There is a similar notion here to "standard transactions" in bitcoin, where the chain itself only enforces a very limited set of rules, but there are more rules at the mempool layer. There are specific rulesets (eg. "validation frame must come before execution frames, and cannot call out to outside contracts") that are known to be safe, but are limited. For paymasters, there has been deep thought about a staking mechanism to limit DoS attacks in a very general-purpose way. Realistically, when 8141 is rolled out, the mempool rules will be very conservative, and there will be a second optional more aggressive mempool. The former will expand over time. For privacy protocol users, this means that we can completely remove "public broadcasters" that are the source of massive UX pain in railgun/PP/TC, and replace them with a general-purpose public mempool. For quantum-resistant signatures, we also have to solve one more problem: efficiency. Here's are posts about the ideas we have for that: firefly.social/post/lens/1gfe… firefly.social/post/x/2027405… AA is also highly complementary with FOCIL: FOCIL ensures rapid inclusion guarantees for transactions, and AA ensures that all of the more complex operations people want to make actually can be made directly as first-class transactions. Another interesting topic is EOA compatibility in 8141. This is being discussed, in principle it is possible, so all accounts incl existing ones can be put into the same framework and gain the ability to do batch operations, transaction sponsorship, etc, all as first-class transactions that fully benefit from FOCIL. Finally, after over a decade of research and refinement of these techniques, this all looks possible to make happen within a year (Hegota fork). firefly.social/post/bsky/qmaj…

@philipliao_ @VitalikButerin thanks for the perspective, it's useful i think 8141 is an off ramp from 4337 and will allow wallets to introduce simpler smart accounts. at the same time, this is possible with 7702 if you just self-send to your EOA smart account, so I'm not sure it will change Rabby's mind

from the application perspective, many of us aren't going to adopt something without Rabby For some apps, Rabby accounts for 80%+ of users. On Matcha Meta this is true. On OG Matcha, Metamask is much more, but Rabby is still like 25-40% I tried to make a push for 5792 support, but it's just the reality that wallet support is a big bottleneck. Aside, as a user, I personally do NOT feel comfortable with delegating my reliable EOA to a 4337 wallet. It just feels like more surface area for things to go wrong, which is not worth the UX improvement. And then, block explorers are slightly more annoying to use and gas costs more (but gas isn't the concern here, perceived risk is) I believe I'm someone who has thought a lot about 4337/7702 but am also decently familiar with EIP-2612, multicall, Permit2, 2771 metatxs - and still have a strong preference for UX improvements that allow me to use my EOAs. If I want a smart contract wallet, it'll be a Gnosis Safe It's interesting that as an application dev, I prefer 7702. But as a user, I avoid it. I sometimes use 4337/7702 for special purpose accounts that are smaller and often scoped to an application as opposed to a general wallet Not sure if this is helpful and wouldn't want to over index on a single person/dev's perspective, but sharing this as feedback

@philipliao_ @VitalikButerin ser we are almost certainly adding this event in glamsterdam (fork before 8141 would go live): forkcast.org/eips/7708

@lightclients @VitalikButerin that's great to hear - there is however, one super important thing that doesn't emit an event: Native ETH transfers. I believe the state of the art is to parse traces. Being able to do traces per frame would be important to achieve the same goal

@philipliao_ @VitalikButerin I think 7702 adoption has been pretty good on the wallet side, but it's the application layer where they haven't integrated things like 5792. Rabby seems to be anti-smart-accounts in general, so I don't really see how to bridge that gap.

@philipliao_ @VitalikButerin 8141 is also very explicitly *not* fixating on gas abstraction. yes, we want to make sure it is possible and devex is good, but it can't come at the cost of vanilla features. so I think we're in agreement there.