Multichain Wallet Control for Agents with ROFL

It’s been a long time since people have been able to build autonomous agents that work smoothly across many blockchains. Developers have always had to deal with broken SDKs, key formats that don’t work together, and the difficult task of keeping track of state across different networks. ROFL (Runtime Offchain Logic) changes this way of thinking by adding a framework that uses a trusted execution environment (TEE) to allow verifiable off-chain execution. One of its best features is multichain key generation and wallet control.

In this article, we’ll talk about how ROFL makes it easier for agents to manage multiple wallets, why this is important for developers and users, and how you can start using it right away.

The Challenge of Multichain Wallets

At first glance, managing wallets across Ethereum, Solana, and other ecosystems may seem straightforward. However, under the hood, it’s highly fragmented:

• Different SDKs: Ethereum uses Web3.js or ethers.js, Solana uses Solana-Web3.js, and Aptos uses its Move SDK.
• Different cryptography: Ethereum relies on secp256k1 elliptic curves, while Solana and Aptos rely on Ed25519.
• Different RPC formats: Each blockchain defines unique transaction encoding, signing, and submission patterns.

Bridges attempt to unify these ecosystems, but they introduce extra layers of trust, wrapped assets, and security vulnerabilities. For autonomous agents, programs that must be provably secure, this is not an acceptable tradeoff.

ROFL’s Key Generation: A Better Approach

ROFL introduces a TEE-based key generation and management system that eliminates these headaches. Instead of using external key stores or bridges, ROFL agents generate native keys for each blockchain inside the enclave. These keys never leave the TEE, ensuring security and verifiability.

Currently, ROFL supports:

• secp256k1 → Ethereum, Arbitrum, Polygon, Bitcoin, and other EVM chains.
• Ed25519 → Solana, Aptos, and similar ecosystems.

When an app or agent is deployed, remote attestation ensures two things:

1. Integrity Proof — Verifies that the deployed code matches the expected ROFL build.
2. Authentication — Enables secure communication with on-chain authentication modules.

This means an agent can simultaneously:

• Control an Ethereum wallet.
• Control a Solana wallet.
• Submit signed transactions directly to both chains.

And it can do all of this without ever exposing the private keys externally.

Key Generation API

Each registered ROFL app has access to a decentralized, on-chain key management system. Key generation is handled via the /rofl/v1/keys/generate endpoint.

Example Request:

{
  "key_id": "demo key",
  "kind": "secp256k1"
}

Parameters:

• key_id: Used for domain separation. Different key IDs yield different keys, even on the same curve.
• kind: Defines which type of key to generate.
• raw-256 → 256 bits of entropy.
• raw-386 → 384 bits of entropy.
• ed25519 → Ed25519 private key.
• secp256k1 → Secp256k1 private key.

Example Response:

{
  "key": "a54027bff15a8726b6d9f65383bff20db51c6f3ac5497143a8412a7f16dfdda9"
}

The response contains the generated key in hexadecimal form. Importantly, the private key is confined to the enclave and cannot be exported, this response is only accessible from within the TEE.

How It Works (Step-by-Step)

Architecture of ROFL multichain wallet control: keys are generated and stored inside the Trusted Execution Environment (TEE), never leaving the enclave, with direct RPC access for Ethereum and Solana wallets, and on-chain authentication via the Sapphire Network.

1. App Deployment: The agent (application logic) is deployed into the TEE container.
2. Key Generation: The enclave generates secp256k1, Ed25519, or entropy-based keys using the key generation endpoint.
3. Secure Storage: Keys remain securely inside the enclave. Even hardware compromise does not leak them.
4. Transaction Signing: When the app needs to send a transaction, it signs internally using the correct key.
5. Direct RPC Access: Signed transactions are submitted directly to blockchain RPC endpoints.

Demonstrative Example: Signing Transactions

Here’s a simplified example of how a ROFL-powered agent could sign and submit transactions:

# Pseudocode for demonstration purposes
from rofl_sdk import TEEWallet
from eth_account import Account
from solana.transaction import Transaction

