Why I’m writing this
If you’ve been following the on-chain AI space, you might remember that ERC-8004 was almost as hyped as x402 at the start of the year. If I wrote about this on January 1st, 2026, I would’ve predicted the ERC-8004 mainnet launch to drive more interactions between autonomous agents than it did this year. Having followed this space closely, I think it’s fair to say on-chain solutions haven’t seen mass adoption in early agentic workflows this year.
I am not saying that ERC-8004 hasn’t seen any adoption. Plenty of registrations and experiments have happened, but some of the most prominent agentic products this year haven’t needed on-chain identity or reputation to deliver their core functionality. These workflows include Hermes and OpenClaw earlier, and more recently Grok Bot, dots, and Muse. As far as I know, they don’t use ERC-8004 or any other on-chain solution. Meanwhile, although crypto-native agentic payments have gained traction through protocols like x402, they haven’t become a standard part of mainstream agentic workflows.
Most people in this space, including me, still think we’re early. But if you’ve been in crypto or Web3 long enough, you’ve been told
”we’re still early” for the past 10 years! Unfortunately, that doesn’t really help with product-market fit if you’re building something today. Founders and product builders must solve a real problem to be effective.
If the technical builders outside of the Web3 ecosystem haven’t needed blockchain for their agentic solutions, what does that mean for those of us building on-chain solutions?
I think I’ve spent a considerable amount of time this year exploring that question. I believe the agentic economy needs on-chain solutions, but simply building an on-chain version of a solution built without blockchain won’t drive mass adoption. Some of my on-chain implementations worked, and some didn’t, and I think I can share valuable lessons from both.
I’m writing this for anyone interested in building in this space. My goal is to share what I’ve learned and encourage you to look beyond your own bias towards crypto and Web3. Hopefully, it’ll help you identify where blockchain adds meaningful value and avoid building on-chain solutions for problems that either don’t exist or don’t justify the additional complexity.
Also, if you’re working in this space and want to share ideas, feel free to reach out.
What have I built
I’ve worked on a wide range of on-chain and agentic solutions this year. Some have been for clients exploring payments, while others just wanted to build Polymarket bots. It’s given me exposure to different use cases and a better understanding of what people actually want to build with AI agents and blockchain. I’ve also learned that high interest in developing something doesn’t mean it will succeed or gain traction.
I’ve also built several projects through hackathons, or just to test out the market. Here are some projects I’ve built:
ClawSt: Co-built this platform, which won Hedera’s Agentic Bounty at ETHDenver 2026. It enabled OpenClaw agents to interact with other agents autonomously. Users (not agents) evaluated the performance to ensure assessments were accurate.
Group Pool: Independently built this platform designed to help wholesalers discover opportunities and buy and sell products globally. I also experimented with variations that allowed agents to handle initial negotiations and compliance checks before involving humans.
CanHav.Co: Built this research tool to help builders discover work being done across their ecosystems and use those insights to improve their own projects. I also integrated Fully Homomorphic Encryption (FHE) into agentic workflows. This project won an agentic prize at an invite-only Arbitrum buildathon in London in July 2026.
TwoField: Experimented with a platform that connected AI agents to MCP servers, allowing users to manage and improve their agents based on their needs. Built on the Arc testnet ahead of its mainnet launch, it explored integrating all three ERC-8004 registries: Identity, Reputation, and Validation.
All four projects might have had a different purpose or customer, but I found myself repeatedly returning to three technical approaches:
ERC-8004 or a variation of this standard to track and evaluate the agents’ work.
x402 and stablecoins as the definitive tools for settlement of agent-to-agent transactions.
Guardrails that allow agents to work only in a specific enviroment, and not venture beyond it.
I’ve learned a lot through building these solutions, but looking back, I can also identify some obvious blind spots. Even projects that clients appreciated or that won prizes at hackathons weren’t necessarily solving problems that required blockchain.
That’s an important distinction, and one I wish I’d thought about more carefully before starting some of these projects.
The next section covers the lessons I’m taking forward, and what I think other builders should consider before committing to an on-chain implementation.
My five biggest lessons
Here are five lessons I’ve taken away from building on-chain agentic solutions this year. They’re by no means exhaustive, but I believe they’re particularly important if you’re building in this space.
Solve a real problem that needs an on-chain solution.
We all tend to believe we’re solving a real problem when we start building something, but there’s a difference between having a hypothesis and validating it with actual users.
If you’re an experienced developer, you’re probably reading this and saying this applies to any product! That is 100% true. But I really think it’s especially important to reiterate this in Web3 and DeFi.
When you’re building agentic solutions, it’s easy to look at blockchain’s immutability, transparency, or decentralization and assume these features automatically add value.
Do your users actually need them? If you’re a Web3 enthusiast like me, you probably have some bias here. I’d encourage you to challenge that assumption and ask whether blockchain solves the problem better than existing alternatives, or whether the pain point you’re addressing is significant enough to enable someone to switch and learn everything that comes with working on blockchain technology.
Your audience isn’t crypto native
I attended Chainlink’s LINK event last week, where Steven Goldfeder, CEO of Offchain Labs, spoke about the future of programmable finance. He pointed out the importance of thinking beyond crypto-native users. The end user doesn’t care whether you’re using USDT or USDC for their transaction, just like someone watching a YouTube video doesn’t really care whether you are running the platform on AWS or Google Cloud!
Unless you’re building for a highly technical Web3 audience, you need to make your product accessible to people unfamiliar with blockchain.
If a developer has to install MetaMask, configure a testnet, find a faucet, and acquire test tokens just to try your solution, you’ve already introduced significant friction. I’ve started thinking carefully about onboarding, wallets, on- and off-ramps, and how much blockchain knowledge my users actually need. Ideally, they shouldn’t have to think about the underlying technology at all.
Security and Compliance are BORING AND OVERWHELMING, but critical.
The recent Binance hack reminded all of us how serious security risks remain in this industry. However, similar cases have happened all year, and hackers have gained access in similar ways.
These attacks involve social engineering, compromised developer environments, and internal systems. These hacks are not simply smart contract vulnerabilities. For small teams or solo founders, it can be overwhelming to think about how even established organizations haven’t been able to address critical vulnerabilities. Unfortunately, for any builder in this space, this is the current reality that we operate in.
If you’re building autonomous agents that interact with wallets, smart contracts, or real funds, think carefully about what could go wrong. That includes access controls, transaction permissions, monitoring, and applicable compliance requirements.
If you’re unsure where to start with security, I’d encourage you to explore OWASP’s resources, including their:
i) Top 10 for Agentic Applications, a peer-reviewed framework outlining critical security risks in autonomous AI systems, and ii) Smart Contract Top 10, which highlights the most critical vulnerabilities in smart contracts.
As a solo builder, I know how tempting it is to prioritize functionality and put security off until later. But if you want people to trust your product, security can’t be an afterthought.
(Actually) Understand the ecosystem.
Choosing which blockchain to build on is more important than simply comparing transaction fees and technical capabilities.
Different ecosystems offer different infrastructure, integrations, communities, grants, and incentives for builders. Base, Arbitrum, Solana, Stellar, and others have programs that can help early-stage projects, but incentives alone shouldn’t determine where you build. Also, building on all of them at the same time in your first iteration is not a great idea, either.
I’d also encourage you to explore the applications already operating in your chosen ecosystem, from agentic payment solutions to agent-to-agent marketplaces and autonomous applications.
You might discover an existing solution you can integrate with, a problem someone has already solved, or an opportunity that hasn’t been explored. Understanding the ecosystem can save you a lot of unnecessary development work.
There’s no product without guardrails.
One mistake I’ve made is trying to build too much into an initial product. When you’re working with AI agents, the possibilities can feel endless. In the Web3 ecosystem, there’s always another integration, feature, or workflow you could add. Many of these integrations might be tempting, especially if a hackathon offers a prize for integrations.
But your MVP should focus on solving one core problem effectively. Everything else can wait. This also applies to the agents themselves.
Define what your agent can do, what requires human approval, and what falls outside its responsibilities. It’s equally important to understand what your product can’t do as what it can.
There’s always a temptation to add more, but sometimes the best decision is knowing what not to build.
What I’d do differently, and where I think agentic Web3 is heading
I am always ideating and prototyping in this space. However, if I joined a startup or a lean organization ideating an agentic solution to take to market. I really wouldn’t spend more than a week building an initial prototype without some form of validation.
In our new reality of really great AI models and AI IDEs, it’s easy to get caught up in development. However, validation still needs to be done by a human.
I think we need to spend less time building unvalidated features and more time understanding whether anyone actually needs them. The technology is really cool, and it’s kind of fun to sit and put together a version of a product that uses both blockchain and AI. But if no one uses these products, then there’s no point!
I still believe there’s a real use case for on-chain agentic workflows, and I’m confident these solutions will find their users. However, I also think meaningful adoption could take longer than I anticipated at the start of this year.
If you’re not an organization with infinite resources and need to find product-market fit right now, I’d recommend focusing on products that can deliver utility today.
In my own work, I find the initial customers may need to be technically experienced users willing to tolerate crypto's current limitations, including security risks, complicated onboarding, on- and off-ramps, and even tax requirements. These might not be massive markets initially, but they could help validate demand and build sustainable businesses.
For anyone looking to build something with broader appeal, I’d encourage you to explore what’s already available before developing your own infrastructure. We’re starting to see platforms like Grok Bot connect with existing tools, while services such as MetaMask Agent Wallet, Phantom, Alpaca’s Trading API, and 1inch are making agentic interactions with financial and on-chain infrastructure increasingly accessible. I haven’t used these connectors on Grok Bot yet, but I am looking forward to experimenting with them.
In both cases, rather than building entirely new smart contracts and workflows from scratch, I think there’s an opportunity to create useful products by connecting these existing capabilities, solving a specific customer problem, and making the experience significantly easier for the end user.
Closing Thoughts
Lastly, I want to emphasize that, like most industries, there’s no fixed formula for success in this space.
If there was a fixed formula for success in agentic economy and I knew it, I probably wouldn’t be writing about it.
That said, I’m genuinely enjoying building and experimenting with these technologies, and I’m excited to see where the agentic Web3 ecosystem goes next. Actually, that’s probably the only way you can succeed in an uncertain market like agentic commerce if you’re not a giant in the space like Stripe!
If you’re working on an on-chain agentic solution, exploring an idea, or simply want to exchange perspectives, I’d love to connect. Feel free to email me at waz@canhav.com or book time here for a conversation.
If I missed anything or you disagree with something, I’d love to hear your thoughts. I’m still learning too.