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

Original Title: "ETHPanda Talk | From Nethermind to Ethereum Foundation: Tomasz's Ethereum Core Development Journey"

Original Source: ETHPanda

Guest of this Episode

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

Introduction and Personal Growth

Bruce: Today we are very honored to invite Tomasz to talk with us about his personal growth journey, the Ethereum Foundation, core protocol, and artificial intelligence applications in the Ethereum ecosystem. Welcome to Shanghai and thank you for joining us today. Could you please start by introducing yourself briefly?

Tomasz: Hello everyone, I'm Tomasz. In March this year, I joined the Ethereum Foundation as a Co-Executive Director, sharing responsibilities with Hsiao-Wei Wang. For the past eight years, I have been running a company called Nethermind – a company I founded in 2017, focusing on Ethereum core development and infrastructure. Initially, I was directly involved in engineering, leading the development of the Nethermind Ethereum client. Today, around 25% to 30% of Ethereum mainnet nodes globally run this client software, which has been a source of pride for us, and this leading position has been maintained for a long time.

Before entering the blockchain field, I had a deep background in the traditional financial industry: I worked in the Foreign Exchange Technology department of Citibank's London branch and later spent over a year working at a hedge fund called Roko's Capital in London. 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 – from the entrepreneurial experience at Nethermind to insights from the Foundation. Looking at Nethermind, we have delivered a large number of talents to the ecosystem: in the past three to four years, nearly 600 people have joined the team through internships and other means. After gaining experience here, many choose to start their own businesses or contribute to important projects within the Ethereum ecosystem. Witnessing the growth journey of these individuals is truly meaningful. Coincidentally, the Ethereum Foundation also has a protocol researcher program, also dedicated to attracting new researchers to join the ecosystem. Currently, the two teams are similar in size, both exceeding 200 people.

Bruce: What attracted you to immerse yourself in Ethereum core development before joining the Ethereum Foundation and founding Nethermind?

Tomasz: The main driving force was curiosity. Initially, I just wanted to develop software that could execute transactions on-chain, mainly for my personal use. Later on, I started studying the Ethereum Yellow Paper out of pure curiosity about the underlying logic of Ethereum. I then attempted to implement the concepts from the Yellow Paper, such as features related to the Ethereum Virtual Machine (EVM). Once I delved into EVM research, I couldn't stop — what started as a simple idea turned into a full-fledged project spanning three years, aiming to implement all core functionalities. I remember that around a year later, we had a usable client, but the company was self-funded by me. Greg joined me a few months later, and together we developed for another year or two until the core development project took shape. Originally, my plan was not to do core development but rather application development.

There is a certain unique allure in core development: if you genuinely love the field, you will find immense satisfaction and pride in building client implementations and the protocol itself. You develop a sense of belonging to "I am contributing to building Ethereum" — it's not just about being part of the community; it's more like truly being integrated into the protocol itself.

Notably, when I first started core development, I was completely on my own without reaching out to other core developers. Looking back, it was due to ignorance: I had no idea that contacting them was actually simple, just sending an email or a tweet. This also reflects a characteristic of core development: there is no clear established path, and no one will tell you what to do. Most of the time, you are simply exploring on an open-source, permissionless platform, and this kind of exploration is actually feasible.

Bruce: That's interesting. I also heard that you founded Nethermind through self-funding initially without accepting Venture Capital (VC) investment. What advantages and challenges do you think this model has?

Tomasz: Actually, I didn't intentionally reject funding from the start. At that time, my understanding of startup funding was a bit vague, and I had heard that startups should pursue funding, so I did try to reach out to VCs, but the process was not smooth, mainly due to my lack of preparation and planning. Now, I often interact with entrepreneurs and fully understand the standard process of fundraising: if you were to provide fundraising advice to a consulting entrepreneur, you would tell them to first clarify the problem, find a solution, prepare a business plan (Pitch Deck), then proactively engage with capital, and maintain a good momentum throughout the process. Funding involves many details, but the process itself is relatively standardized — if your idea aligns with market needs, and the problem matches the solution, the fundraising process will be smooth; otherwise, you may face some obstacles.

