ETHPanda Talk | From Nethermind to the Ethereum Foundation: Tomasz's Journey in Ethereum Core Development

ETHPanda Talk is a podcast focusing on how to build a better digital society based on Ethereum. We invite outstanding Ethereum builders to share their motivations for participating in Ethereum construction, their ongoing projects, their experiences and gains, and their thoughts and visions for the future. We hope that by exploring the stories and ideas behind these builders, we can bring more diverse perspectives and inspiration to everyone, and encourage everyone to participate in and promote the development of Ethereum.

This episode's guest

Tomasz Stanczak : Co-Executive Director of the Ethereum Foundation (EF), Founder of Nethermind, and Ethereum Core Developer.

Introduction and Personal Growth

Bruce: We are very honored to have Tomasz as our guest today. He will be discussing his personal journey, the Ethereum Foundation, core protocols, and the application of artificial intelligence in the Ethereum ecosystem. Welcome to Shanghai, and thank you for participating today. Could you please briefly introduce yourself?

Tomasz: Hi everyone, I'm Tomasz. This March, I joined the Ethereum Foundation as a co-executive director, working alongside Hsiao-Wei Wang. For the previous eight years, I ran a company called Nethermind—which I founded in 2017—focused on Ethereum's core development and infrastructure. Initially, I was directly involved in engineering, leading the development of the Ethereum client Nethermind, which is now running on approximately 25% to 30% of Ethereum mainnet nodes worldwide—an achievement we've been very proud of for a long time.

Before entering the blockchain field, I had extensive experience in the traditional financial industry: I worked in the foreign exchange technology department of Citibank's London branch, and then spent over a year at a London-based hedge fund called Roko's Capital. In the six months since joining the Ethereum Foundation, my core task has been to drive change without disrupting the existing, well-functioning system. Over the years, I've accumulated many stories within the Ethereum ecosystem—both entrepreneurial experiences at Nethermind and insights from my work at the Foundation. From Nethermind's perspective, we've contributed a significant amount of talent to the ecosystem over the years: nearly 600 people have joined the team through internships and other means in the past three or four years. After gaining experience here, many have chosen to start their own businesses or join important projects within the Ethereum ecosystem. Witnessing their growth journeys has been truly meaningful. Coincidentally, the Ethereum Foundation also has a Protocol Researcher program, similarly dedicated to attracting new researchers to the ecosystem. Currently, both teams are similar in size, exceeding 200 people.

Bruce: Before joining the Ethereum Foundation and founding Nethermind, what attracted you to Ethereum core development?

Tomasz: The core driving force was curiosity. Initially, I just wanted to develop software that could execute transactions on the blockchain, primarily for my own use. Later, I started studying the Ethereum Yellow Paper, purely to understand the underlying operating logic of Ethereum. Then I tried to implement the content in the Yellow Paper, such as the Ethereum Virtual Machine (EVM) related functions. Once I delved into the EVM, I couldn't stop—what started as a simple idea eventually became a complete project planned for three years, with the goal of implementing all core functions. I remember that about a year later, we had created a usable client, but this company was founded by me with my own funds. A few months later, Greg joined me, and we developed together for a year or two before this core development project gradually took shape. Actually, my initial plan wasn't to do core development, but rather application development.

The core development area has a unique appeal: if you genuinely love it, you'll gain a strong sense of satisfaction and pride in building client implementations and the protocol itself. You'll develop a sense of belonging, a feeling of "I'm contributing to building Ethereum"—it's not just about being part of the community, but about truly being integrated into the protocol itself.

It's worth mentioning that when I first started doing core development, I was completely on my own, without connecting with other core developers. Looking back, this was probably due to ignorance: I had no idea that contacting them was actually quite simple—just an email or a tweet would suffice. This also reflects a characteristic of core development: there's no clear, predetermined path, and no one tells you what to do. Often, you're simply exploring on your own on open-source, permissionless platforms, and this kind of exploration is precisely what's feasible.

Bruce: That's interesting. I also heard that you founded Nethermind with your own funds and didn't accept venture capital (VC) in the early stages. What do you see as the advantages and challenges of this model?

Tomasz: Actually, I didn't intentionally reject fundraising from the beginning. At the time, I had some vague ideas about startup fundraising and had heard that startups should strive for funding, so I did try contacting venture capitalists, but the process was very unsuccessful, mainly because I was unprepared and lacked planning. Now I often communicate with entrepreneurs and I fully understand the standard fundraising process: if you're giving fundraising advice to entrepreneurs you're consulting with, you'll tell them to first clarify the problem, find a solution, prepare a business plan (Pitch Deck), and then proactively reach out to investors, and the whole process needs to maintain a good momentum. Fundraising involves many details, but the process itself is relatively standardized—if your idea aligns with market demand and the problem and solution match, the fundraising process will be smooth; otherwise, you may face some obstacles.

