EIP-5792 was finalized on May 9, 2025. Wilson Cusack and I took over the EIP in April 2024. Over the course of those 13 months, we worked with various stakeholders in the industry to drive alignment and build adoption.

By most metrics, EIP-5792 has been very successful:

• The spec is supported by other major wallets, such as MetaMask and Ambire.

• viem and wagmi have first-party support for EIP-5792 RPC methods.

• Top apps such as Uniswap use EIP-5792 RPC methods to submit batch transactions.

We have learned a lot throughout this process, and while this kind of work is nuanced, I wanted to share what I consider to be guiding principles for it.

A draft EIP does not provide value to users. An EIP in review does not provide value to users. Even a finalized EIP does not provide value to users. The best way to get developers and users excited about something is to get it in their hands and let them use it. Before you get too caught up in your EIP, find a way to ship a version of what you’re proposing so users can try it and other stakeholders can get excited about it.

This is something we did well for EIP-5792. We shared demos of the new RPC methods even before we took over the EIP, and had support for it live in production the same month we started updating the spec.

At the time, batch and sponsored transactions (both enabled by EIP-5792) were big differentiators for Coinbase Smart Wallet and got developers and users excited about using it. This excitement grabbed the attention of other industry stakeholders and helped with things like getting experimental support for the new RPC methods in viem/wagmi within the same month, which got other wallet developers asking about the spec, which got more app developers asking about the spec, etc.

An EIP alone does not provide value to users. Ship what you’re proposing.

Anyone can propose an EIP. I mean this literally. All you have to do is open a PR against the public EIP repository on GitHub. A very small fraction of those people finalize their EIPs and gain adoption. You want to be one of those people. This takes persistence. You will get into disagreements. You will become frustrated. It took over a year to finalize EIP-5792, with many passionate disagreements along the way. But it has been successful largely just because we stuck with it. We fostered discussions, promoted it on socials, maintained documentation, and supported builders who used it all throughout the past 13 months. Very few are willing to stick with something that long. Being one of the people who is willing to stick with your proposal greatly increases the likelihood your proposal will be successful and gain adoption.

Stick with your proposal. Most people don’t, and others recognize those who do.

The goal of an EIP is to crowdsource a solution to some shared problem in the Ethereum ecosystem. If you don't need ecosystem-wide adoption, you don't need to write an EIP.

If you do need other people on board with your solution, you need them to be excited about solving the problem, and you need them to feel good about the solution. To do this, you’re going to need to be open to other stakeholders’ ideas. If you’re not, they will likely try to find their own solution or a different group of people who are more willing to listen to their ideas.

Late into the development of EIP-5792, I took a strong stance that the spec should not support EOAs. After this, I received messages from a few stakeholders advocating for EOA support. After hearing their arguments, I eventually walked this stance back and we found a path for supporting EOAs. This did two really important things:

1. It got those who I heard arguments from more involved and excited about the spec.

2. EOA support ended up being an important piece for important stakeholders such as MetaMask, who likely would not have been as excited about the spec (and maybe would not have ended up supporting it at all) if I did not hear the EOA advocates out.

Finalizing an EIP is one thing. Finalizing an EIP with broad industry support is a very different thing. If you want the latter, you need to hear people out.

The Ethereum ecosystem is big. There are a lot of people, apps, tools, wallets out there. You alone will not be able to get every single potential stakeholder engaged. You need to scale yourself. The best way to do this is by finding and supporting other strong advocates of what you’re proposing. Sometimes these champions present themselves. Other times you need to hear people out, get them excited, and nudge them into helping out.

EIP-5792 has had many champions over the last 13 months, and the spec absolutely would not be as successful as it is today without them. Here are some examples of champions of EIP-5792:

• jxom: jxom is a primary maintainer of viem/wagmi. He added support for EIP-5792 RPC methods into viem/wagmi very early on in the development of the spec. With wagmi being by far the most popular Ethereum library, this brought EIP-5792 into the hands of pretty much every app developer the same month the methods were live on Coinbase Smart Wallet.

• Adam Fuller: Adam took it upon himself to push updates to the EIP-5792 documentation site as the spec was being updated.

• Phil Liao: Phil is a loud and proud supporter of EIP-5792 who helped spread the word on socials, which directly fostered important discussions that led to material changes to the spec.

If you want your proposal to be successful, you’re going to need help. Find and support champions.

People (especially engineers) in the Ethereum ecosystem will talk in circles forever if you let them. If leadership appears to be lacking, step in and make some decisions. It is not paramount that they are the "right" decisions the first time around, but you do need to be making consistent progress. If you’re following the other principles here, you can trust that other people will speak up if you’ve misstepped (refer to my above example around EOA support).

Hear people out but also make sure you’re making progress. Be decisive.

The first few months we were working on EIP-5792, we questioned if going through the EIP process was really worth it (the alternative being to maintain the API as solely a Coinbase one). I can now say it was absolutely worth it. Finalizing your EIP signals to the ecosystem that it is ready to be adopted. If we didn’t go through this process, there would not be the broad support for it that exists today, which would have meant an overall worse UX on Ethereum.

While there are some tactical changes I would make if I were to do it all again, I would still abide by the principles here: ship it, stick with it, hear people out, find and support champions, and be decisive.