At the time, my situation was very chaotic: on one hand, I had to build the core development solution (which is the client implementation), on the other hand, I had some other ideas about the commercialization path, and there was a rather grand long-term vision at that time—to provide Ethereum client services for future hedge funds, allowing them to deploy and run an Ethereum client locally. However, in 2017, this idea was not well-received by most people, and some even found it unbelievable. When I discussed this with some people, they would question: "How could you do it alone? It's too difficult," "Why build a client? It's fundamentally impossible to commercialize." Hearing these voices, I became even more convinced of my judgment. Looking back now, the vision I wrote down on paper at that time is exactly the current reality of Nethermind: we are indeed collaborating with large financial institutions, hedge funds, and they are indeed deploying the client locally for scenarios such as data extraction, remote procedure calls (RPC), transaction broadcasting, etc. However, at that time, only I could see this future but couldn't convince others.

The reason I ultimately chose to self-fund was partly because I didn't have a top university background, didn't understand the fundraising process, and didn't want to validate their doubts through communication with venture capitalists; and partly because I wanted to prove them wrong through actual actions. I feel that this kind of mindset may not be shared by many new entrepreneurs, but this journey was really exceptionally difficult, and I struggled for a long time. Fortunately, I had a decent income from my previous work in banking and hedge funds, had some savings to self-fund, so I didn't fall into the desperate situation of "cannot survive without funding." However, the pressure of self-funding was still significant, especially after starting to recruit employees, the funds were being depleted very quickly.

If you are a solo founder, completely relying on yourself, not hiring anyone, you can actually minimize costs to the maximum—such as moving to a country with extremely low living costs, even living frugally. But once you start hiring, it means having to bear fixed expenses every month, and the pressure instantly escalates. Nowadays, many founders (especially those without a technical background) need to hire developers and engineers from the beginning, which requires them to have multiple skills to control costs.

However, self-funding also has clear advantages: I actually didn't understand many aspects of entrepreneurship at that time. If I had successfully fundraised initially, it would likely have wasted a lot of money, ultimately leading to failure—a kind of failure that would be more painful than "proving your worth to yourself every day." When you are only accountable to yourself, although you demand a lot from yourself, the process is very difficult, but this pressure is much easier to bear than facing disappointment from investors.

Bruce: How many people were there in the early days of Nethermind?

Tomasz: I can't remember the exact number now. About a year to a year and a half later, we applied for the Ethereum Foundation's first grant program and received $50,000, which was when I officially hired the first employee. Previously, Greg joined the team as a founding engineer, co-founder, but he left after a year, although our relationship is still very good. Interestingly, it wasn't until three or four years later that I met him for the first time, so the company was completely remote in the early stages, and the first official round of hiring was probably about a year and a half after founding.

Looking back now, this was actually a good strategy. With AI agents, coding agents, and other tools available today, small teams can accelerate development, making this approach feasible. If the founder has rich engineering experience, a clear vision of the product direction, 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 the relevant aspects of business operations.

My own background has actually laid a certain foundation for entrepreneurship: I hold a Master's degree in Computer Science and have 10 to 15 years of experience building large-scale 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 more. Additionally, I passed the Chartered Financial Analyst (CFA) exam — a three-year endeavor covering a wide range of accounting, governance, ethics and laws, and financial instruments. These experiences covered almost all aspects of business operations and marketing, preventing me from feeling completely lost in the early stages of entrepreneurship. However, even with this background, I still encountered many unexpected situations in practice and had to continuously address new challenges from day one of starting a business.

My first "failure" after starting a company occurred 10 to 15 minutes into founding the company: I went to register the company, and fortunately, registering a company in the UK is very simple — just pay £10, complete the registration in five minutes, and no need to submit any documents for the next year, making the process smooth. I actually recommend this approach to some entrepreneurs, although it may sound counterintuitive, registering a company directly in the UK, Hong Kong, or similar places is indeed very convenient and comes with a certain tax-free period. After registering the company, I applied for a bank account in 2017. The bank asked for the account's purpose, and I explained the company's business in detail — the operational plan of a blockchain company. However, I quickly received a rejection notice with a response stating, "We will not open an account for you. No need to inquire about the reason or contact us again." For the next three years, Nethermind actually operated without a company bank account, and all income and expenses were handled through my personal bank account. Looking back now, this was also feasible.

Bruce: For Nethermind's years of development, what do you consider the key milestones? For example, receiving funding from the Ethereum Foundation should be a significant checkpoint, right? Are there any other noteworthy milestones?

Tomasz: Indeed, there are several key points. Funding from the Ethereum Foundation is definitely one of them, but there are other equally important moments. First is establishing connections with the London blockchain community, and here I must mention Antonio Sabado — he is now Nethermind's Chief Growth Officer and helped me a lot. He encouraged me to integrate into London's community, organize EVM workshops to share knowledge, and advised me to open a Twitter account (I had not used social media for over a year at that time). It was also him who reminded me, "You should apply for funding from the Ethereum Foundation," but my initial reaction was, "I am not qualified enough; they surely won't agree."