My situation at the time was incredibly chaotic: on one hand, I needed to build the core development solution (i.e., the client implementation); on the other hand, I had other ideas about the commercialization path, and a long-term vision that seemed quite ambitious at the time—to provide Ethereum client services for future hedge funds, allowing them to deploy and run Ethereum clients locally. However, in 2017, this idea wasn't well-received by most people; some even found it unbelievable. When I talked to some people, they would question, "How could you possibly do it alone? It's too difficult," and "Why make a client? It's simply not commercializable." Hearing these comments only strengthened my conviction—looking back now, the vision I wrote down on paper is exactly the reality of Nethermind today: we are indeed working with large financial institutions and hedge funds, and they are indeed deploying clients locally for scenarios such as data extraction, remote procedure calls (RPC), and transaction sending. But at the time, only I could see this future; I couldn't convince others.

The reason I ultimately chose to self-fund was partly because I lacked a top-tier university degree and didn't understand the fundraising process, and I didn't want to confirm the skepticism of venture capitalists through communication; another part was that I wanted to prove them wrong through my actions. I think this mindset might not be common among many new entrepreneurs, but this journey was exceptionally difficult, and I struggled for a long time. Fortunately, my previous jobs in banking and hedge funds had provided me with a decent income and some savings to support my self-funding, so I didn't fall into a "survival without fundraising" predicament. However, the pressure of self-funding was still immense, especially after I started hiring employees, when funds were depleted very quickly.

If you're an independent founder, relying entirely on your own efforts and not hiring anyone, you can actually minimize costs—for example, by moving to a country with a very low cost of living, or even cutting back on personal expenses. But once you start hiring, it means you have to bear fixed monthly expenses, and the pressure increases instantly. Now, many founders (especially those without a technical background) need to hire developers and engineers from the beginning, which requires them to have a variety of skills to control costs.

However, self-funding also has clear advantages: at the time, I didn't really understand many of the intricacies of entrepreneurship. If I had successfully raised funds, I might have wasted a lot of money and ultimately failed—that kind of failure would be more painful than "proving my worth to myself every day." When you are only responsible for yourself, although you will be demanding of yourself and the process will be difficult, this pressure is much easier to bear than facing disappointment from investors.

Bruce: How many people were there when Nethermind was founded?

Tomasz: I don't remember the exact number now. About a year to a year and a half later, we applied for the first batch of grants from the Ethereum Foundation and received $50,000. This was also when I officially hired my first employee. Greg had previously joined the team as a founding engineer and co-founder, but he left after a year, although we still have a good relationship. Interestingly, I didn't meet him for the first time until three or four years later, so the company initially operated entirely remotely. The first formal hiring was about a year and a half after the company was founded.

Looking back, this was actually a good strategy. With tools like AI agents and programming agents available today, small teams can accelerate development, making this model feasible. If the founder has extensive engineering experience and a clear understanding of the product direction, then self-funding and starting with a small team is usually a relatively safe path—allowing you to focus on product development while gradually learning about business operations.

My background actually laid a certain foundation for entrepreneurship: I have a master's degree in computer science and 10 to 15 years of experience building large-scale systems for financial institutions; while working at Citibank, I also completed a five-year MBA program, learning about corporate governance, accounting, and other related knowledge; in addition, I passed the Chartered Financial Analyst (CFA) exam—a three-year exam covering a wide range of topics related to accounting, governance, ethics, law, and financial instruments. This experience covered almost all aspects of business operations and marketing, preventing me from being completely overwhelmed in the early stages of starting a business. However, even so, many unexpected situations still arise in practice, requiring me to constantly deal with new problems from day one.

My first "failure" after starting my business happened within 10 to 15 minutes of founding the company: I went to register it, and luckily, registering a company in the UK is very simple—it only costs £10, takes five minutes, and requires no further documentation for the next year; the process is very smooth. I actually recommend this method to some entrepreneurs, although it sounds counterintuitive, but registering a company directly in places like the UK or Hong Kong is indeed very convenient, and there's a tax-free period. After registering the company, I applied for a bank account in 2017. The bank asked me about the purpose of opening the account, and I explained the company's business in detail—the operational plan for a blockchain company—but I quickly received a rejection notice, and they only replied, "We will not open an account for you. Do not ask for reasons or contact us again." For the next three years, Nethermind actually operated without a company bank account; all income and expenses were handled through my personal bank account. Looking back now, this was actually feasible.

