As a blockchain and smart contract engineer since 2019, I've witnessed numerous attempts to improve user experience and onboarding in the Web3 space. While many solutions have shown promise, a lot have fallen short of delivering truly intuitive interactions. However, the emergence of AI agents presents a paradigm shift in how users can interact with blockchain technology—potentially eliminating the need for traditional browser-based interfaces altogether. I discussed this potential back in October 2024, and now I'm excited to share my hands-on experience building with ElizaOS.

Choosing an Agent Framework

After evaluating various options, I settled on ElizaOS (ai16z) for two primary reasons: its TypeScript foundation and its Web3-centric focus. The framework's architecture, detailed in their whitepaper, aligns perfectly with the goals of building blockchain-native AI agents that can abstract away many wallet and bridge problems.

Getting Started with ElizaOS

My journey began with the excellent AI dev school curriculum, which provided a solid foundation for understanding ElizaOS. After thoroughly reviewing the ElizaOS documentation, I forked the eliza-starter repository to create my project: ai-donkey.

The goal behind AI Donkey was to explore how we can constrain an AI agent to technical specifications—in this case, the ERC20 token standard. While ERC20 is "just" an interface specification for smart contracts, the diversity of implementations can be both a blessing and a curse when tokens are deployed in production (a topic I'll explore in detail in a future article).

Initial Development and Observations

After forking the template, I:

1. Upgraded to Eliza core v0.1.8 to access Deepseek support and newer features

2. Developed an initial version of Donkey focused solely on building ERC20 tokens using OpenZeppelin smart contracts

3. Experimented with different language models, starting with Claude before transitioning to Deepseek

Testing the agent revealed interesting insights about AI-driven smart contract development. In one particular test, I requested "a token with a supply of 500M tokens that is burnable and additionally is non-transferrable unless the transfer is disabled (one-way disable)."

While the agent successfully met the basic requirements, it made assumptions about transfer enablement, defaulting to an onlyOwner pattern. This highlighted two critical areas for improvement:

1. Assumption Handling: Agents should clarify uncertainties with users rather than making implementation decisions independently. While the onlyOwner pattern is well-established (often using multi-sigs or DAOs), assuming this was the user's intention could lead to misaligned implementations.

2. Technical Translation: Agents should provide non-technical summaries of generated code and share implementation plans for confirmation before execution.

The Starter Repo Approach: Pros and Cons

Advantages

• Reduced complexity compared to the core Eliza repo

• Rapid deployment capabilities

• Straightforward model integration with proper API configuration

Limitations

• Lacks the ChatGPT-style browser interface available in the main repo (unless I missed something)

• Custom functionality requires plugin development if not available in existing Eliza plugins

Plugin Development

The plugin development process has recently undergone significant changes. Previously, it involved creating an issue, forking the main Eliza repo, adding the plugin, and submitting a PR—a process I began exploring myself. However, ElizaOS Labs recognized this approach wasn't scalable and has introduced a new system for plugin development and distribution.

This evolution represents a crucial step toward building a more robust and accessible ecosystem. The new approach promises to streamline plugin development while maintaining quality and security standards.

Looking Forward

While creating a basic AI agent has become remarkably accessible, the real challenge—and opportunity—lies in delivering genuine utility that drives repeated user engagement. In the blockchain space, this means developing agents simplify complex UX patterns but can also bridge the gap between technical specifications of protocols and implementations with user experience in mind.

The combination of AI agents and blockchain technology represents a powerful paradigm shift in how we approach Web3 user experience. As frameworks like ElizaOS continue to evolve and mature, we're moving closer to a future where interacting with blockchain technology becomes as natural as having a conversation.

The journey with Donkey is just beginning, and I'm excited to explore how we can leverage this new paradigm to build more sophisticated and useful tools for the Web3 ecosystem. Stay tuned for more developments and deeper dives into specific aspects of AI-driven smart contract development.

If you want to chat more about this don’t hesitate to reach out: https://dengltd.tech/