EIP-3074: AUTH and AUTHCALL opcodes

EIPs Core EIPs
, ,
223

This is absolutely not true. Wallets should not expose any RPC that allows an app to prompt a user to add an invoker, just as they should not expose any RPC that prompts a wallet to provide the dapp with the private key. If people believe the same as you, this may explain why there is so much backlash against this proposal.

To be explicitly clear, wallets MUST NOT allow dapps to prompt users to add arbitrary invokers.

Wallets MAY allow dapps to prompt the user to add an invoker that the wallet provider has explicitly whitelisted. Getting an invoker onto such a whitelist should involve massive amounts of independent auditing work, validation, testing, and possibly some amount of lindy.

Adding an invoker is a similar trust model as giving your private key to a new wallet provider. It is a bit safer, but not nearly safe enough that dapps should have any mechanism for prompting users to add arbitrary invokers.

2 Likes
224

An essential aspect that deserves attention, yet doesn’t often get its weight, is the continuing mindset among developers on what constitutes an account on Ethereum. I will repeat a sentiment frequently echoed: “Smart contract wallets are regarded as second-class citizens on Ethereum”. An EVM developer typically perceives an account solely as an EOA, and when they do think of testing their application with more than one wallet, it’s often with another EOA. It’s not their fault; the protocol is designed in a way that still, and and continue to favors this perspective.

I will mention two oversights frequently disregarded by EVM dapp developers:

  • Support for ERC-1271 or ERC-6492, which provide standard signature validation methods for contracts. Again, it’s not their fault. We should not expect developers to know every ERC to launch their dapp.

  • Multichain dapps (pretty much every EVM dapp) often assume an account’s availability across every network, a presumption that does not hold true for smart contract wallets. The result: a SCW can’t create an initial connection with the dapp. More in details:

    Frequently, this results in dapps requiring a connection to a specific network (typically L1 by default), and then asking for a switch to an L2 after the initial wallet connection. While this issue can partly be attributed to initial design releases of walletconnect modals, it underscores the oversight of accommodating smart contract wallets even by well-intentioned companies such as WalletConnect.

Being incompatible with the dapp ecosystem effectively renders a Smart Contract Wallet obsolete on Ethereum.

The EVM is witnessing the departure of some of its most skilled wallet developers due to this very issue. Numerous teams launched smart contract wallets, only to discover their incompatibility and lack of support across the EVM’s array of dapps. One prominent example is Argent, which ultimately gave up on EVM, and transitioned to Cairo’s Starknet. Their reasoning: on Sarknet, every account is a SCW, aligning with the expectations of EVERY dapp over there.

With ERC-4337 and RIP-7560, SCWs have finally captured some, if not little, attention of dapp developers, who now consider testing their dapps with a wallet that is not an EOA. Just recently, Uniswap removed an unjustified warning that prevented smart wallets from interacting with their interface. Without the highlight that ERC-4337 gave to SCWs, this issue would never have been fixed. If a prominent company like Uniswap had this issue, imagine other dapps, particularly those with limited resources. Will they ever test their dapps with more than one wallet?

If our objective is to cater to future users with full AA, then pursuing EIP-3074 distracts both wallet and dapp developers from this goal. The underlying message conveyed here is that we will continue supporting EOAs enshrinement and development, and the adoption of smart accounts will continue to be optional.

EIP-3074 has garnered favorable responses from both EOA wallets and some SCW tooling providers, despite EIP-3074 only addressing execution abstraction alone. Why? Quite simply, for wallets, it already integrates seamlessly with the present dapp ecosystem, and that’s where the profit lies. For some SCW infra providers, it expands their market to the current userbase of EOA wallets with gas sponsorship relaying.

Achieving full account abstraction on Ethereum relies on our capacity to focus efforts, rather than splitting the already limited attention span within our ecosystem.

3 Likes
225

This is really the key misunderstanding that people have with 3074. Just because it is permissible to do so doesn’t mean this is how it should be utilized.

It’s like saying we should have protocol nonces for smart accounts because “a dapp might ask you swap the implementation of your smart account for their specially extended one”. Yes, you could imagine a design where this is possible. It just doesn’t make sense though because it’s totally insecure.

1 Like
226