Bruce: Looking back on Nethermind's development over the years, what do you consider to be the key milestones? For example, receiving funding from the Ethereum Foundation should be considered an important milestone, right? Are there any other noteworthy milestones?

Tomasz: There were definitely a few key moments. The Ethereum Foundation grant was certainly one of them, but there were several equally important ones: First was establishing connections with the London blockchain community, and I must mention Antonio Sabado—now the Chief Growth Officer at Nethermind—who helped me a lot back then. He encouraged me to integrate into the London community, host EVM workshops to share my knowledge, and even suggested I start a Twitter account (I hadn't used social media for over a year at the time). He was also the one who reminded me, "You should apply for the Ethereum Foundation grant," but my initial reaction was, "I'm not qualified, they definitely won't approve."

Secondly, the moment when the Nethermind client successfully synchronized with the Ethereum mainnet for the first time was a moment to be truly proud of. It was the official delivery of a large piece of software, like watching your own child grow up; the sense of accomplishment is hard to describe, and it was definitely a significant technological milestone.

On the business front, there were two key milestones: The first was acquiring our first paying customer – the xDAI network. They proactively expressed their desire to use the Nethermind client and requested customized extensions. For a startup, the first paying customer is significant, signifying market validation of the business model. The second key milestone was the outbreak of the COVID-19 pandemic. During the pandemic, many people worldwide shifted to online activities, trying digital services such as games and cryptocurrencies, leading to a surge in online payment demand. This resulted in increased attention and funding for blockchain solutions. Nethermind, operating entirely remotely, had accumulated mature operational experience in environments where face-to-face communication was impossible. This allowed us to respond quickly to market demands during the pandemic, securing numerous cooperation contracts. In contrast, many traditional enterprises were still figuring out how to adapt to the digital work environment, experiencing temporary chaos, which gave us a competitive advantage.

Before that, there were already many successful applications in the Ethereum ecosystem, and a large amount of funds flowed in for further investment. The industry had a strong demand for experienced developers, and at that time we had accumulated three years of experience in protocol development, which perfectly matched the market demand, and our business entered a stage of accelerated development.

Bruce: If you had the chance to go back seven or eight years and say a word or two to your younger self, what would you say?

Tomasz: There are two classic answers. The first is "Don't do it"—because the first three years of starting a business are incredibly exhausting; the mental fatigue is unimaginable. You constantly doubt yourself, and those days are exceptionally difficult. Sometimes I think that if I hadn't chosen to start a business back then, I might have avoided that painful experience. Now, although I've experienced many cool things because of my involvement in building the Ethereum ecosystem, looking back at myself eight years ago, shouldering everything alone, I still feel that perhaps remaining naive and continuing to live a routine life would have been an easier choice.

Another answer is "keep silent." Giving advice to others is actually quite irrational because you can never predict what different choices will lead to. You can only reflect on your own life path, but you don't know whether things would have been better or worse if you had made different choices. So, perhaps the best advice is to say nothing.

Ethereum Foundation Responsibilities and Goals

Bruce: You've now joined the Ethereum Foundation as a co-executive director, working alongside Hsiao-Wei Wang. I'd like to know how you divide and collaborate within the Foundation?

Tomasz: We reached a consensus from the beginning: whoever takes on any task that needs to be handled first will be responsible for it. This model solves two core problems: First, it avoids the inefficiency of "everything must be decided by both people." Compared to a single executive director structure, either party can make decisions independently, resulting in higher decision-making efficiency. Second, it automatically achieves a division of labor that "makes the best use of everyone's talents"—everyone will proactively take on tasks that they are better at and more comfortable with, and over time, the division of labor will naturally become clear.

Specifically, I was primarily responsible for external communication, such as participating in podcasts and managing the Twitter account; Hsiao-Wei Wang was responsible for Farcaster platform-related matters, while also leading a large amount of internal communication, personnel coordination, and daily operations. We worked together to advance some important matters, such as the new compensation policy; she was also mainly responsible for Foundation's Treasury and DeFi-related businesses. We would exchange ideas from time to time, but in our daily work, we mostly operated independently, sometimes focusing on matters covering different regions based on our respective locations, such as inviting speakers. The possibility of adjusting our division of labor in the future cannot be ruled out—for example, if I become tired of external communication, I might shift to internal affairs; Hsiao-Wei Wang might also be more involved in external communication, or we might maintain the current division of labor. Overall, it has been a very smooth collaboration.

Bruce: It's clear you two work very well together. This year, the Ethereum Foundation announced three core goals: expanding L1, expanding blobs, and improving user experience. You've been with the Foundation for about six months now. Which goal do you find most challenging at present? Why?

Tomasz: Which goal is the most challenging? You should really ask the colleagues who are specifically responsible for the relevant areas. But in my opinion, the goal of "interoperability and user experience" has the broadest scope, and that's precisely why it seems the most challenging—the core difficulty is that it's hard to quantify the progress of this goal, and it's impossible to give a clear answer to "when all the sub-goals can be achieved".

Let's look at L1 and L2 scaling first: L1 scaling has clear quantifiable metrics, such as the goal of increasing the gas limit per block to 100 million, and then further to 300 million. With specific goals, the team can move in a clear direction, resulting in higher efficiency. Regarding L2 scaling, although some paths are not yet clear, the general direction is clear—we will promote Blob scaling to accelerate the implementation of the Dencun upgrade (supporting 128 blobs in the future), and will continue to iterate afterward. Of course, there is no clear answer yet regarding how to further advance the two-dimensional peer-to-peer data availability solution (PeerDAS), but if you talk to Alex Stokes, Foundation researchers, engineers, and core developers, you can learn about the specific plans for the next step. I recently talked with Vitalik about Blob Scaling plans, and he has a very clear vision for the entire roadmap, so from this perspective, Blob scaling may not be the most challenging. However, the concept of Data Availability itself is a big problem – how to implement it correctly, and how to ensure competitiveness while maintaining sufficient decentralization and security, still requires continuous exploration.

Returning to the goal of "interoperability and user experience": We currently have two main delivery proposals. One is OIF (Open Intents Framework), for which Josh Rudolf recently released a very detailed summary outlining all the work we've done around this framework in the ecosystem. The other is EIL (Ethereum Interoperability Layer), a proposal put forward by the AA (Account Abstraction) team, which has also received support from myself and Marissa Posner and her team. This proposal will be officially announced during the Devconnect conference.

The core challenge of this goal lies in the "lack of a unified standard": some might say "current interoperability is good enough," while others believe "interoperability is the core pain point"; everyone agrees that "user experience needs optimization," but different people have vastly different definitions of "user experience (UX)"—it can be security and privacy, or performance and latency, it can be aimed at retail users, or institutional users, and even involve specific scenarios such as wallet usage experience. Because the definition of "user experience" is so broad, it's difficult to define "success" in a way that everyone agrees on, which is why it's so challenging.

L2 interoperability challenges

Bruce: We all know that L2 is an important part of the Ethereum ecosystem, but interoperability between L2 instances still faces many challenges. What do you see as the biggest obstacle to L2 interoperability? How will the Ethereum Foundation collaborate with the L2 community to address these issues?

Tomasz: The challenges of L2 interoperability are multifaceted. For EVM-based L2 networks, protocol compatibility and interoperability are relatively easier to achieve; however, the core challenges lie in several areas: bridge security, permissionlessness, and how to preserve the core attributes of the L1 chain (such as permissionlessness and censorship resistance) during interoperability. Among these, "achieving asset bridging without relying on third parties and in a permissionless manner" is a significant challenge—many solutions under the OIF framework and existing bridging tools on the market have not yet fully met these requirements. Often, in pursuit of a better user experience, some security risks are deliberately hidden, requiring a trade-off between experience and security. In the planning of EIL (Ethereum Interoperability Layer), we will focus on exploring how to achieve interoperability in a permissionless manner without third-party intervention, which is also one of the core characteristics of EIL.

Beyond these challenges, L2 interoperability faces numerous detailed issues: such as the uniformity of address representation, compatibility with different on-chain tools and applications (e.g., multi-signature functionality), the unified representation of stablecoins in cross-chain scenarios, and the consistency of wallet experience—for example, ensuring users can clearly identify the "same asset on different chains" during cross-chain operations. In Kohaku Wallet and its SDK, we have already offered many suggestions, such as how to unify address representation and how to consistently present asset information. The core goal is to make cross-L2 operations "feel as convenient as operating on a single chain," but achieving this goal requires resolving a large number of detailed issues.

Bruce: Based on my observation, L2 interoperability is not just a technical challenge; there may also be some conflicts of interest or business considerations behind it.

Tomasz: As I've mentioned many times, the advancement of interoperability must begin with connecting "people"—interoperability can only truly be realized when people from different teams are willing to communicate with each other and integrate systems, rather than deliberately building "on-chain barriers." However, sometimes due to business considerations, some L2 operators may not be so willing to actively cooperate. This is also one of the goals that our Foundation has set for itself: to help the entire L2 and L1 ecosystems collaborate more closely.

We recently proposed a dedicated conference next year to bring together engineers and researchers from the L2 ecosystem. This idea stemmed from feedback from some L2 engineers who said that core developers in the L2 field almost never have the opportunity to meet in person. Initially, I didn't quite understand, because core L1 developers attend numerous conferences and frequently meet to exchange ideas. After further discussion, I realized this was indeed the case: all L1 client teams hold regular in-person meetings, but core L2 developers lack such communication channels. Therefore, we hope to promote communication and collaboration among L2 teams by holding a dedicated conference.

Interestingly, many people say that "L2 engineers are all willing to collaborate and eager to achieve interoperability," but this actually ignores business considerations. Those responsible for strategy and business decisions need to consider brand building, market positioning, and the competitive landscape. They may have concerns about cross-chain collaboration, or even feel that "excessive collaboration is inappropriate." However, if you communicate directly with engineers, you'll find that their core demand is very pure: they simply want to solve technical problems, so they are always willing to work together.

EF's Future Priorities and Strategies

Bruce: Looking ahead, what are EF's priorities? What enhancements will be made in strategy development, community engagement, and external partnerships?

Tomasz: Clearly, EF's work encompasses multiple dimensions, including security, protocol upgrades, testing and verification, and ecosystem coordination. A crucial component of our core objectives is gathering information and refining requirements through dialogue with all stakeholders in the ecosystem—whether it's the cypherpunk community or large institutions—and then conveying this feedback to all core developers. We assist in advancing related work through focused research and other methods, while avoiding imposing an excessively strong development direction. It's a delicate balance: we hope to play the role of coordinator, clarifying the development direction through analysis and judgment, and conveying our thinking to the community, but we cannot directly stipulate "we must go in this direction."

All core developers are a highly opinionated, experienced, and meritocratic group. They are quick to recognize if you make a mistake, so we must ensure the accuracy of our decisions. This is also the core logic behind the Ethereum Foundation's goal setting: finding a direction that everyone agrees on—ensuring consensus is reached regardless of who you communicate with, so that when announcing goals, there won't be a disconnect between "what we think the ecosystem needs" and "the actual needs of the community." For example, this year's three major goals—"expanding L1, expanding L2, and optimizing interoperability and user experience"—have garnered broad enough consensus to be recognized by all relevant parties, including core developers, researchers, users, and DeFi builders, enabling collaborative progress.

We've now begun discussing our goals for next year. My initial suggestion was to prioritize "Finality, Privacy, and Security," but some feedback suggested that security and privacy are already default priorities and related work will proceed regardless. Later, I heard Dankrad's perspective, who believes we should continue working on L1 scaling, as this task is not yet complete—our previous plan to increase the gas limit per block to 300 million over two years is still underway. During discussions, we will fully incorporate feedback from all parties in the ecosystem, ensuring that the final goals are mutually agreed upon by core developers, researchers, all users, and DeFi builders. While still in the exploratory phase, "Finality" is definitely a crucial component: many institutions, L2 projects, and users have expressed a desire to shorten block times and improve finality speed, and there are already some excellent proposals in this area. Additionally, we may continue scaling work to make the narrative more concise; or we may explicitly focus on a few security and privacy-related projects—though this may not need special emphasis, as work in these areas will continue regardless. For example, we have a "privacy cluster" of 50 people, independent of the protocol team. They have a clear plan for the development roadmap of privacy technologies, solutions, and institutional privacy needs. The feedback we receive continuously shows that privacy is a core demand of institutional users. Here, I mean the formulation of relevant standards and specifications that clearly define how to utilize existing solutions on Ethereum to meet the privacy needs of specific scenarios.

Bruce: The next question is, how can EF further enhance community engagement, contribute to ecosystem development, and build a more active, participatory community?

Tomasz: We've made significant adjustments to the foundation's organizational structure and operating model. James Smith assembled an outstanding team, and I also rebuilt the high-quality Founder Success team, focusing on developer education, accelerating the deployment of enterprise applications, and collaborating with universities and the Ethereum Everywhere team. We also partner with physical spaces (such as community centers) to host offline gatherings and events.

We've also made significant adjustments to our funding model: we've almost completely abandoned "non-return financial aid"—that is, simply providing money without requiring any output, no longer simply saying, "You can build it, and we'll provide funding." Instead, we prefer to provide assistance through "coordination and empowerment": for example, connecting projects with resources and amplifying their voice; increasing project exposure through social media accounts and public relations channels; and proactively promoting projects at various Ethereum-related events, letting the community know "what's happening in Shanghai, what's happening in Shenzhen, and what's happening in Hong Kong." We're about to launch a Community Hub in Hong Kong to facilitate regular exchanges between founders and academics, and we've already begun collaborating with the Hong Kong Polytechnic University (PolyU).

We aim to consistently deliver a core message across these regions and continuously ask the community, "What more can we offer?" Because community development must be an autonomous journey—maintaining independence during community building fosters stronger entrepreneurial spirit, a philosophy we want to convey to all parties in the ecosystem. Core developers inherently possess an entrepreneurial spirit; they are independent and focused on delivering results. Application developers are clearly more entrepreneurial, as they are starting startups and developing applications. Therefore, this "self-driven + moderately empowering" approach to community building better stimulates the ecosystem's initiative.

Going forward, we will continue to advance the construction of these physical hubs, while collaborating with relevant parties to bring in sponsors—who may come from L2 project teams, application developers, and other ecosystem stakeholders. We will tell them, "This event perfectly aligns with your goals," and "This community is solving the problems you face," helping them establish long-term partnerships. Sometimes we will also become direct clients of some projects, but this will be less frequent than in the past.

Artificial Intelligence and Ethereum

Bruce: It's great to see more and more local community centers emerging. We've already talked about your personal growth, Nethermind, EF, and protocol-related topics; now let's focus on AI applications on Ethereum—a very cutting-edge field. I've seen many people say, "AI doesn't need Web3; Web3 is just riding the AI wave." What are your thoughts on this?

Tomasz: For many AI companies, Web3 means security, censorship resistance, and the defensive mechanisms provided by decentralization. However, they currently face fierce industry competition and must deliver results quickly, generate revenue, and launch faster and better models. Therefore, they may not prioritize Web3 in the short term. But when they discover that certain mechanisms can help them attract more users—especially as more users begin to focus on privacy protection and results verification—the value of Web3 will become apparent.

I believe this is similar to the logic behind Web3's entry into other industries: roughly 5% to 10% of the demand in each industry truly requires a "trustless delivery" mechanism. In most scenarios, existing trust systems are sufficient, but as assets become increasingly digitized and more assets are put on-chain, Web3 will eventually become the default choice. In the AI field, this process may happen even faster—because AI agents are inherently digital; they use digital assets from their inception, and the integration of Web3 payments with AI agents may become a core driving force. This is precisely the key scenario where AI needs Web3: our long-standing vision is for people to naturally use its functionality without discussing blockchain or mentioning Web3.

As for scenarios like proxy verification, training verification, and decentralized training, their adoption may be slower, and they may always remain niche demands. We often discuss "verifying reality and truth," but what's popular in the market isn't necessarily the truth—for example, when we consume entertainment content or listen to stories, we're actually buying "fiction in a positive sense." What we want is an engaging narrative, not just simple facts; we simply want to be entertained. Many news media outlets are similar; while delivering information, they also provide entertainment value. Facts are merely a canvas for constructing stories, attracting attention, and evoking emotional resonance.

When people use AI to access world news and learn about external information, will they actively seek verification of its authenticity? Perhaps not. However, in institutional settings—such as when companies need to purchase data and obtain accurate information—the demand for Web3 will become increasingly strong. This is because we have already experienced the problems caused by fake news, and now the risk of "false reality" is escalating: AI can generate entire sets of non-existent news articles, social media feeds, and even fictional characters and video content. If you stay at home for extended periods, you might be misled by this misinformation, mistakenly believing that a fictional world truly exists; even when you step outside, parts of the "reality" around you may become illusory due to over-reliance on technology.

Therefore, users willing to pay for authentic data and requiring verification of all information will become the core audience of Web3, which is where Web3's irreplaceable value lies. For retail users, the situation may be more ambiguous: they typically choose lower-priced data services, and if Web3 can help data providers reduce operating costs, insurance costs, or risks, then consumers will naturally tend to choose Web3-based solutions. Although retail users don't often mention "decentralization," their need for "privacy" has always existed.

I've been discussing this topic frequently lately because some people say "nobody cares about privacy," but this year in Milan, I saw a giant Apple billboard in a taxi that read "Safari Privacy." As a large international company, Apple has conducted extensive market research, understands what values consumers are willing to pay for, and ultimately chose "privacy" as its core selling point, placing it in a prime location in Milan's financial district. This indicates that users are either actively demanding privacy protection or have an underlying need—just not explicitly expressed—that will drive them to pay for related services. Especially when AI may completely possess personal information, leading to a complete privacy breach, users' concern for privacy will further increase, and Web3 can provide AI with security, privacy protection, and user control. Therefore, I believe there is a strong basis for cooperation between the two.

Bruce: You mentioned that Ethereum can serve as a coordination layer for AI agents, and that there are already new standards for it. Could you elaborate on that?

Tomasz: Currently, we have the ERC-8004 and x402 standards. ERC-8004 is the standard for the Ethereum ecosystem, while x402 is a more general term. Both standards are built on protocols such as MCP, A2A (Agent-to-Agent), and ACP, covering core scenarios such as agent business agreements and inter-agent interactions. x402 is mainly used for payment requests—not only applicable to AI agents, but also capable of initiating payments via the HTTP protocol and completing verification on the blockchain.

ERC-8004 is specifically designed for AI agents. Its core principle is to leverage the "trustless" nature of blockchain (i.e., the trust environment provided by blockchain) to ensure trust relationships between agents on top of protocols such as A2A. It defines a series of "trustless" rules: how agents declare their identities, how they register, how they publicize the services they provide, how they verify each other's claims, how they query the reputation of other agents, and how they verify the work results of other agents—for example, by introducing external on-chain and off-chain validators to rerun parts of the execution process and confirm the results.

These functionalities, combined, support two core scenarios: first, agents acting on behalf of users, where users entrust their identity to an agent, much like a computer acts as a tool to perform operations and use the user's identity; second, autonomous agents, which are AI agents that operate independently on behalf of on-chain deployed accounts. Many leading AI agent practitioners have participated in the development and refinement of this standard. I believe ERC-8004 will continue to evolve, and new related standards may even emerge, but it has already provided a foundation for developers. People are already starting to build tools around it, such as developing dashboards, deploying the first implementation of ERC-8004, and launching standard-compliant AI agents. This is a very exciting time, full of opportunities for entrepreneurship and development. The Ethereum ecosystem has previously been booming due to tokens and NFTs; now, it seems that AI agents may well become the next core direction.

Bruce: I noticed that ChaosChain and the concept of "agency governance" were very popular at the beginning of the year. How are these projects progressing now? What hypotheses will you be testing next?

Tomasz: This goes back to my vision at Nethermind—back then, I discussed the possibility of "agent governance" with the team: would core developers gradually be replaced by AI agents? Of course, "replacement" here doesn't mean complete replacement, but rather assistance. Observing our daily work, we've noticed that people are starting to frequently consult large language models (LLMs) and AI chat tools for advice, referring to the information they extract from datasets, which to some extent influences our decision-making process. And the training data and algorithmic biases of the models may tilt our decisions in a certain direction.

When core developers consult AI in their work, asking questions like "What should we do in this situation?" or "Is this solution correct?", while they will still maintain their own judgment and treat AI merely as a tool, this means that about 5% of their thinking may be influenced by AI. Over time, this percentage could rise to 10%—the better the LLM's performance, the higher the reliance may be. Especially in areas they are unfamiliar with, core developers may be more inclined to refer to AI's suggestions, perform simple verification, and then choose to trust them, since AI can sometimes provide seemingly perfect answers. There are already some doctoral-level studies that directly adopt solutions provided by AI, and this is likely to become more common in the future.

At the governance level, when the "social consensus layer" determines the direction of the protocol's development, the final outcome may depend on "how many proposals AI can generate" and "how much attention these proposals can receive"—just as core developers currently spend months researching proposals, proposing solutions, cross-validating them, and engaging in debates. If AI begins to generate proposals in batches, it will be needed to assist in verifying the feasibility of these proposals, which essentially becomes a kind of "proof-of-work": searching for valuable ideas and verifying their rationality; once a high-quality idea is found, it can drive the protocol in that direction.

However, this also carries risks: if someone filters ideas—only publishing proposals that align with their expectations and hiding content detrimental to their goals—then "social consensus governance" would become a proof-of-work mechanism based on "idea generation and verification." Extrapolating further, as the speed and quality of idea generation increase, the protocol's iteration speed would also accelerate, potentially even achieving "block-level social consensus," where each block accompanies protocol changes and includes verification and voting processes. Imagine how complex such a system would be.

We began discussing ChaosChain at the end of last year or the beginning of this year and conducted some related demonstrations in the Bay Area. A dedicated team was also established within Nethermind to explore this area, and this team is now being spun off from Nethermind to independently advance the project. However, the concept of ChaosChain has diverged into two directions: one is that the team is exploring AI agent-related applications based on ERC-8004, which can be seen as general research focusing on "agent governance." Some feasible basic solutions have already been developed, laying the foundation for subsequent construction. The other direction is that the team, combining the research results of the Hetu team and Vitalabs, is exploring "agent work attribution"—that is, how to determine the reward mechanism for each other based on outcome attribution when AI agents collaborate, which is similar to proof-of-work.

Nethermind, on the other hand, continues to adhere to a pure DAO governance model, preferring to use AI agents to assist DAO decision-making. This is because we believe that DAO participation and core development have many similarities: the council in a DAO is responsible for making decisions, allocating resources, and validating technical solutions (such as the solutions proposed in the L2 project). This is consistent with the logic of core developers validating the quality of proposals and deciding whether to invest resources to implement them; essentially, both are about "capital allocation."

The evolution from DAO participation to deep AI agent involvement in governance follows a natural progression: First, AI agents begin writing proposals, commenting on existing EIPs (Ethereum Improvement Proposals), and pointing out issues on the ETH Research forum. Next, they become capable of independently writing EIPs and driving their implementation. Then, AI agents can join AllCoreDevs conference calls (even without video) and share their opinions on proposals in the chat. Finally, AI agents can participate in meetings with video, actively speaking, commenting on proposals, and even offering their own solutions and defending them. This process involves no magic; based on current AI technology, it can be achieved by gradually implementing the technology and integrating sufficient core development expertise—which is why we believe Nethermind is the ideal platform to launch this project.

Bruce: This is very interesting, and I think now is the perfect time to launch these kinds of experimental projects and explore more possibilities.

Bruce: The last question is for developers: How will the Ethereum Foundation support and coordinate the direction of AI integration with Ethereum globally? Can you share some upcoming plans?

**Tomasz:** About two months ago, we formed the dAI team (Decentralized AI Team), led by David Crapis. The team has already achieved considerable success: releasing the ERC-8004 standard and garnering widespread attention, and announcing collaborations with institutions like Google, Cloudflare, and Coinbase—at least the foundation has played a coordinating role in promoting the implementation of proxy payment solutions. This has brought significant attention to Ethereum and its related standards, attracting more people to participate in the development of proxies, dashboards, and registration processes. I'm sure that in the past two months, some "hidden startups" have been building products around ERC-8004, which is exactly what we've been hoping for.

Many people's core demand of the foundation is that we provide a "canvas" so that developers can create the next application-driven innovative product—and AI agents could very well be that "next cool thing." Although the hype surrounding AI agents and blockchain has cooled down somewhat in the past few months, and many venture capitalists remain skeptical, I believe the hype will return.

The dAI team will be releasing more surprises and ideas soon, and the team size will increase, but not excessively—because we want to continue playing the role of "coordinator," rather than directly developing applications based on these standards. In addition, we've launched education-related initiatives, with the dAI team providing dedicated support. If you're working in a related field, feel free to contact them; they'll respond quickly and provide the necessary support. I also recall they'll be collaborating with mainstream AI projects to host hackathons.

We hope to actively promote global cooperation, such as connecting open source AI developers and practitioners in the Greater Bay Area, China (Shanghai, Hangzhou, etc.), and Hong Kong, as well as entrepreneurs and startup founders around the world, to promote cross-regional collaborative innovation.

Bruce: I also agree that coordination and cooperation between different regions can lead to many excellent solutions. This leads to the next question: China has many open-source AI models, as well as a large number of AI developers and engineers. What contributions do you hope the Chinese Ethereum community can make?

Tomasz: We understand that there is huge potential for cooperation between Hong Kong and mainland China – jointly nurturing startups and exploring suitable areas of collaboration, in line with local policies and goals, could yield many valuable results. For example, cross-border payments are an area worth watching, and may further evolve into agent payments in the future. Furthermore, how Chinese open-source AI models can be integrated with global solutions is also an important direction. Many Western entrepreneurs are focusing on embodied AI solutions and are very willing to collaborate with Chinese engineers – this is likely to be the core path for future cooperation: combining China's strengths in robotics and open-source AI to jointly build innovative products.

Of course, we also look forward to seeing complete solutions emerge locally in China, especially innovations in the coordination layer, which aligns with Ethereum's core principle of "global neutrality." The Chinese community is fully capable of building very successful projects.

Bruce: I believe there's still a lot that can be done in the future. Everyone is welcome to join the ETHPanda community at any time to further discuss and explore more initiatives, and to drive industry development through concrete actions.

ending

This article is based on an interview recording from ETHPanda Talk.

ETHPanda is an Ethereum community comprised of Chinese-speaking builders, dedicated to connecting Chinese-speaking builders with the international Ethereum ecosystem through education, public services, events, and technological innovation, jointly promoting the continuous development and innovation of Ethereum.