EIP-5792 was finalized on May 9, 2025. Wilson Cusack and I took over the EIP in April 2024. Over the course of those 13 months, we worked with various stakeholders in the industry to drive alignment and build adoption.

By most metrics, EIP-5792 has been very successful:

• The spec is supported by other major wallets, such as MetaMask and Ambire.

• viem and wagmi have first-party support for EIP-5792 RPC methods.

• Top apps such as Uniswap use EIP-5792 RPC methods to submit batch transactions.

We have learned a lot throughout this process, and while this kind of work is nuanced, I wanted to share what I consider to be guiding principles for it.

A draft EIP does not provide value to users. An EIP in review does not provide value to users. Even a finalized EIP does not provide value to users. The best way to get developers and users excited about something is to get it in their hands and let them use it. Before you get too caught up in your EIP, find a way to ship a version of what you’re proposing so users can try it and other stakeholders can get excited about it.

This is something we did well for EIP-5792. We shared demos of the new RPC methods even before we took over the EIP, and had support for it live in production the same month we started updating the spec.

At the time, batch and sponsored transactions (both enabled by EIP-5792) were big differentiators for Coinbase Smart Wallet and got developers and users excited about using it. This excitement grabbed the attention of other industry stakeholders and helped with things like getting experimental support for the new RPC methods in viem/wagmi within the same month, which got other wallet developers asking about the spec, which got more app developers asking about the spec, etc.

An EIP alone does not provide value to users. Ship what you’re proposing.

Anyone can propose an EIP. I mean this literally. All you have to do is open a PR against the public EIP repository on GitHub. A very small fraction of those people finalize their EIPs and gain adoption. You want to be one of those people. This takes persistence. You will get into disagreements. You will become frustrated. It took over a year to finalize EIP-5792, with many passionate disagreements along the way. But it has been successful largely just because we stuck with it. We fostered discussions, promoted it on socials, maintained documentation, and supported builders who used it all throughout the past 13 months. Very few are willing to stick with something that long. Being one of the people who is willing to stick with your proposal greatly increases the likelihood your proposal will be successful and gain adoption.

Stick with your proposal. Most people don’t, and others recognize those who do.

The goal of an EIP is to crowdsource a solution to some shared problem in the Ethereum ecosystem. If you don't need ecosystem-wide adoption, you don't need to write an EIP.

If you do need other people on board with your solution, you need them to be excited about solving the problem, and you need them to feel good about the solution. To do this, you’re going to need to be open to other stakeholders’ ideas. If you’re not, they will likely try to find their own solution or a different group of people who are more willing to listen to their ideas.

Late into the development of EIP-5792, I took a strong stance that the spec should not support EOAs. After this, I received messages from a few stakeholders advocating for EOA support. After hearing their arguments, I eventually walked this stance back and we found a path for supporting EOAs. This did two really important things:

1. It got those who I heard arguments from more involved and excited about the spec.

2. EOA support ended up being an important piece for important stakeholders such as MetaMask, who likely would not have been as excited about the spec (and maybe would not have ended up supporting it at all) if I did not hear the EOA advocates out.

Finalizing an EIP is one thing. Finalizing an EIP with broad industry support is a very different thing. If you want the latter, you need to hear people out.

The Ethereum ecosystem is big. There are a lot of people, apps, tools, wallets out there. You alone will not be able to get every single potential stakeholder engaged. You need to scale yourself. The best way to do this is by finding and supporting other strong advocates of what you’re proposing. Sometimes these champions present themselves. Other times you need to hear people out, get them excited, and nudge them into helping out.

EIP-5792 has had many champions over the last 13 months, and the spec absolutely would not be as successful as it is today without them. Here are some examples of champions of EIP-5792:

• jxom: jxom is a primary maintainer of viem/wagmi. He added support for EIP-5792 RPC methods into viem/wagmi very early on in the development of the spec. With wagmi being by far the most popular Ethereum library, this brought EIP-5792 into the hands of pretty much every app developer the same month the methods were live on Coinbase Smart Wallet.

• Adam Fuller: Adam took it upon himself to push updates to the EIP-5792 documentation site as the spec was being updated.

• Phil Liao: Phil is a loud and proud supporter of EIP-5792 who helped spread the word on socials, which directly fostered important discussions that led to material changes to the spec.

If you want your proposal to be successful, you’re going to need help. Find and support champions.

People (especially engineers) in the Ethereum ecosystem will talk in circles forever if you let them. If leadership appears to be lacking, step in and make some decisions. It is not paramount that they are the "right" decisions the first time around, but you do need to be making consistent progress. If you’re following the other principles here, you can trust that other people will speak up if you’ve misstepped (refer to my above example around EOA support).

Hear people out but also make sure you’re making progress. Be decisive.

The first few months we were working on EIP-5792, we questioned if going through the EIP process was really worth it (the alternative being to maintain the API as solely a Coinbase one). I can now say it was absolutely worth it. Finalizing your EIP signals to the ecosystem that it is ready to be adopted. If we didn’t go through this process, there would not be the broad support for it that exists today, which would have meant an overall worse UX on Ethereum.

While there are some tactical changes I would make if I were to do it all again, I would still abide by the principles here: ship it, stick with it, hear people out, find and support champions, and be decisive.