To be crystal clear:

  • I do not have a problem with metamask, specifically.
  • I do have a problem with white lists maintained by large, private companies.
  • I understand that the Ethereum codebase is permissionless.
  • I understand that anyone can build a wallet and market their wallet to users.

But what I don’t understand is why people think “If you don’t like it, just make your own wallet company!” is a reasonable response to my concern as an app dev about not having feature-parity with the apps made by wallet companies. That approach might be viable for unicorns like Coinbase and Uniswap, but it isn’t for me.

3074 white lists are wallet-specific. The invoker contracts are chain specific. If I want to make a smart contract that uses AUTH or AUTHCALL on ten different chains with the ten largest wallets then I will need to go through one hundred wait lists and audits. Many of those white lists will be managed by wallet companies building their own applications, some of which may be competing with mine.

The debate seems to have missed one critically important fact: a white listed invoker that is generalized enough for the use cases of all apps would be so generalized that maintaining a white list would no longer serve a purpose, as any hostile app could fully drain the user via the generalized invoker.

An example:

A lending protocol similar to AAVE, but with a ‘hook’ that executes prior to the liquidation of a borrower’s collateral. The hook would use 3074 to deposit more of the user’s collateral tokens into the lending protocol to avoid the liquidation.

An app-specific version of this invoker would:

  1. Ensure that AUTHCALL is only used during the liquidation.
  2. Ensure that the AUTHCALL is only called explicitly by the lending protocol.
  3. Only transfer the specific token that matches the user’s collateral token.
  4. Only deposit up to a pre-approved amount set by the user when they opted into the hook.
  5. Can continue ‘topping off’ multiple collateralized positions to protect the user from liquidations while keeping the user capital efficient.
  6. Can be opted-out at any time.
  7. Fully immutable, etc

Now if we set up this hook to access the 3074 op codes through a generalized invoker, this is what it would look like from the perspective of the generalized invoker:
(assume prices are crashing)

  1. The invoker would be called by a contract (the invoker is not used as an entrypoint)
  2. The contract would then transfer some of one of the user’s tokens to itself
  3. It would then transfer some of another one of the user’s tokens to itself
  4. And it would keep doing this until the user is fully drained.

The generalized invoker has no sense of the lending protocol. It doesn’t know that the user had deposited multiple different ERC20 tokens into it, it also doesn’t know that each of these transfers is a deposit that is protecting the user.

From its POV, all it sees is some contract transferring all of the users’ tokens to itself. Without apriori knowledge of the lending protocol, this would be indistinguishable from an attack.

If a white listed invoker allows the calling contract to take all of the users’ tokens then there’s no point in maintaining a white list. Importantly, the app-specific version of the invoker would be significantly safer than any invoker that is generalized enough to perform this feature.

Although this design, specifically, isn’t something I’m planning to build, this app-specific invoker design is a genuinely useful feature. It’s a feature that helps users. It’s a feature that provides value to users - both by freeing up a portion of their collateralized capital and by mitigating the losses that a user suffers upon liquidation. This type of app doesn’t even use intents; with intents, the advantages of in-app 3074 are even more pronounced.

I do not want to have to “build my own wallet company” in order to build an app like this. I do not want to have to “build my own wallet company” to have feature parity with the wallet companies building apps like this.

As an app dev, my perspective is:

  • I would strongly prefer for the permissioning of smart contract usage of 3074 to be managed by users in a similar way (but more pronounced, perhaps) to how users currently manage token approvals.
  • If that isn’t possible, I would prefer for smart contract usage of 3074 to be handled solely by an enshrined invoker contract.
  • If that isn’t possible, then I do not believe that 3074 is secure enough for production.

I do not believe that invoker interactions should be heterogenous between wallets. Handling the permissioning offchain doesn’t make a system permissionless, especially when that permissioning is explicitly assumed to be occuring and is factored into the security assumptions of the proposal. If the EIP is too unsafe to function without strict permissioning from offchain actors then, in my opinion, it is too unsafe for production in a permissionless system.

1 Like
227

I think the concern of centralizing apps into wallets because wallets have more capabilities is a legitimate concern. However, wallets already have privileges for doing what any invoker could do today, but they choose (for whatever reason) not to leverage that. Invokers make it so there is a path somewhere between “giving your keys to a new entity” to “only your wallet can do these things”.