Secondly, when the Nethermind client successfully synced to the Ethereum mainnet for the first time, it was a very proud moment. It was the formal delivery of a large piece of software, like watching your own child grow up. The sense of achievement is hard to put into words; it is definitely a significant technical milestone.

On the business side, there are two key milestones: the first one is acquiring the first paying customer—the xDAI network. They proactively expressed interest in using the Nethermind client and requested some custom extension features. For a startup, having the first paying customer is highly meaningful, as it signifies the validation of the business model. The second key milestone was the outbreak of COVID-19. During the pandemic, many people worldwide shifted to online activities, started exploring games, cryptocurrencies, and other digital services, leading to a surge in online payment demands. As a result, blockchain solutions received more attention and funding. Nethermind itself operates in a fully remote mode and had already accumulated mature operational experience in an environment where face-to-face communication was not possible. This allowed us to quickly respond to market needs during the pandemic and secure numerous partnership contracts. In contrast, many traditional companies were still figuring out how to adapt to the digital work environment at that time, experiencing a brief period of chaos. This also gave us a competitive edge.

Prior to that, there were already many successful applications in the Ethereum ecosystem, with a large influx of funds for further investment. There was a high demand in the industry for experienced developers, and at that time, we had accumulated three years of experience in protocol development, which aligned perfectly with market needs, leading our business into a phase of accelerated growth.

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

Tomasz: There are two relatively classic answers. The first one is, "Don't do it"—because the initial three years of entrepreneurship were really draining. The mental exhaustion was unimaginable, and you would constantly doubt yourself. Those days were exceptionally tough. Sometimes I think, if back then I had not chosen entrepreneurship, perhaps I could have avoided that painful experience. Even though now, because of participating in building the Ethereum ecosystem, I have experienced many cool things, looking back to the version of myself eight years ago who was bearing everything alone, I still think that maybe maintaining innocence and continuing with a routine life would have been another, more relaxed choice.

The other answer is "Stay silent." Offering advice to others is actually very irrational because you can never predict the outcomes of different choices. You can only retrospect based on your own life path, but you do not know if making different choices at that time would have led to a better or worse situation. Therefore, perhaps the best advice is to say nothing at all.

Ethereum Foundation Responsibilities and Goals

Bruce: You are now joining the Ethereum Foundation as a Co-Executive Director, working alongside Hsiao-Wei Wang. I'd like to understand how you collaborate and divide responsibilities within the Foundation.

Tomasz: We reached an initial consensus: whoever first takes on a task is responsible for it. This approach addresses two core issues: first, it avoids the inefficiency of "everything must be jointly decided," allowing either party to make decisions independently. Compared to a dual executive director structure, this increases decision-making efficiency. Second, it automatically achieves a division of labor based on individuals' strengths. Everyone will proactively take on tasks they excel at or are more comfortable with, leading to a natural division of labor over time.

Specifically, I am more responsible for external communication tasks, such as participating in podcasts and managing the Twitter account. Hsiao-Wei Wang handles Farcaster platform-related matters and leads a significant amount of internal communication, personnel coordination, and day-to-day operational work. We jointly drive some important initiatives, such as the new compensation policy; she is also primarily responsible for the Foundation's treasury and DeFi-related business. We occasionally exchange views, but in day-to-day operations, we mostly operate independently. Sometimes, we also focus on different regional tasks based on our respective locations, such as speaking engagements. In the future, we do not rule out the possibility of adjusting our division of labor—for example, if I become tired of external communication, I might shift to internal affairs, and Hsiao-Wei Wang may engage more in external communication. Of course, it is also possible that we will continue with the current division of labor. Overall, this has been a very smooth collaboration.

Bruce: It's evident that your collaboration is very cohesive. This year, the Ethereum Foundation announced three core goals: L1 scalability, blob scalability, and improving user experience. Now that you have been with the Foundation for about six months, which goal do you find most challenging? Why?

Tomasz: Which goal is the most challenging is a question that should be directed to colleagues specifically responsible for those areas. However, in my opinion, the "Interoperability and User Experience" goal has the broadest scope, and it is therefore the most challenging. The core difficulty lies in that it is hard to quantify the completion of this goal, and it is not possible to clearly state when all sub-goals will be achieved.

