In the rapidly evolving landscape of AI agents operating on blockchain networks, one of the critical challenges is designing a secure, non-custodial wallet architecture that enables autonomous operation while maintaining developer control. This article presents a comprehensive blueprint for implementing wallet architectures in multi-tenant agent launchpads, where one platform deploys agents on behalf of multiple developers.

The Challenge

Agent launchpads face a unique set of requirements that traditional wallet architectures don't fully address. These platforms need to:

1. Enable agent creators to deploy one or multiple agents
2. Provide seamless fund management (onramp/offramp)
3. Support autonomous on-chain operations
4. Maintain non-custodial control (ensuring the launchpad cannot control agents' wallets or funds)
5. Handle gas sponsorship

Proposed Architecture

Core Components

The architecture centers around smart contract wallets with a dual-key system:

1) Smart Contract Wallet

• Each agent operates through its own smart contract wallet
• Implements role-based access control
• Can include additional safety measures like spending limits and address whitelists

2) Dual-Key System

• Admin Key (Developer-controlled)
• Agent Key (TEE-managed)

Key Management

Admin Key

The admin key represents the developer's ultimate control over the wallet. It can be implemented through various mechanisms:

• MetaMask or other external wallets
• Passkeys (face or touch ID) like Crossmint
• Social login wallets like Magic, Dynamic, Privy

The crucial aspect is that this key remains exclusively under developer control, never touching the launchpad's infrastructure.

Agent Key

The agent key enables autonomous operations and requires special handling:

• Must be generated and stored in a Trusted Execution Environment (TEE)
• Can have full or restricted permissions
• Permissions can include:
  • Maximum spend limits
  • Whitelisted contract addresses
  • Blacklisted operations

TEE Implementation

The Trusted Execution Environment is critical for maintaining non-custodial status. Key requirements include:

1) Complete Control Loop Encapsulation

• LLM API interaction
• Action processing (e.g., using libraries like GOAT)
• Key signing operations

2) Example TEE Platforms

• Lit Protocol (TEE+MPC)
• Marlin Protocol
• Phala Network

Security Considerations

Maintaining non-custodial status is crucial both for security and regulatory compliance. Non-custodial control means that the launchpad platform cannot access or control the funds in agents' wallets. This is essential not only for security but also for regulatory compliance, as controlling user funds would require costly money transmitter licenses in jurisdictions like the United States.

To ensure non-custodial operation, several security measures must be implemented:

1) Prompt Isolation

• All prompt processing must occur within the TEE
• External LLM services can be used, but prompt handling must be encapsulated

2) Action Mapping

• The correlation between prompts and on-chain actions must be secured within the TEE
• No external manipulation of action execution should be possible

3) Key Segregation

• Clear separation between admin and agent keys
• No launchpad access to admin keys
• TEE-based agent key management

Conclusion

This architecture provides a robust foundation for building non-custodial agent launchpads. By carefully implementing the dual-key system within a TEE environment, platforms can offer autonomous agent operations while maintaining security and developer control.

Remember that this architecture should be treated as a blueprint and adapted to specific platform requirements while maintaining the core principles of non-custodial control and secure autonomous operation.

Comparison with Alternative Architectures

While designing this architecture, we evaluated several alternative approaches. Here's an analysis of their trade-offs:

A. Server-Side Key Storage with Environment Variables

This approach involves storing wallet keys as environment variables in agent servers running on centralized computing platforms like AWS.

Key Issues:

• Fundamentally custodial in nature
• The launchpad platform has full access to wallet keys
• Platform can access or destroy keys at will
• Violates regulatory requirements for non-custodial control

B. Server-Side Key Management Solutions

Using solutions like Fireblocks, Turnkey, or Privy server wallets.

Analysis:

• Functionally equivalent to approach A
• More sophisticated key storage
• Still custodial as platform holds API keys
• API keys enable full wallet control and token extraction
• Does not solve the fundamental custodial control issue

C. Single TEE-Based Key Architecture

Creating a single key for the wallet inside a TEE (like Lit Protocol or Marlin Network).

Limitations:

• Suitable only for fully autonomous agents
• Developers lose all control post-deployment
• Too restrictive for most agent development use cases
• Doesn't meet the common requirement for developer oversight

D. TEE with Pre-authorized Control

Implementing approach C with a pre-authorized wallet backdoor in the TEE code.

Concerns:

• Could theoretically achieve similar properties to our proposed architecture
• Significantly more complex implementation
• Higher risk of security vulnerabilities
• Increased chance of fund compromise or loss
• Not recommended for production environments

Our proposed dual-key architecture provides the optimal balance of security, control, and regulatory compliance while avoiding the pitfalls of these alternative approaches. It maintains non-custodial status while giving developers appropriate control over their agents.