‍Multichain Wallet Control for Agents

Building a multichain agent is hard. This is because the process inherits some of the same fragmentation challenges as traditional dApp development. Developers must deal with multiple SDKs, separate libraries, incompatible transaction and key/account formats, different RPC patterns, and the challenge of coordinating state across discrete networks. 

Agents do have an advantage over regular dApps. They utilize blockchains but don’t have to fully live onchain due to different compute requirements. Offchain execution brings many benefits, but generally has one glaring problem: verifiability. 

Fortunately, runtime off-chain logic (ROFL) provides a framework for verifiable execution of arbitrary code via trusted execution environments (TEEs). And one of the unique benefits of ROFL is a key generation feature that simplifies one important piece of this puzzle: cross-chain wallet management. ROFL’s key generation feature allows an agent to control wallets across different blockchains, skipping the usual development overhead and complexity.

What is Key Generation?

Key generation is ROFL's cryptographic key derivation system that allows applications running within TEEs to generate and manage wallet private keys on multiple elliptic curves. Unlike traditional cross-chain solutions that rely on bridges or wrapped tokens, ROFL's approach creates native wallet control on each target blockchain.

The system currently supports two primary elliptic curves: secp256k1, for EVM-compatible chains (or native Bitcoin wallets…), and Ed25519, employed by networks like Solana and Aptos. Keys are generated and kept inside the TEE enclave, with an onchain key management system ensuring secure access control even if the hardware were to fail. This setup guarantees that, for example, an agent can be provably in control of its private keys. 

How Does It Work? 

The technical implementation of key generation leverages the secure isolation of TEEs to create and store cryptographic keys safely. When an app or an agent is deployed on ROFL, it generates cryptographic keys during the remote attestation process, which serves two purposes: 1) proving the app's integrity to the network and 2) enabling secure authentication with onchain modules.

This key generation process is especially useful for multichain operations due to the TEEs’ ability to handle multiple cryptographic schemes. In other words, it can derive keypairs across different elliptic curves within the same TEE, which, in turn, means a single ROFL-powered app can control a wallet on Arbitrum while simultaneously controlling one on Solana. 

It does all this without exposing the keys to any external party, but the main advantage is in transaction execution. Since ROFL apps run offchain in TEEs but have network access, they can use these securely generated keys to submit transactions directly to target chains via RPC calls. This approach eliminates the need for bridges to coordinate crosschain transaction signing. Instead, the agent simply operates native wallets on each chain, with the TEE providing cryptographic security for operations.

Why Does it Matter?

ROFL’s key generation unlocks flexibility for agents and reduces trust requirements for developers and users. By enabling native wallet control across ecosystems, agents are no longer bound to a single chain or completely reliant on a bridge. Decentralized key management systems also enable developers to prove to their users that they are not in control of the agent's private keys and thus reduce scam risk. 

For a builder, the core value here is unified cross-chain wallet management through hardware-secured compute. Instead of managing separate infrastructure for each blockchain, developers can:

1. Use a single codebase to control wallets across multiple chains
2. Employ direct native transactions instead of crosschain messaging
3. Leverage hardware-level protection for private keys and transaction logic

Of course, there is still a need to provide assets on each network, and actually moving funds across chains still requires bridges. Additionally, blockchains like Solana don't support light clients, creating dependency on RPC providers for transaction submission. However, for agents that can operate with native assets on each chain, this approach *significantly* reduces the effort and operational complexity.

Note: It’s recommended that light clients verify chain state and reduce RPC dependence. This architecture choice is made on purpose to extend flexibility for agent developers.

Practical Examples 

For example, consider the agentic treasury protocol Talos. ROFL's key generation enables Talos to eliminate a critical trust assumption: users no longer need to trust that the team won't misuse private keys, since those keys are generated within and never leave the TEE. This allows Talos to operate as a truly autonomous agent across multiple chains, with users trusting the cryptographic guarantees of the TEE rather than the intentions of the developers. 

Another example is zkAGI. In this case, ROFL's secure enclave enables zkAGI's Oasis_bot to encrypt Hyperliquid API credentials within the TEE, allowing users to execute autonomous trading strategies on Hyperliquid without exposing sensitive information. While currently focused on perp trading, the architecture positions zkAGI to leverage ROFL's cross-chain signing capabilities, particularly with an upcoming "Spin the Wheel" feature, which could generate keys for managing assets across networks beyond HyperEVM.

Conclusion 

By introducing this functionality, ROFL opens new design spaces for autonomous agents. Developers can build multichain systems that are both simpler and more secure, while maintaining the privacy and verifiability guarantees of TEE-based execution. Similarly, they can increase the chances of getting agent adoption since they don’t have to ask their users to trust them. Users can verify. Learn more here.