Let's start with L1 Scaling and L2 Scaling: L1 Scaling has clear quantifiable metrics, such as the goal to increase the Gas Limit per block to 100 million, and then further to 300 million. With specific targets in place, the team can progress efficiently in a clear direction. On the L2 Scaling front, while some paths may still be unclear, the overall direction is clear — we will advance Blob extension to accelerate the implementation of Dencun upgrade (which will eventually support 128 Blobs), followed by continuous iterations. Of course, there is currently no clear answer regarding how to further advance the two-dimensional Peer Data Availability Solution (PeerDAS), but engaging with Alex Stokes, Foundation researchers, engineers, and core developers can provide insights into the specific next steps. I recently discussed Blob Scaling plans with Vitalik, and he has a very clear vision of the entire roadmap, so from that perspective, Blob extension may not be the most challenging. However, the concept of Data Availability itself is a significant issue — how to implement it correctly, how to ensure competitiveness while maintaining an adequate level of decentralization and security, all of this still requires ongoing exploration.

Now, turning back to the "Interoperability and User Experience" goal: Currently, we have two main delivery proposals. One is the OIF (Open Intents Framework), and Josh Rudolf recently released a very detailed summary, outlining all the work we have done in the ecosystem around this framework. The other is the EIL (Ethereum Interoperability Layer), which is a proposal put forward by the AA (Account Abstraction) team and has also received support from me, Marissa Posner, and their team. This proposal will be formally announced during the Devconnect conference.

The core challenge of this goal lies in the "lack of unified standards": Some may argue that "current interoperability is already good enough," while others believe that "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 be security and privacy, performance and latency, targeted at retail users or institutional users, or even specific scenarios like wallet usability. Because the definition of "user experience" is so broad, it is challenging to define "success" in a way that everyone agrees with, and this is also why it is the most challenging aspect.

L2 Interoperability Challenge

Bruce: We all know that L2 is a crucial part of the Ethereum ecosystem, but currently, interoperability between L2 solutions still faces many challenges. 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 challenges of L2 interoperability are multifaceted. If it is an EVM-based L2 network, achieving protocol compatibility and interoperability between them may be relatively easier; however, the core challenges are concentrated in several areas: bridge security, permissionlessness, and how to retain the core attributes of the L1 chain during interoperability (such as permissionlessness, censorship resistance, etc.). Among them, "trustless, permissionless asset bridging" is a significant challenge—many current solutions under the OIF framework and existing bridge tools on the market have yet to fully meet 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 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 a core feature of EIL.

In addition, L2 interoperability also faces many challenges at the detailed level: such as uniformity in address representation, compatibility of tools and applications on different chains (such as multi-signature functionality), unified representation of stablecoins in cross-chain scenarios, and consistency in wallet experience—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 put forward many suggestions, such as how to standardize address representation and consistently present asset information. The core goal is to make cross L2 operations "feel as convenient as operating on a single chain," but to achieve this goal, many detailed issues need to be addressed.

Bruce: From my observations, L2 interoperability is not only a technical challenge but may also involve some conflicts of interest or business considerations.

Tomasz: I have also mentioned many times that advancing interoperability should start with the connection of "people"—only when individuals from different teams are willing to communicate and integrate systems, rather than deliberately building "on-chain barriers," can interoperability truly take root. However, sometimes due to business considerations, some L2 operators may not be too eager to cooperate proactively, which is also one of the goals we have set for ourselves at the Foundation: to help the entire L2 and L1 ecosystem collaborate more closely.

We recently had a proposal: Next year, we will bring together engineers and researchers from the L2 ecosystem to hold a dedicated summit. This idea stemmed from feedback from some L2 engineers — they mentioned that core developers in the L2 space have rarely had the opportunity to meet in person. At first, I didn't quite understand because core developers in L1 attend many conferences every year and frequently have face-to-face interactions. After deeper conversations, I realized it was true: all L1 client teams regularly hold offline meetings, but there is a lack of such communication channels among core developers in the L2 space. So, we hope that by organizing a specific event, we can promote communication and collaboration among L2 teams.

Interestingly, many people would say, "L2 engineers are willing to collaborate with each other and are eager to achieve interoperability," but this actually overlooks business considerations — those responsible for strategic and business decisions need to consider brand building, market positioning, and competitive landscape. They may have concerns about cross-chain collaboration and even feel that "overcollaboration is not appropriate." However, if you communicate directly with engineers, you will find that their core motivation is very pure: they just want to solve technical problems, so they are always willing to cooperate.