# Create Ethereum wallet inside TEE
eth_wallet = TEEWallet(curve="secp256k1")
print("Ethereum Address:", eth_wallet.address())

# Create Solana wallet inside TEE
sol_wallet = TEEWallet(curve="ed25519")
print("Solana Address:", sol_wallet.address())

# Example Ethereum transaction
eth_tx = {
"to": "0xRecipientAddress",
"value": 1000000000000000, # in wei
"gas": 21000,
"nonce": 0,
}
signed_eth_tx = eth_wallet.sign_transaction(eth_tx)

# Example Solana transaction
sol_tx = Transaction()
sol_tx.add(
# instructions go here
)
signed_sol_tx = sol_wallet.sign_transaction(sol_tx)

# Submit via RPC
eth_wallet.send_transaction(signed_eth_tx, rpc_url="https://arb1.arbitrum.io/rpc")
sol_wallet.send_transaction(signed_sol_tx, rpc_url="https://api.mainnet-beta.solana.com")

Code Walkthrough:

• TEEWalet(curve=...): Initializes a new wallet inside the TEE for a given elliptic curve.
• sign_transaction(): Signs the transaction payload inside the enclave.
• send_transaction(): Submits the signed transaction directly to the chain RPC.
• The key_id ensures domain separation (e.g., agent-demo).
• We use the TEEWallet abstraction to create both Ethereum (secp256k1) and Solana (ed25519) wallets inside the enclave.
• Each wallet derives its key deterministically from the enclave, tied to key_id domain separation.
• Ethereum and Solana transactions are signed directly with enclave-controlled keys.
• Signed transactions can then be submitted to the respective RPC endpoints (e.g., Arbitrum for EVM, Solana mainnet RPC).

Why This Matters

ROFL’s TEE-based multichain wallet system provides several unique advantages:

• No Bridges Needed: Agents directly control native wallets on each chain.
• Deterministic Key Persistence: Keys are reproducible across deployments with the same key_id.
• Unified Codebase: Developers can use a single framework to interact with multiple blockchains.
• Verifiable Security: Users don’t need to trust developers with keys; they can trust cryptographic guarantees of the enclave.
• Lower Complexity: No need for separate key management infrastructure per chain.

This dramatically lowers development and operational overhead, especially for agent-based protocols.

Practical Use Cases

1. Agentic Treasury (Talos)

Talos leverages ROFL’s key generation to securely manage a multichain treasury. Instead of asking users to trust the developers with keys, Talos ensures keys are generated inside the TEE. This removes a huge trust assumption and makes treasury operations provably autonomous.

2. Autonomous Trading (zkAGI)

zkAGI encrypts API credentials within ROFL’s TEE. Beyond trading on Hyperliquid, it could also use multichain key generation to manage assets across Ethereum, Solana, and beyond, opening the door for more sophisticated trading strategies.

Limitations & Considerations

• RPC Dependency: Blockchains like Solana don’t support light clients, so apps must depend on external RPC providers.
• Bridges Still Needed for Transfers: To actually move assets between chains, bridges are still necessary. ROFL solves signing, not liquidity transfer.
• TEE Trust Model: While TEEs provide strong guarantees, their security ultimately depends on the underlying hardware vendor.

Getting Started with ROFL Key Generation

Developers can begin experimenting with ROFL’s wallet generation today. Key resources:

• ROFL Documentation: Key Generation
• Oasis Blog: Multichain Wallet Agents

If you’re building an agent that must interact with multiple chains, ROFL offers a clean, secure, and verifiable way to unify wallet control.

Conclusion

Multichain agents represent the next frontier of Web3. By embedding cryptographic key management into TEEs, ROFL enables developers to build applications that:

• Operate seamlessly across chains.
• Eliminate unnecessary trust assumptions.
• Offer verifiable guarantees to their users.

This marks a shift from “trust the team” to “trust the math and hardware”, a critical foundation for scaling the agent economy.

References

• Oasis Blog: Multichain Wallet Agents
• Oasis Docs: ROFL Key Generation