ETHPanda Talk is a podcast focused on how to build a better digital society based on Ethereum. We invite outstanding Ethereum builders to share their motivations for participating in Ethereum development, the projects they are advancing, the experiences and insights they have gained, as well as their thoughts and outlook for the future. We hope to bring more diverse perspectives and inspiration by exploring the stories and philosophies behind these builders, encouraging everyone to participate in and promote the development of Ethereum.
Guest of This Episode
Tomasz Stanczak: Co-Executive Director of the Ethereum Foundation (EF), Founder of Nethermind, and Ethereum Core Developer.
Introduction and Personal Growth
Bruce: Today, we are very honored to have Tomasz as our guest to discuss his personal growth journey, the Ethereum Foundation, the core protocol, and the applications of artificial intelligence in the Ethereum ecosystem. Welcome to Shanghai, and thank you for joining us today. Could you please introduce yourself briefly?
Tomasz: Hello everyone, I am Tomasz. I joined the Ethereum Foundation in March this year as a Co-Executive Director, working alongside Hsiao-Wei Wang. Before that, I spent eight years running a company called Nethermind, which I founded in 2017, focusing on core development and infrastructure for Ethereum. Initially, I was directly involved in engineering practices, leading the development of the Ethereum client Nethermind, which today runs on about 25% to 30% of Ethereum mainnet nodes worldwide. This is an achievement we have always been proud of, and we have maintained this leading position for a long time.
Before entering the blockchain field, I was deeply involved in the traditional finance industry: I worked in the foreign exchange technology department at Citibank's London branch and then spent over a year at a hedge fund in London called Roko's Capital. In the six months since joining the Ethereum Foundation, my core work has been to drive change without disrupting the existing well-functioning system. Over the years in the Ethereum ecosystem, I have accumulated many stories—both from my entrepreneurial experience at Nethermind and my insights from working at the Foundation. From Nethermind's perspective, we have contributed a large number of talents to the ecosystem over the years: nearly 600 people have joined our team through internships and other means in the past three to four years. Many of them chose to start their own businesses or engage in important projects within the Ethereum ecosystem after gaining experience here, and witnessing their growth journey has been very meaningful. Coincidentally, the Ethereum Foundation also has a protocol researcher program aimed at attracting new researchers to join the ecosystem, and currently, both teams are of similar size, each exceeding 200 people.
Bruce: What attracted you to core Ethereum development before joining the Ethereum Foundation and founding Nethermind?
Tomasz: The core driving force was curiosity. Initially, I just wanted to develop software that could execute transactions on-chain, primarily for my own use. Later, I began studying the Ethereum yellow paper purely to understand the underlying operational logic of Ethereum, and then I tried to implement the content from the yellow paper, such as features related to the Ethereum Virtual Machine (EVM). Once I delved into the EVM, I couldn't stop—what started as a simple idea eventually turned into a complete project that took three years to realize all the core functionalities. I remember that about a year later, we produced a usable client, but this company was independently funded by me. A few months later, Greg joined me, and we developed it together for a year or two before this core development project gradually took shape. In fact, my initial plan was not to do core development but to focus on application development.
There is a unique attraction to core development: if you truly love this field, you will gain a strong sense of satisfaction and pride in the process of building the client and the protocol itself. You will feel a sense of belonging, thinking, "I am participating in building Ethereum"—this is not just about being part of a community; it feels like truly integrating into the protocol itself.
It is worth mentioning that when I first started core development, I was completely exploring on my own without establishing contact with other core developers. Looking back, it was due to ignorance: I had no idea that reaching out to them was actually very simple—just sending an email or a tweet would suffice. This also reflects a characteristic of core development: there is no clear established path, and no one will tell you what to do. Many times, you are exploring on an open-source, permissionless platform, and this exploration is indeed feasible.
Bruce: That's very interesting. I also heard that you founded Nethermind with your own funds and did not accept venture capital (VC) in the early stages. What do you think are the advantages and challenges of this model?
Tomasz: Actually, I didn't deliberately refuse funding from the start. At that time, I had a vague concept of startup financing and had heard that startups should seek funding, so I did try to reach out to VCs, but the process was very difficult, mainly due to my lack of preparation and planning. Now, I often communicate with entrepreneurs and fully understand the standard process for financing: if you were to provide financing advice to consulting entrepreneurs, you would tell them to first clarify the problem, find a solution, prepare a business plan (Pitch Deck), and then proactively connect with capital, maintaining good momentum throughout the process. Financing involves many details, but the process itself is relatively standardized—if your idea aligns with market demand and the problem matches the solution, the financing process will go smoothly; otherwise, you may face some obstacles.
My situation at that time was very chaotic: on one hand, I had to build core development solutions (i.e., the client implementation), and on the other hand, I had some other ideas about commercialization, along with a long-term vision that seemed quite grand 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 was not well received by most people; some even found it unbelievable. When I communicated with some people, they would question, "How can you do this alone? It's too difficult," or "Why do you want to make a client? It can't be commercialized at all." Hearing these voices only strengthened my conviction—looking back now, the vision I wrote down on paper at that time is exactly the current state of Nethermind: we are indeed collaborating with large financial institutions and hedge funds, and they are deploying clients locally for data extraction, remote procedure calls (RPC), transaction sending, and other scenarios. But at that time, only I could see this future, and I couldn't convince others.
The reason I ultimately chose to self-fund was partly because I didn't have a top university background and didn't understand the financing process, and I didn't want to validate their doubts through communication with VCs; another part was that I wanted to prove them wrong through action. I think this mindset may not be common among many new entrepreneurs, but this journey was indeed exceptionally difficult, and I struggled for a long time. Fortunately, my previous work in the banking and hedge fund industries provided me with a decent income and some savings to self-fund, so I didn't fall into the dire situation of "not being able to survive without financing." However, the pressure of self-funding was still significant, especially after I started hiring employees, as the funds were consumed very quickly.
If you are an independent founder relying entirely on yourself and not hiring anyone, you can actually minimize costs to the greatest extent—such as moving to a country with a very low cost of living or even living frugally. But once you start hiring, it means you have to bear fixed monthly expenses, and the pressure increases instantly. Nowadays, many founders (especially those without a technical background) need to hire developers and engineers from the start, which requires them to have multiple skills to control costs.
However, self-funding also has clear advantages: at that time, I actually didn't understand many aspects of entrepreneurship, and if I had successfully raised funds back then, I might have wasted a lot of money and ultimately failed—such a failure would be more painful than "proving my worth to myself every day." When you are only responsible to yourself, although you will be demanding of yourself and the process is tough, this pressure is much easier to bear than facing the disappointment of investors.
Bruce: How many people were there at the beginning of Nethermind?
Tomasz: I can't quite remember the exact number now. About a year to a year and a half later, we applied for the first batch of funding projects from the Ethereum Foundation and received $50,000, which was also when I officially hired my first employee. Before that, Greg had joined the team as a founding engineer and co-founder, but he left after a year; however, we still have a great relationship now. Interestingly, Greg and I didn't meet in person until three or four years later, so the company operated entirely in a remote work model in the early days, and the first formal hiring occurred about a year and a half after the establishment.
Looking back now, this was actually a good strategy. Nowadays, with tools like AI agents and programming agents, small teams can advance development work more quickly, and this model is feasible. If the founder has rich engineering experience and knows the product direction they want to develop, then self-funding and starting with a small team is usually a relatively safe path—this allows you to focus on product development while gradually learning about business operations.
My own 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 systems for financial institutions; during my time at Citibank, I also completed a five-year MBA program, where I learned about corporate governance, accounting, and other subjects; in addition, I passed the Chartered Financial Analyst (CFA) exam—this exam took three years and covered a lot of content related to accounting, governance, ethics, and financial instruments. These experiences almost covered all aspects of business operations and marketing, preventing me from being completely at a loss in the early stages of entrepreneurship. But even so, practical operations still encounter many unexpected situations, and from day one of starting my business, I had to continuously deal with new problems.
My first "failure" after starting the company occurred within 10 to 15 minutes: I went to register the company, and fortunately, registering a company in the UK is very simple—you only need to pay £10, and the registration can be completed in five minutes, with no need to submit any documents for the next year; the process is very smooth. I would actually recommend this approach to some entrepreneurs; although it sounds somewhat counterintuitive, registering a company directly in places like the UK or Hong Kong is indeed very convenient, and there is a certain tax exemption period. After registering the company, I applied for a bank account, which was in 2017. The bank asked me about the purpose of opening the account, and I detailed the company's business—a blockchain company's operational plan—but soon received a rejection notice, with the response being, "We will not open an account for you; there is no need to ask for reasons, and do not contact us again." For the next three years, Nethermind actually operated without a company bank account, handling all income and expenses through my personal bank account, which, looking back now, was also feasible.
Bruce: Regarding the development journey of Nethermind over the years, what do you think are the key milestones? For example, receiving funding from the Ethereum Foundation should be considered an important node, right? Are there any other milestones worth mentioning?
Tomasz: There are indeed several key milestones. The funding from the Ethereum Foundation is certainly one of them, but there are also a few other equally important moments: first, the establishment of connections with the London blockchain community, where I must mention Antonio Sabado—he is now the Chief Growth Officer at Nethermind and helped me a lot at that time. He encouraged me to integrate into the London community, host EVM workshops to share knowledge, and suggested that I open a Twitter account (I hadn't used social media for over a year at that point). It was also he who reminded me, "You should apply for funding from the Ethereum Foundation," but my initial reaction was, "I'm not qualified; they definitely won't agree."
Secondly, when the Nethermind client successfully synchronized with the Ethereum mainnet for the first time, it was a moment of great pride. It was the formal delivery of a large piece of software, akin to watching your child grow up; the sense of accomplishment is hard to describe in words, and it was definitely an important technical milestone.
On the business side, there are two key milestones: the first was acquiring our first paying client—the xDAI network. They proactively expressed, "We want to use the Nethermind client and hope you can provide some customized extension features." For a startup, having the first paying client is significant, marking the validation of our business model in the market. The second key milestone was the outbreak of the COVID-19 pandemic. During the pandemic, many people around the world turned to online activities, starting to explore games, cryptocurrencies, and other digital services, leading to a surge in demand for online payments, which in turn garnered more attention and funding for blockchain solutions. Nethermind was already operating in a fully remote work model, and having accumulated mature operational experience in an environment where face-to-face communication was impossible allowed us to quickly respond to market demands and secure numerous collaboration contracts. In contrast, many traditional companies were still figuring out how to adapt to a digital work environment, falling into temporary chaos, which gave us a competitive advantage.
Before that, there were already many successful applications in the Ethereum ecosystem, with substantial funds flowing in for further investment, and the industry had a strong demand for experienced developers. At that time, we had already accumulated three years of experience in protocol development, which perfectly aligned with market needs, and our business entered an accelerated growth phase.
Bruce: If you had the chance to go back seven or eight years, what would you say to your younger self?
Tomasz: There are two classic answers. The first is "Don't do it"—because the first three years of entrepreneurship are incredibly exhausting, and the mental fatigue is unimaginable; you will constantly doubt yourself, and those days are exceptionally tough. 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 have experienced many cool things by participating in building the Ethereum ecosystem, looking back at the version of myself from eight years ago who bore everything alone, I still feel that perhaps maintaining innocence and continuing to live a more conventional life would have been an easier choice.
The other answer is "Stay silent." Giving advice to others is actually quite irrational because you can never predict what different choices will lead to. You can only reflect based on your own life path, but you don't know if making a different choice at that time would have resulted in a better or worse situation. So perhaps the best advice is to say nothing at all.
Responsibilities and Goals of the Ethereum Foundation
Bruce: You have now joined the Ethereum Foundation as a Co-Executive Director, working alongside Hsiao-Wei Wang. I would like to understand how you collaborate and divide responsibilities within the Foundation.
Tomasz: From the beginning, we reached a consensus: whoever takes on a task first is responsible for it. This model addresses two core issues: first, it avoids the inefficiency of "everything must be jointly decided by both," allowing either party to make independent decisions, which enhances decision-making efficiency compared to a single executive director structure; second, it automatically achieves a division of labor that utilizes each person's strengths—everyone will proactively take on tasks they are more skilled at and comfortable with, and over time, the division of labor becomes clear.
Specifically, I am more responsible for external communication work, such as participating in podcasts and managing the Twitter account; Hsiao-Wei Wang is responsible for matters related to the Farcaster platform, while also leading a lot of internal communication, personnel coordination, and daily operations. We work together on some important matters, such as new compensation policies; she is also primarily responsible for the Foundation's Treasury and DeFi-related business. We occasionally exchange opinions, but for the most part, we operate independently in our daily work, sometimes focusing on different regional matters based on our respective locations, such as speaking invitations and related work. In the future, we may also adjust our division of labor—if I become tired of external communication, I might shift to internal affairs; Hsiao-Wei Wang might also participate more in external communication, or we might continue to maintain our current division of labor. Overall, it has been a very smooth collaboration.
Bruce: It's clear that your collaboration is very harmonious. This year, the Ethereum Foundation announced three core goals: scaling L1, scaling blobs, and improving user experience. Now that you have been with the Foundation for about six months, which goal do you think is the most challenging? Why?
Tomasz: Which goal is the most challenging is actually a question better directed at those colleagues who specialize in the relevant fields. However, in my view, the goal of "interoperability and user experience" has the broadest coverage, and because of this, it appears to be the most challenging— the core difficulty lies in the fact that it is hard to quantify the completion of this goal, and it is impossible to clearly state "when all sub-goals will be achieved."
Looking first at L1 scaling and L2 scaling: L1 scaling has clear quantitative indicators, such as the goal of increasing the Gas Limit of each block to 100 million, and then further increasing it to 300 million. With specific targets, the team can push forward in a clear direction, enhancing efficiency; regarding L2 scaling, while some paths are still not entirely clear, the general direction is defined—we will promote blob scaling and accelerate the implementation of the Dencun upgrade (which will support 128 blobs in the future), and we will continue to iterate thereafter. Of course, there is currently no clear answer on how to advance the two-dimensional peer data availability solution (PeerDAS), but if you communicate with Alex Stokes, researchers, engineers, and core developers from the Foundation, you will learn about the specific plans for the next steps. I recently discussed the blob scaling plans with Vitalik, 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 issue—how to implement it correctly while ensuring competitiveness, sufficient decentralization, and security still requires ongoing exploration.
Returning to the goal of "interoperability and user experience": currently, we have two main delivery proposals, one is the OIF (Open Intents Framework), and Josh Rudolf recently published a very detailed summary outlining all the work we have done around this framework in the ecosystem; the other is the EIL (Ethereum Interoperability Layer), which is a proposal put forward by the AA (Account Abstraction) team and has received support from me, Marissa Posner, and her team, and this proposal will be officially announced during the Devconnect conference.
The core challenge of this goal lies in the "lack of unified standards": some may say "current interoperability is good enough," while others believe "interoperability is a core pain point"; everyone agrees that "user experience needs to be optimized," but different people have vastly different definitions of "user experience (UX)"—it can relate to security and privacy, or performance and latency, and it can target retail users or institutional users, even involving specific scenarios like wallet usage experience. Because the definition of "user experience" is too broad, it is difficult for us to define "success" in a way that everyone agrees upon, which is also why it is the most challenging.
Challenges of L2 Interoperability
Bruce: We all know that L2 is an important part of the Ethereum ecosystem, but currently, interoperability between L2s still faces many difficulties. What do you think is the biggest obstacle to current L2 interoperability? How will the Ethereum Foundation collaborate with the L2 community to address these issues?
Tomasz: The issues facing L2 interoperability are multifaceted. For EVM-based L2 networks, achieving protocol compatibility and interoperability between them is relatively easier; however, the core challenges focus on several aspects: the security of bridges, permissionlessness, and how to retain the core attributes of the L1 chain (such as permissionlessness and resistance to censorship) during the interoperability process. Among these, "completing asset bridging in a permissionless manner without relying on third parties" is a huge 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 intentionally hidden, which requires a trade-off between experience and security. In the planning of the 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 features of the EIL.
In addition, L2 interoperability also faces many detailed challenges: for example, the uniformity of address representation, compatibility of different tools and applications on different chains (such as multi-signature functionality), unified representation of stablecoins in cross-chain scenarios, and consistency of wallet experiences—such as allowing users to clearly identify "the same asset on different chains" during cross-chain operations. In the Kohaku Wallet and its SDK, we have proposed many suggestions, such as how to unify address representation and how to consistently present asset information, with the core goal being to make cross-L2 operations "feel as convenient as operating on a single chain," but achieving this goal still requires resolving a lot of detailed issues.
Bruce: From my observation, L2 interoperability is not just a technical challenge; there may also be some conflicts of interest or commercial considerations behind it.
Tomasz: I have also mentioned multiple times that the advancement of interoperability must start with the connection of "people"—only when individuals from different teams are willing to communicate with each other and integrate systems, rather than deliberately building "on-chain barriers," can interoperability truly take root. However, sometimes due to commercial considerations, some L2 operators may be reluctant to cooperate proactively, which is also one of the goals we have set for the Foundation: to help the entire L2 and L1 ecosystem collaborate more closely.
We recently proposed to gather engineers and researchers from the L2 ecosystem next year to hold dedicated exchange meetings. This idea stemmed from feedback from some L2 engineers—they said that core developers in the L2 space have almost never had the opportunity to meet in person. Initially, I didn't quite understand this, as core developers in L1 attend many conferences every year and often meet to communicate. After deeper discussions, I realized that this is indeed the case: all L1 client teams regularly hold offline meetings, but there is a lack of such communication channels among core developers in the L2 space. Therefore, we hope to promote communication and collaboration between L2 teams by organizing dedicated meetings.
Interestingly, many people say, "L2 engineers are willing to cooperate with each other and are eager to achieve interoperability," but this actually overlooks the commercial considerations—those responsible for strategic and business decisions need to think about brand building, market positioning, and competitive landscape, and they may have concerns about cross-chain cooperation, even feeling that "there shouldn't be too much collaboration." However, if you communicate directly with the engineers, you will find that their core demand is very pure: they just want to solve technical problems, so they are always willing to collaborate.
Future Priorities and Strategies of the EF
Bruce: Looking ahead, what are the priorities for the EF? What strengthening measures will be taken in terms of strategic planning, community engagement, and external collaboration?
Tomasz: Clearly, the work of the EF covers multiple dimensions, including security assurance, protocol upgrades, testing and validation, and ecosystem coordination. A crucial component of our core goals is to gather information and refine needs through dialogue with various stakeholders in the ecosystem—whether from the cypherpunk community or large institutions—and then convey this feedback to all core developers, assisting in advancing related work through focused research while avoiding overly imposing development directions. This is a delicate balance: we want to play the role of a coordinator, clarifying development directions through analysis and judgment, and conveying our thoughts to the community, but we cannot directly dictate "this is the direction we must go."
All core developers are a group of strong-willed, experienced, and capable individuals. If you make a misjudgment, they will quickly notice, so we must ensure the accuracy of our decisions. This is also the core logic behind the Ethereum Foundation's goal-setting: to find a direction that "everyone agrees on"—so that no matter who we communicate with, consensus can be reached, and when announcing goals, there will be no disconnect between "what we think the ecosystem needs" and "the actual needs of the community." For example, the three major goals we set this year—"scaling L1, scaling L2, and optimizing interoperability and user experience"—have garnered sufficient consensus, allowing all relevant parties, including core developers, researchers, users, and DeFi builders, to recognize them, thus enabling collaborative advancement.
We have already begun discussing the goal direction for next year. I initially proposed listing "Finality, Privacy, and Security" as priorities, but some feedback indicated 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 to advance L1 scaling work because this task is not yet complete—previously, we planned to raise the Gas limit of each block to 300 million over two years, and we are still working on that. During the discussion, we will fully incorporate feedback from various ecosystem parties, and the final goals must be a direction recognized by core developers, researchers, all users, and DeFi builders. We are still in the exploratory phase, but "finality" is certainly an important component: many institutions, L2 project parties, and users have expressed a desire to shorten block times and improve finality speed, and there are already some very high-quality related proposals. Additionally, we may continue to advance scaling-related work to make the narrative more concise; or clearly define a small number of security and privacy-related projects—though it may not need to be emphasized specifically, as work in these areas will continue regardless. For instance, we have an independent "Privacy Cluster" outside of the protocol team, consisting of 50 people, who have a clear roadmap for the development of privacy technologies, solutions, and institutional-level privacy needs. The feedback we continuously receive indicates that privacy is a core demand for institutional users, referring to the establishment of relevant standards and norms, clarifying how to utilize existing solutions on Ethereum to meet specific privacy needs.
Bruce: The next question is, how will the EF further enhance community engagement, support ecosystem development, and build a more active participatory community?
Tomasz: We have made significant adjustments to the Foundation's organizational structure and operational model. James Smith has assembled an excellent team, and I have also restructured the Founder Success team to focus on developer education and accelerating the implementation of enterprise-level applications, while collaborating with universities and the Ethereum Everywhere team. We are also partnering with physical spaces (such as community centers) to host offline gatherings and events.
In terms of funding models, we have also made major adjustments: we have almost completely abandoned the "no-return financial funding" model—i.e., simply giving money without requiring any output, no longer saying simply, "You can build, and we will support you with funds." Instead, we prefer to provide assistance through "coordinated empowerment": for example, connecting project parties, facilitating resource matching, amplifying project visibility; enhancing project exposure through social media accounts and public relations channels; actively promoting in various Ethereum-related events to let the community know "what is happening in Shanghai, what is happening in Shenzhen, what is happening in Hong Kong." We are about to launch a Community Hub in Hong Kong to facilitate regular exchanges between founders and academics, and we have already begun collaborating with the Hong Kong Polytechnic University (PolyU).
We hope to consistently convey core messages in these regions and continuously ask the community, "What more can we provide?" Because the development of the community must be a self-driven journey—maintaining independence during the community-building process can inspire a stronger entrepreneurial spirit, which is also the philosophy we want to convey to all ecosystem parties. Core developers inherently possess a certain entrepreneurial spirit; they are independent and focused on delivering results; application developers are clearly more entrepreneurial, as they need to start companies and develop applications. Therefore, this "self-driven + moderate empowerment" approach to community building can better stimulate the initiative of the ecosystem.
In the future, we will continue to advance the construction of these physical hubs while collaborating with relevant parties to attract sponsors—these sponsors may come from L2 project parties, application developers, and other entities within the ecosystem. We will tell them, "This event aligns perfectly with your goals," "This community is addressing the problems you are facing," helping them establish long-term collaborations. Sometimes we may also directly become clients of certain projects, but this will happen less frequently than in the past.
AI and Ethereum
Bruce: It's great to see that more and more local community centers are emerging. We have talked about your personal growth, Nethermind, EF, and protocol-related topics; now let's focus on AI applications on Ethereum—this is a very cutting-edge field. I see many people saying, "AI doesn't need Web3; Web3 is just riding the AI wave." What are your thoughts on this?
Tomasz: For many AI companies, Web3 represents security assurance, censorship resistance, and the defensive mechanisms brought by decentralization, but currently, they are facing fierce industry competition and must deliver results quickly, generate revenue, and launch faster and better models, so they may not prioritize Web3 in the short term. However, when they realize that certain mechanisms can help them attract more users—especially as more users begin to focus on privacy protection and outcome verification—the value of Web3 will become apparent.
I believe this is similar to the logic of Web3 entering other industries: in each industry, there is probably about 5% to 10% of demand that truly requires a "trustless delivery" mechanism. In most scenarios, relying on existing trust systems is sufficient, but as assets become increasingly digital and more assets are 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 will use digital assets from the moment they are created, and the integration of Web3 payments with AI agents may become a core driving force. This is the key scenario where AI needs Web3: our long-term vision is to enable people to use its functions naturally without discussing blockchain or mentioning Web3.
As for scenarios like agent verification, training verification, and decentralized training, the adoption speed may be slower and may always remain a niche demand. We often discuss "verifying reality and truth," but what is popular in the market may not necessarily be the truth—for example, when we consume entertainment content or listen to stories, what we are purchasing is actually "positively fictional," and what we want is an exciting narrative rather than mere facts; we just want to be entertained. Many news media operate similarly; while conveying information, they also provide entertainment value, with facts merely serving as a canvas to construct stories, attract attention, and evoke emotional resonance.
When people use AI to obtain world news and understand external information, will they actively demand verification of authenticity? Perhaps not. But in institutional scenarios—such as when companies procure data and need to obtain real information—the demand for Web3 will become increasingly strong. We have already experienced the troubles of fake news, and now the risk of "false reality" is intensifying: AI can generate entire sets of non-existent news, social media information flows, and even fictional characters and video content. If you stay indoors for a long time, you may be misled by this false information, mistakenly believing that a fictional world actually exists; even if you step outside, some of the "reality" around you may become false due to over-reliance on technology.
Therefore, those willing to pay for real data and needing to verify all information will become the core audience for Web3, which is also the irreplaceable value of Web3. For retail users, the situation may be more ambiguous: they typically choose lower-priced data services, and if Web3 can help data providers reduce operational costs, insurance costs, or risks, then consumers will naturally tend to choose Web3-based solutions. Although retail users may not often mention "decentralization," the demand for "privacy" has always existed.
I have been discussing this topic frequently lately because some people say, "No one cares about privacy," but this year when I was in Milan, I saw a giant billboard from Apple that read "Safari Privacy." As a large international company, Apple has conducted extensive market research and understands what values consumers are willing to pay for, ultimately choosing to make "privacy" a core promotional point, placing it in a prime location in Milan's financial district. This indicates that users are either actively demanding privacy protection or have a latent need for it—one that is not explicitly expressed, but this need will drive them to pay for related services. Especially when AI may completely control personal information, leading to a total breach of privacy, users' attention to privacy will further increase, and Web3 can provide security, privacy protection, and user control for AI, so I believe there is a strong foundation 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 related to this. Can you elaborate on that?
Tomasz: Currently, we have the ERC-8004 and x402 standards, where ERC-8004 is a standard for the Ethereum ecosystem, and x402 is a more general term. Both standards are built on protocols like MCP, A2A (Agent-to-Agent), and ACP, covering core scenarios such as agent business agreements and interactions between agents, with x402 primarily used for payment requests—not only applicable to AI agents but also capable of initiating payments via HTTP protocol and completing verification on the blockchain.
ERC-8004 is specifically designed for AI agents, focusing on leveraging the "trustless" characteristics of blockchain (i.e., the trust environment provided by blockchain) to ensure trust relationships between agents on top of protocols like A2A. It defines a series of "trustless" rules: how agents declare their identity, 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 validate the work results of other agents—such as by introducing external on-chain and off-chain validators to rerun parts of the execution process and confirm results.
These functionalities combined can support two core scenarios: first, agents act on behalf of users, where users delegate their identity to agents, similar to how a computer acts as a tool to perform operations on behalf of the user; second, autonomous agents, which are AI agents operating independently on behalf of on-chain deployed accounts. Many top practitioners in the field of AI agents have participated in the formulation and refinement of this standard. I believe ERC-8004 will continue to evolve, and new related standards may emerge, but it has already provided a foundation for developers, and some have begun to build tools around it, such as developing dashboards, deploying the first implementation of ERC-8004, and launching AI agents that comply with the standard. This is an exciting time filled with entrepreneurial and building opportunities. The Ethereum ecosystem has previously surged due to tokens and NFTs, and it seems that AI agents may very well become the next core direction.
Bruce: I noticed that the concept of ChaosChain and "agentic governance" was very popular at the beginning of the year. What is the current progress of these projects? What hypotheses will you be testing next?
Tomasz: This can be traced back to my vision when I was at Nethermind—at that time, I discussed the possibility of "agentic governance" with the team: could core developers gradually be partially replaced by AI agents? Of course, this "replacement" does not mean complete substitution but rather assistance. Observing our daily work, we find that people have already started frequently consulting large language models (LLMs) and AI chat tools for advice, referencing the information extracted from datasets, which to some extent influences our decision-making processes. The training data and algorithmic biases of the models may lead our decisions to lean in specific directions.
When core developers ask AI in their work, "What should be done in this situation?" or "Is this solution correct?" they still maintain their judgment and only use AI as a tool, but this means that perhaps 5% of their thinking may be influenced by AI; over time, this proportion may rise to 10%—the better the performance of the LLM, the higher the dependency may become. Especially in areas where they are not familiar, core developers may be more inclined to reference AI's suggestions, simply verifying them before choosing to trust, as AI can sometimes provide seemingly perfect answers. There are already some PhD-level studies that directly adopt solutions provided by AI, and this situation may become more common in the future.
At the governance level, when the "social consensus layer" determines the direction of protocol development, the final outcome may depend on "how many proposals AI can generate" and "how much attention these proposals can garner"—just as core developers currently spend months researching proposals, putting forward solutions, validating each other, and engaging in debates. If AI begins to generate proposals in bulk, it will need to assist in verifying the feasibility of these proposals, which essentially becomes a form of "proof of work": searching for valuable ideas and validating their rationality, and once quality ideas are found, they can drive the protocol in that direction.
However, there are also risks: if someone filters ideas—only making public those proposals that align with their expectations while hiding content that is detrimental to their goals—then "social consensus governance" will turn into a proof-of-work mechanism based on "idea generation and validation." If we extrapolate further, as the speed and quality of idea generation continue to improve, the iteration speed of the protocol will also accelerate, potentially achieving "block-level social consensus," where each block is accompanied by protocol changes, including 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. Nethermind has also established a dedicated team for exploration, and this team is now spinning off from Nethermind to independently advance the project. However, the concept of ChaosChain has already diverged into two directions: one direction is that the team is exploring AI agent-related applications based on ERC-8004, which can be seen as focusing on "agentic governance" as a general research area, and they have already formed some feasible foundational solutions that lay the groundwork for future construction; the other direction is that the team, in conjunction with the Hetu team and Vitalabs' research results, is exploring "agent work attribution"—that is, how to determine mutual reward mechanisms based on outcomes when AI agents collaborate, which has similarities to proof of work.
Nethermind itself continues to adhere to a pure DAO governance model, leaning towards using AI agents to assist DAO decision-making. We believe that DAO participation and core development share many similarities: the council in a DAO is responsible for making decisions, allocating resources, and validating technical proposals (such as those proposed by L2 projects), which aligns with the logic of core developers validating proposal quality and deciding whether to allocate resources for implementation, essentially engaging in "capital allocation."
The transition from DAO participation to deep involvement of AI agents in governance will undergo a natural evolutionary process: first, AI agents will start writing proposals on the ETH Research forum, commenting on existing EIPs (Ethereum Improvement Proposals) and pointing out issues; next, they will be able to independently write EIPs and promote their implementation; then, AI agents can join AllCoreDevs conference calls (even without video), expressing their views on proposals in the chat; ultimately, AI agents will be able to participate in meetings via video, actively speaking, commenting on proposals, and even proposing their own solutions and defending them. This process involves no magic; based on the current level of AI technology, as long as we gradually advance the technical implementation and integrate sufficient core development expertise, it can be achieved—this is also why we believe Nethermind is the ideal platform to launch this project.
Bruce: This is very interesting. I think now is the best time to conduct such 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 and Ethereum integration globally? Can you share some upcoming plans?
Tomasz: About two months ago, we established the dAI team (Decentralized AI team), led by David Crapis. The team has already achieved good results: they released the ERC-8004 standard, which has garnered widespread attention, and announced collaborations with institutions like Google, Cloudflare, and Coinbase—at least the Foundation has played a coordinating role in promoting the implementation of agent payment solutions, which has brought significant attention to Ethereum and its related standards, attracting more people to participate in the development of agents, dashboards, and registration processes. I am confident that in the past two months, some "invisible startups" have been building related products around ERC-8004, which is exactly what we hope to see.
Many people have a core demand from the Foundation, which is to provide a "canvas" for developers to create the next application-driven innovative product—and AI agents are likely to be that "next cool thing." Although the heat around AI agents and blockchain has cooled somewhat in recent months, and many venture capitalists remain skeptical, I believe the excitement will return.
The dAI team will have more surprises and ideas to announce, and the team size will expand, but it will not grow excessively—because we want to continue playing the role of "coordinator" rather than directly developing applications based on these standards. Additionally, we have launched educational initiatives, and the dAI team will provide specialized support. If you are working in related areas, feel free to contact them; they will respond quickly and provide the necessary support. I remember they will also collaborate with mainstream AI projects to host hackathon events.
We hope to actively promote global cooperation, such as connecting open-source AI developers and practitioners in the Bay Area, China (Shanghai, Hangzhou, etc.), and Hong Kong, as well as entrepreneurs and startup founders from around the world, to foster cross-regional collaborative innovation.
Bruce: I also agree that coordination and cooperation between different regions may give rise to many excellent solutions. This leads to the next question: China has many open-source AI models and 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 tremendous potential for cooperation between Hong Kong and mainland China—jointly nurturing startups in both regions, combining local policies and goals, and exploring suitable collaboration directions will yield many valuable results. For example, cross-border payments are a field worth paying attention to, which may further evolve into agent payments; additionally, how China's open-source AI models can interface 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 a core path for future cooperation: leveraging China's advantages 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 is still much to be done in the future. Everyone is welcome to join the ETHPanda community at any time to further discuss, explore more initiatives, and take concrete actions to promote industry development.
Conclusion
This article is based on the recording of the ETHPanda Talk interview.
ETHPanda is an Ethereum community composed of Chinese-speaking builders, dedicated to connecting Chinese builders with the international Ethereum ecosystem through education, public services, events, and technological innovation, and jointly promoting the continuous development and innovation of Ethereum.
免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。