EF's Future Priorities and Strategy

Bruce: Looking ahead, what are EF's priorities? What strengthening measures will be taken in terms of strategy development, community engagement, and external partnerships?

Tomasz: Obviously, EF's work covers multiple dimensions, including security, protocol upgrades, testing and verification, and ecosystem coordination. A significant part of the core goal is to collect information through dialogues with various ecosystem participants — whether from the cypherpunk community or major institutions — distill needs, and then convey this feedback to all core developers. This is done by focusing on research to assist in advancing relevant work while avoiding imposing development directions too strongly. It's a delicate balance: we want to play a coordinating role, analyze and judge development directions, communicate our thoughts to the community, but cannot dictate that "we must move in this direction."

All core developers are opinionated, experienced, and meritocratic groups. 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 that direction that "everyone agrees on" — regardless of whom you communicate with, everyone can reach a consensus. This way, 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, the three main goals we set for this year — "Scaling L1, Scaling L2, Optimizing Interoperability and User Experience" — have garnered sufficient consensus, allowing core developers, researchers, users, DeFi builders, and all other stakeholders to agree, enabling collaborative advancement.

Now that we have started discussing next year's direction, I initially proposed focusing on "Finality, Privacy, Security." However, some feedback was received that security and privacy are already default priorities and work in these areas will progress regardless. Later, I heard Dankrad's opinion that we should continue advancing Layer 1 scaling work because this task is not yet complete — previously, we planned to increase the Gas limit per block to 300 million over two years, and this is still ongoing. During the discussion, we will take full account of feedback from all parties in the ecosystem, and the final goal must be a direction accepted by core developers, researchers, all users, and DeFi builders. We are currently in the exploration phase, but "Finality" is definitely a key part: many institutions, L2 project teams, and users have expressed their desire to shorten block times and increase finality speed, and there are already some high-quality proposals in this regard. Additionally, we may continue to advance scaling work to make the narrative more concise, or focus on specific security and privacy-related projects — although this may not need explicit emphasis as work in these areas will continue. For example, we have a "Privacy Cluster" separate from the protocol team, consisting of 50 people, who have a clear roadmap for privacy technology development, solutions, and institutional privacy requirements. Ongoing feedback indicates that privacy is a core demand for institutional users, specifically referring to the establishment of relevant standards and specifications on how to leverage existing solutions on Ethereum to meet specific privacy needs.

Bruce: The next question is, how can the EF further increase community participation, support ecosystem development, and build a more vibrant and 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 redesigned a high-quality Founder Success team focusing on developer education, accelerating enterprise application adoption, while collaborating with universities and the Ethereum Everywhere team. We have also partnered with physical spaces (such as community centers) to hold offline meetings, events, etc.

In terms of funding, we have also made major changes: we have almost completely abandoned the "no-strings-attached financial funding" model — simply giving money without expecting any output, no longer simply saying "you can build, we'll support financially." Instead, we prefer to provide assistance through "coordinated empowerment": such as connecting project teams, networking resources, amplifying project visibility; increasing project exposure through social media accounts and PR channels; actively promoting at various Ethereum-related events so the community knows "what's happening in Shanghai, what's happening in Shenzhen, what's 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 partnered with The Hong Kong Polytechnic University (PolyU).

We aim to consistently deliver core messages in these regions and continuously ask the community, "How else can we help?" Because community development must be an autonomous journey — maintaining independence throughout the community-building process can inspire a stronger entrepreneurial spirit. This is the concept we want to convey to all participants in the ecosystem. Core developers themselves possess a certain entrepreneurial spirit; they work independently and focus on delivering results. Application developers are evidently more entrepreneurial as they have to start startups and develop applications. Therefore, this "autonomy-driven + moderately empowered" approach to community building can better stimulate proactivity in the ecosystem.

In the future, we will continue to advance the development of these physical hubs while collaborating with relevant parties to onboard sponsors — these sponsors may come from L2 project teams, application developers, and other ecosystem entities. We will tell them, "This event aligns well with your goals" and "This community is addressing the issues you are facing," helping them establish long-term partnerships. Sometimes we may also directly become clients of some projects, but this situation will be less common than in the past.

Artificial Intelligence and Ethereum

Bruce: I can see more and more local community centers emerging, which is fantastic. We've already discussed your personal growth, Nethermind, EF, and protocol-related topics. Now, let's focus on AI applications on Ethereum — a very cutting-edge area. I've seen many people say, "AI doesn't need Web3; Web3 is just riding the wave of AI's popularity." What are your thoughts on this?