My hope is that we see a small number of high profile individuals within the community (ideally not just big name platforms financial platforms, but people building public goods) write some useful general purpose invokers and then all wallets add them. I also hope that this doesn’t just turn into “Uniswap can write invokers and no one else can”.

2 Likes
228

EIP 3074’s all or nothing, trust-maximizing security model pulls towards permissioned innovation because it requires a tremendous amount of trust capital to play. Permissioned innovation is the consequence we should expect, because in practice, devs outside a very limited set of players won’t be able to use this. It’s great for Metamask’s ability to innovate, not so great for dapp devs. Should we pretend the protocol exists in a vacuum? You yourself are now advocating whitelisting invokers, losing some vocal supporters in the process. I agree that nothing else makes sense. If whitelisting isn’t the standard best practice straight out the gate it soon will be after an onslaught of scams. Trust minimized security models (eg 4337 paymasters) level the playing field for a much wider range of devs.

I don’t think anyone is seriously advocating implementing complex accounting features in the protocol. 4337 already works without ANY protocol changes. Having some protocol changes will help in the future with efficiency, but even without them full 4337 style account abstraction is already more powerful than EIP 3074 EOAs. What is more relevant is that enshrining EOAs will likely delay Ethereum’s full account abstraction roadmap by creating a less powerful half measure. This will reduce the sense of urgency in developing account abstraction. We’re more likely to get stuck on a local maxima.

Apologies if I am misunderstanding you, but you seriously suggesting that the environment in which the EVM operates is less adversarial than Linux’s? Every bit code on the EVM is transparent. All of its attack surface, every method is immediately exposed. No firewalls. If you exploit it, there’s money at stake. Sudo on Unix systems gave us an endless parade of security headaches even when Unix was still running inside friendly academic networks. As soon as the environment got more adversarial we had to throw it out “all or nothing” as a reasonable security design and replace it with capabilities and mandatory access control mechanisms like RBAC. If sudo isn’t good enough for a Linux server on the Internet, how can it be good enough for EVM account security?

It is much safer to rely on a good trust-minimized security design than rely on a vaporware ecosystem of formally verified contracts. If formal verification were so easy, all the major on-chains contracts would be formally verified. That doesn’t seem to be the case. Besides, formal verification is no panacea. Even if you formally verify the implementation, there’s no way to formally verify the spec for the formal verification process. In practice, EIP 3074’s trust maximized model is going to get us a very limited set of very powerful, non formally verified invokers that support features as as intents.

229

Wouldn’t you expect the implications of handing over your private key to be much more commonly understood than the implications of authorizing an EIP 3074 invoker? If you agree that’s true, how long until we reach parity? What happens in the meantime?

230

As someone deeply invested in the vision of Ethereum’s smart contract wallet, advocating 4337, I’m not entirely sure about my stance on the long-awaited 3074 change. It’s not because 3074 is a bad development, but rather because of the differences between the state of its proposal vs where we are at today.

I believe there are some fundamental questions we need to address regarding 3074 to further discuss the implementation:

  1. Is 3074 being implemented to expedite and streamline the transition to 4337? If so, do we have an updated roadmap on this matter? What roadmap exists for EOA wallets implementing AUTHCALL to evolve into fully smart contract wallets?
  2. Is 3074 being accepted to ensure that EOA wallets don’t fall behind in features and user experience compared to smart contract wallets emerging with 4337?

Within this framework, I think it’s essential for all parties to discuss 3074 more openly.

2 Likes
231

I would expect a wallet developer looking to add support for EIP-3074 will understand the implications. I would not expect an end-user to understand the implication.

1 Like
232

Hi all, scanning some of the recent discussion.

I really agreed with your post up until this point. It’s true that dapps want simple compatibility with all wallets, but if EOAs can suddenly add the same interfaces that SCAs can add, then it provides a platform for all wallets/dapps to align around interfaces that can be generalized across both account types. If we can agree on those interfaces (and I think we should be able to agree this interface is not exposing the AUTH opcode directly to dapps), then 3074 creates a path for dapp devs to more easily support all wallets.

This unseats the EOA interface as the “maximum supportable interface” for dapps to rely on, and opens the space for SCAs to participate competitively.