Tomasz: For many AI companies, Web3 signifies security, censorship resistance, and the defense mechanisms brought about by decentralization. However, they are currently facing intense industry competition and must rapidly deliver results, generate revenue, and introduce faster, superior models. Therefore, Web3 may not be a top priority in the short term. But when they realize that certain mechanisms can help them attract more users — especially when more users start to focus on privacy protection and result validation — the value of Web3 will become apparent.

I think this logic is similar to Web3 entering other industries: about 5% to 10% of each industry's scenarios truly require a "trustless delivery" mechanism. In most cases, relying on the existing trust system is sufficient. However, as assets become more digitized and more assets are put on-chain, Web3 will eventually become the default choice. In the AI field, this process may happen more quickly — because AI agents themselves are digital, they use digital assets from the very beginning, and the integration of Web3 payments with AI agents could become a core driver. This is the key scenario where AI needs Web3: our long-standing vision is to enable people to naturally use its functionality without discussing blockchain or mentioning Web3.

As for scenarios like attestation validation, training validation, decentralized training, the adoption may be slower, perhaps always remaining a niche demand. We often discuss the "validation of reality versus truth," but what's popular in the market may not necessarily be the truth — for example, when we consume entertainment content, listen to stories, what we are actually purchasing is "positively construed fiction." What we desire is an exciting narrative rather than mere facts; we just want to be entertained. Many news media outlets are the same way. While they convey information, they also provide entertainment value. Facts are just the canvas on which stories are built, capturing attention and eliciting emotional resonance.

When people use AI to access world news, acquire external information, do they actively seek to verify authenticity? Perhaps not necessarily. But in institutional scenarios — such as enterprise procurement data needing real information — the demand for Web3 will become increasingly stronger. This is because we have already experienced the scourge of fake news, and now the risk of "false reality" is escalating: AI can generate an entire set of fabricated news, social media content streams, and even fictitious characters and video content. If you stay indoors for an extended period, you may be misled by this false information, believing that a fictional world actually exists; even when you step out of the room, parts of the "reality" around you may become false due to excessive reliance on technology.

Therefore, those willing to pay for authentic data, needing to verify all information, will become the core audience of Web3, which is also the irreplaceable value of Web3. For retail users, the situation may be more ambiguous: they typically opt for lower-priced data services, and if Web3 can help data providers reduce operating costs, insurance costs, or risks, consumers will naturally lean toward Web3-based solutions. Although retail users do not often mention "decentralization," the need for "privacy" has always been there.

I have been discussing this topic a lot recently because someone said, "Nobody cares about privacy." However, this year when I was in Milan, I saw a giant billboard of Apple in a taxi, which read "Safari Privacy." As a large international company, Apple has conducted extensive market research, understanding what values consumers are willing to pay for, ultimately choosing "privacy" as a core promotional point, placed at a key location in the Milan financial district. This indicates that users are either actively demanding privacy protection or have an underlying need — just not explicitly expressed. This demand will drive them to pay for related services. Especially when AI may fully grasp personal information, leading to complete privacy breaches, the user's focus on privacy will further intensify, and Web3 can provide security, privacy protection, and user control to AI, so 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 relevant new standards. Can you provide a specific overview?

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

ERC-8004 is specifically designed for AI agents, leveraging the blockchain's "trustless" feature (i.e., the trust environment provided by the blockchain), on top of protocols like A2A, to ensure trust relationships between agents. It defines a series of "trustless" rules: how agents declare their identity, register, disclose provided services, validate each other's declarations, query other agents' reputation, and verify other agents' work—such as by introducing external on-chain and off-chain verifiers, rerunning parts of the execution process and confirming the results.

These functionalities combined can support two core scenarios: one where agents act on behalf of users, where users delegate their identity to agents, similar to using a computer where the computer acts as a tool representing the user to perform operations and use the user's identity; and the other being autonomous agents, representing AI agents that operate independently on-chain deployed accounts. Many top AI agent domain practitioners have been involved in the development and improvement 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 people are now starting to build tools around it, such as developing dashboards, deploying the first implementation of ERC-8004, launching ERC-8004-compliant AI agents, etc. This is a very exciting moment, full of entrepreneurial and building opportunities. While the Ethereum ecosystem has previously experienced a surge in tokens and NFTs, it now appears that AI agents are likely to become the next core direction.

Bruce: I noticed that earlier this year, ChaosChain and the concept of "agentic governance" were very popular. How are these projects progressing now? What assumptions will you test next?

Tomasz: This can be traced back to the vision I had during my time at Nethermind—back then, I discussed with the team the possibility of "agentic governance": will core developers gradually be partially replaced by AI agents? Of course, this "replacement" is not a complete substitution but rather assistance. Observing our daily work, we have already started to frequently consult large language models (LLMs), AI chat tools for advice, referencing the information they extract from datasets, which has somewhat influenced our decision-making process. The training data and algorithm bias of the models may steer our decisions in a specific direction.

When a core developer asks AI for advice in their work, such as "How should we handle this situation?" or "Is this solution correct?", they will still maintain their own judgment and view AI as a tool. However, this means that about 5% of their thought process may be influenced by AI. Over time, this percentage may increase to 10%—the better LLM performs, the higher the dependency. Especially in unfamiliar areas, core developers may be more inclined to reference AI suggestions, perform simple validations, and then choose to trust, as AI can sometimes provide seemingly perfect answers. There are already some doctoral-level studies that directly adopt solutions provided by AI, and this scenario may become more common in the future.

On the governance side, when the "social consensus layer" decides the direction of protocol development, the ultimate result may depend on "how many proposals AI can generate" and "how much attention these proposals can attract"—similar to how core developers currently spend months researching proposals, presenting solutions, cross-validating, and engaging in debates. If AI starts generating proposals in bulk, AI will be needed to assist in verifying the feasibility of these proposals, essentially becoming a form of "proof of work": searching for valuable ideas, validating their feasibility, and once high-quality ideas are found, driving the protocol in that direction.

However, there are risks involved: if someone filters ideas—only making public proposals that align with their expectations, hiding content that is not favorable to their goal—then "social consensus governance" will become a proof-of-work mechanism based on "idea generation and validation." If we further extrapolate, as the speed and quality of idea generation continue to improve, the iteration speed of the protocol will also accelerate, possibly even achieving "block-level social consensus," where every block is accompanied by protocol changes, including validation and voting processes. Imagine how complex such a system would be.

We began discussing ChaosChain at the end of last year or early this year and conducted some related demos in the Bay Area. An internal team at Nethermind was also formed to explore this, and now this team is splitting off from Nethermind to independently drive the project. However, the concept of ChaosChain has diverged into two directions: one direction involves the team exploring AI agent-related applications based on ERC-8004, which can be seen as focusing on general research on "agent governance." Practical foundational solutions have already been developed, laying the groundwork for future construction. The other direction involves the team combining research results from the Hetu team and Vitalabs to explore "attribution of agent work"—that is, when AI agents collaborate, how to determine reward mechanisms based on contributions, which is similar to proof of work.

Meanwhile, Nethermind itself continues to adhere to a pure DAO governance model, leaning more towards using AI agents to assist DAO decision-making. We believe that DAO participation and core development have many similarities: the board of directors in a DAO is responsible for making decisions, allocating resources, and validating technical solutions (such as those proposed by L2 projects), which aligns with the logic of core developers validating proposal quality and deciding whether to invest resources to implement them; fundamentally, they are both engaged in "capital allocation."

From DAO Participation to AI Agent Deep Dive into Governance, there will be a natural evolution process: first, the AI agent will start drafting proposals on the ETH Research forum, commenting on existing EIPs (Ethereum Improvement Proposals), and pointing out issues; then, being able to independently draft EIPs and drive them to completion; next, the AI agent may join the AllCoreDevs call (even without video) and express opinions in the chat about proposals; finally, the AI agent will be able to join video calls, actively speak up, comment on proposals, and even present its own solutions and argue for them. There is no magic in this process; based on the current level of AI technology, as long as technological rollout is incremental and a sufficient core development expertise is integrated, this can be achieved—this is also why we believe Nethermind is the ideal platform to kick off 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 developer-focused: How will the Ethereum Foundation support and coordinate the direction of AI integration with Ethereum globally? Could 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 made significant progress: they released the ERC-8004 standard, which sparked widespread attention, and also announced collaborations with institutions like Google, Cloudflare, Coinbase, among others—at least the Foundation played a coordinating role, driving the agent payment solution, which brought a lot of attention to Ethereum and its related standards, attracting more participation in agent, dashboard, and registration process development. I'm sure that in the past two months, there have been some "stealth startups" building products around ERC-8004, which is exactly what we want to see.