I completely agree that we would be better off with an object-capability security model, like Google’s Fuchsia. The question: How do we migrate there? By adding 3074, we create developer-space for iterating on what a better security model would look like. Yes, it’s a hot wire, but it’s not one intended to be exposed to every site. Instead, it enables iterating on better/safer interfaces.

I’ve been working on one proposal (sure to be replaced by a better one) for a better and more secure interface that 3074 would allow both EOAs and SCAs to expose. It’s an interface that can be agnostic to implementation but also opinionated enough that it provides more coherent guarantees during site connection.

This makes the assumption that any generalized interface is insecure. I think we can agree that exposing AUTH directly to strangers is insecure, but by allowing open-ended community development around wallet-dapp interfaces, we will be able to explore exactly how secure an interface can be made. Can it be fully general? We’ll be able to ask that, and wallets will be free to permissionlessly explore that design space in a standards-driven way.

Without 3074, the mere existence of EOAs will continue to ensure that dapps build for them first (as to not exclude anyone). 3074 is a path to building better interaction patterns.

1 Like
233

Can you elaborate on what you mean by this? I’m trying very hard not to straw man you here but I’m interpreting it to mean that not only will your company maintain a white list of which contracts can use AUTH but you’ll also maintain a white list of which dapps can access the white listed invoker contracts. I can’t think of another pattern in which you have a white listed general invoker that not all dapps have access to.

234

I am saying that invokers enable design of new interaction patterns. I’m not suggesting and have no plans of creating a list of what dapps can connect to wallets, and I don’t know how you got there. A sample elaboration can be found in the permissions standard doc I linked to.

235

Ah - apologies for the ambiguity of terminology. I believe the confusion is because when you say dapp you’re referring to the frontend, whereas when I say dapp I’m referring to the smart contract.

In my previous post, I described a useful app-contract-embedded invoker pattern:

A lending protocol similar to AAVE, but with a ‘hook’ that executes prior to the liquidation of a borrower’s collateral. The hook would use 3074 to deposit more of the user’s collateral tokens into the lending protocol to avoid the liquidation.

But, as mentioned above, if this app’s smart contract handled the AUTHCALL via a generalized invoker it would look malicious:

That lead me to conclude that a sufficiently generalized invoker is insecure, as using it would be indistinguishable from an attack.

You disagreed:

So my interpretation of your comments came from:

  • Strangers can use a generalized invoker to do anything that they could do with an app-specific invoker.
  • You do think a generalized invoker can be secure
  • You don’t want to expose AUTH directly to strangers
  • Ergo, you plan to limit which app’s smart contracts can integrate with your generalized invoker

If that interpretation is incorrect, can you help me reconcile why that’s the case? It would help me understand more clearly if you used the specific app/invoker pattern I’ve described here - examples always help add context and clear up ambiguous terminology.

236

I think the core of this discontinuity is here. I do think so, or maybe I hope so, but I haven’t seen proof that this is true for all people yet. So I build with the goal of allowing us to build out that security, even if we don’t have it yet, in a way that allows staying safe along the way.

As I said to you before, I eagerly welcome any pattern that would make any permission granted safe, but until then, starting from “no invoker”, and gradually expanding and improving the approval/integration process, I think we can make meaningful progress expanding from “cannot do any invoker things” quickly to “can do most desired invoker things”, and we can then gradually chip at “can do any invoker things”.

Like I said to you then, at MetaMask we are also building a wallet plugin system called Snaps, and we’ve been on a basically equivalent journey to make that system permissionless (should be no surprise, since 3074 is basically an onchain EOA plugin system). In fact, I personally intend to use the Snaps system to prototype invoker/sca interfaces that aren’t standards-ready because it’s the easiest way to do it, and any developer with a copy of MetaMask Flask can already do the same, and build their own invoker enabled wallet.

So today, the “developer edition” lets you do whatever, and the consumer edition doesn’t. It’s a pretty common pattern, but again, I’m eagerly searching for better/safer ways of verifying user consent, I’d love to dissolve the distinction and have one safe pattern.

237

OK I think I see the distinction. Your current plan is not for metamask to whitelist which apps can use a metamask generalized invoker, it’s for metamask to build an extremely limited invoker that all apps can use and then gradually expand that invoker’s feature set while maintaining the ‘all apps can use our invoker’ mindset. Is that correct?

238

As an “AA” practitioner, I’d like to share my perspective.