Many people's core ask of the Foundation is for us to provide the "canvas" for developers to build the next wave of application-driven innovative products—and the AI agent is likely that "next cool thing." Although in the last few months, the hype around AI agents and the blockchain space has cooled off, many VCs remain skeptical, but I believe the hype will come back.

The dAI team will have more surprises and ideas to announce in the future; the team will expand, but not excessively—because we want to continue playing the role of "coordinator" and not directly develop applications based on these standards. In addition, we have launched education-related initiatives; the dAI team will provide specialized support, so if you are working in a related field, feel free to reach out to them, and they will respond promptly and provide the necessary support. I remember they will also collaborate with mainstream AI projects to host hackathon events.

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

Bruce: I also agree that coordination and cooperation between different regions may lead to many excellent solutions. This also raises 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 recognize the enormous potential for collaboration between Hong Kong and mainland China—nurturing startups together, aligning with local policies and goals, and exploring suitable collaboration directions will yield many valuable outcomes. For example, cross-border payments is an area worth attention and may evolve into agent-based payments in the future. Furthermore, how China's open-source AI models can align with global solutions is also a crucial 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 key path for future collaboration: leveraging China's strengths in robotics and open-source AI to jointly develop innovative products.

Of course, we also look forward to seeing complete solutions born locally in China, especially in terms of innovative coordination layers, which align with Ethereum's core principle of "global neutrality." The Chinese community is fully capable of building very successful projects.

Bruce: I believe there are still many things 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 practical actions to drive industry development.

Wrap-up

Bruce: Alright, our interview today is coming to an end. Let's wrap up with a few quick Q&As. Do you usually read books?

Tomasz: I rarely manage to read a whole book from start to finish now. Mainly due to lack of time—my current approach is to buy a book, skim through it to understand the core themes, then have LLM tell me what the book is about, its importance, and key insights. After that, I occasionally read parts of chapters to feel the writing style and validate if LLM's summary is accurate.

Over the past few months, I have been focusing on content related to complex systems at the Santa Fe Institute. I was previously looking at Kauffman's "The Origins of Order" to better understand the formation of natural hierarchical structures—such as the hierarchical relationship between L1 and L2 in the blockchain ecosystem. Now, most of my "reading" is actually exploring LLM's answers on specific topics and cross-referencing with the original sources for validation, and the instances of completing reading a whole book are becoming less and less common.

Recently, I received a wonderful gift — the Bastion Foundation sent me a copy of "Babette's Feast." They knew I loved this movie, so they specially gave me the original book. I have been carrying this book with me everywhere, hoping to finish reading it soon.

Bruce: You are juggling multiple initiatives effortlessly while maintaining high energy levels. Can you share any practical habits related to sleep, exercise, diet, and scheduling that help you?

Tomasz: I definitely wouldn't consider myself a role model in this regard because my life is completely irregular — often traveling between different time zones, irregular sleep patterns, no fixed schedule, mostly doing things on the fly, always in a rush. However, over the years, I have had a few small rules that have always helped me: for example, I try not to schedule meetings on Fridays, which allows me time for trips or a whole day of uninterrupted focused time. Of course, sometimes I accidentally end up with 1-2 meetings, but most Fridays I am free, which also means that Monday through Thursday is usually very packed.

There's also a simple trick I recommend everyone to try: in Google Calendar or any scheduling tool you use, set meetings to end 5 to 10 minutes early. That way, there is buffer time between meetings, which significantly reduces stress. I've seen studies showing that this setting can significantly reduce stress levels. After all, meetings tend to overrun, but if you originally set it to end 55 minutes, even if it runs 3-5 minutes over, it won't affect the next meeting. If meetings are back-to-back with no buffer, once one overruns, you'll be late, and you'll become very anxious, with no time even for note-taking or preparing for the next meeting.

Bruce: You travel frequently. Do you have any tricks for dealing with jet lag?

Tomasz: I don't actually have many tricks. Because my sleep is already irregular, I'm almost always in a "jet-lagged" state, so I don't feel a significant jet lag when traveling. And I rarely travel back and forth across continents frequently — many people travel for work to a place and then back, which requires two adjustments to sleep patterns; but I usually travel gradually in one direction and don't do short-term back and forth trips, avoiding the hassle of adapting to jet lag repeatedly.

Bruce: Alright, that's all for our interview today. Many thanks to Tomasz for participating today, and once again, welcome to Shanghai.

Tomasz: Thank you, thank you very much.

This article is from a contributor and does not represent the views of BlockBeats.