Firstly, if " full account abstraction" is the ultimate goal, then we should assess the EIP-3074 standard based on whether it contributes to achieving this goal:

:partying_face: Adoption of EIP-3074 would incentivize DApp developers to immediately start supporting features like batch transactions and gas sponsorship. (Minor benefit)

:partying_face: It would encourage EOA wallets to immediately support some features of contract wallets, allowing users to immediately benefit from partial account abstraction, thereby aiding the transition to full account abstraction. (Moderate benefit)

:disappointed: EIP-3074 may divert the community’s attention away from full account abstraction. (Moderate issue)

:disappointed: The scattered Invoker in EIP-3074 could potentially increase systemic security risks, requiring wallets to make corresponding security improvements. This may necessitate a series of ERCs to enhance security, such as standards for Invoker signatures and wallet interactions. (Severe issue)

:disappointed: Currently, there’s no smooth upgrade path from EIP-3074 to full account abstraction. (Severe issue)

Based on these points, while I do believe EIP-3074 may be exciting for current users, I hope we can discuss clearly how to progress towards the goal of full account abstraction before its implementation.

Thanks

2 Likes
239

I agree that this holds true for certain AA features, such as batch transactions, where ERC- 5792 can now be applied and used on a dapp interface with any account. I agree as well for sponsored gas, where a dapp no longer presupposes that an account must have a balance of ETH to transact.

However, this isn’t true for the two examples I mentioned above. Support for EIP-1271 will continue to lack and the assumption that an account can exists on every network will continue exist.

So EIP-3074 can partially help, but at what cost?

When EIP-3074 was first introduced, there was no unified consensus on how we will reach full Account Abstraction. ERC-4337 hadn’t yet been introduced, and this proposal was aimed to enhance the user experience for EOAs in the short term as we figure out a good way for full AA. I tackles some important promises of account abstraction, without fully supporting it.

Fast forward to today, we’ve seen monumental shift in both the development of SCAs and the mindset of developers. We actually have hope for achieving full account abstraction. Wallets that already support EOAs can now offer full SCA functionality without requiring consensus changes, and with a clear path to native account abstraction for networks that opt to implement RIP-7560. Trust Wallet, for example, is already offering users full AA functionality.

So, the question arises: Is EIP-3074 worth the risk of initiating a parallel fragmentation among both users and developers? Are we willing to prolong the use of EOAs indefinitely with only execution abstraction? And perhaps most importantly, should we risk Ethereum’s goal of full account abstraction in exchange for short-term gains in current EOA functionality?

2 Likes
240

I agree

I can see this being a pretty simple improvement that alleviates some of the risks of inadvertent AUTH revocation that could weaken the reliability/“hardness” of commitments that are made using an AUTH message, like what @haydenadams raised.

It sounds like it wouldn’t affect implementation complexity much since it reuses existing state, so I’d suspect if authors agree, that implementers would follow. For that reason, I’m supportive of this change.

I understand this will be raised on ACDs tomorrow, and welcome anyone to name me as a supporter.

1 Like
241

It won’t initiate that fragmentation. The fragmentation already clearly exists, as you’ve documented very well.

If there is ever a design for fully converting EOAs to SCAs, I think we’d all support it! I think what we’re seeing with 3074 (and the minor tweaks that can be made on it to somewhat increase the hardness of the delegation) is that we will never be able to perfectly revoke the meaning of a secret number that someone knows out there. Someone else might honor it.

What I’m saying is: While I would never prolong the usage of EOAs, I am not certain that they can be made anything less than semi-immortal, and so I suggest we augment them as well as we can, while not holding back how well we augment the journey for new users.

I’ve seen this either-or/zero-sum argument again and again in the anti-3074 debate, but I haven’t seen any substance to these claims. Obviously everything has to be weighed beside other things, but 3074 is an incredibly simple change to implement, so I really don’t think it should be treated as blocked by titanically more complicated moon-shots.

242

I agree that could work out OK if we only have trustworthy invokers. In the real world shouldn’t we expect more grey area? Doesn’t the user need some mental representation of EIP 3074 to understand what a wallet is proposing? We have that problem even with the simpler EOA model. A family member of mine let a scammer create a wallet for them, not realising they’d be able to steal the funds deposited months later.