Add Server Wallets tutorial

Author: yashovardhan

src/pages/tutorials/designing-server-wallets.mdx

@@ -0,0 +1,102 @@
+---
+title: Designing Server Wallets for AI Agents with ERC 8004
+image: 'img/tutorials/tutorials-banners/designing-server-wallets.png'
+description: Designing Server Wallets for AI Agents with ERC 8004.
+tags: [AI agent, ERC 8004, server wallet, embedded wallets, ethereum, solana]
+date: October 28, 2025
+author: MetaMask Developer Relations
+---
+
+At MetaMask, we have specialized in creating fast and secure non custodial wallets in ethereum and now across the whole of the web3 ecosystem. With ERC‑8004 standardizing how AI agents express “what they intend to do,” we can see a clear need for a fast, safe, multi‑chain signing backend, more commonly known as a Server Wallet. The interesting thing about Server Wallets is that it will be a requirement for even non web2 native developers in the very near future. Hence, thinking about an ideal architecture around it becomes necessary.
+
+This guide outlines an opinionated, production‑oriented architecture you can adopt today and hints at where we’re going next with a one-click ERC‑8004 server wallet experience.
+
+## What are Server Wallets?
+
+A server wallet is a backend signer that holds and uses private keys on behalf of the app or AI Agent, while clients authenticate requests and receive signatures to submit on chain. The idea is that the signing key lives in a secure environment, so it is never exposed directly to the AI agent and is protected by certain policies set for its execution.
+
+## Reference architecture
+
+- The client holds an “Agent Key” used to authenticate who is asking to sign; separate from the on‑chain account key that actually controls funds.​
+- Backend exposes minimal APIs that forward requests into a Trusted Execution Environment (TEE, e.g., AWS Nitro Enclaves).​
+- TEE enclave is the only environment allowed to verify Agent Key, generate account keys, decrypt keys, apply policy, and produce signatures. It has no external networking and no persistent storage
+- The encrypted key and metadata live in a database outside the enclave, encrypted by the Agent Key.
+
+## Request flow
+
+- Client creates a request describing the action and signs it with the Agent Key to prove origin and integrity.
+- Backend passes the request into the enclave, which has no external networking, SSH or persistent storage to reduce exposure.
+- Enclave verifies the signature, checks policy, signs if allowed, and returns only the signature and decision metadata to the backend.
+
+## Core Security Operations
+
+### Key generation
+
+- The Client send a request with the Agent Key
+- The account keypair is created inside the enclave and encrypted using the Agent Key
+- The encrypted blob is then stored in a database alongside the public address of the Agent Key​
+
+### Importing Key
+
+- The agent has the Private Key on the client side.
+- The SDK encrypts the Private key with the Agent Key
+- The import API is called with the encrypted blob which stores it in the database alongside the public address of the Agent Key
+
+### Signing
+
+- The client authenticates a request with the Agent Key
+- The TEE validates, enforces policy and signs the request
+- Finally, it returns a signature without exposing key material.​
+
+### Export
+
+- The client sends an export request with the Agent Key
+- The TEE validates, enforces policy and signs the request
+- Finally, it returns the encrypted blog stored in the database, which the can be decrypted on the client side with the Agent Key.​
+
+### Rotation
+
+- A new Agent Key is generated on the client side.
+- It is authenticated with the existing Agent Key by the enclave, enforcing the policies.
+- The encrypted blob decrypted is re-encrypted using the new Agent Key and stored against the new public address of the Agent Key.
+
+### Some reference TEE Policies
+
+- Spend limits: cap value per transaction and per day.
+- Scope limits: allowlisted contracts, methods, and tokens.
+- Chain limits: allow only the networks you support.
+- Frequency limits: throttle bursts to reduce risk.
+- Simulation checks: sign only if a dry‑run looks safe.
+- Human approval: require a second click for unusual activity.
+
+## Some interesting architectural questions
+
+While finalising our version of the server wallets, we came across very valid and genuine questions, which needed to be answered. Some of these questions
+
+- Why use Trusted Execution Environments (TEEs)
+  - Currently MetaMask Embedded Wallet SDKs give access to the signer directly to the frontend/ backend environment where the operations need to happen.
+  - With a wallet secret present in the environment of execution, able to access the TEE operations, both are equally secure.
+  - However with TEE, we can add a policy engine, which can restrict certain operations.
+  - For a general user account, this is not much useful for most cases, however for an AI agent, the chance for AI hallucinating and performing weird things are much more. More than security we have to make sure this issue is resolved.
+- Why not TSS MPC
+  - The MPC Core Kit SDKs offered with MetaMask Embedded Wallets are a great option for this, however TSS signing speed becomes a bottleneck.
+  - Even with our DKLS19 solution it takes 4-5secs to sign with 5 nodes holding the key.
+  - We can reduce the number of nodes to do it and have it on a high quality server but still it cannot match the speed of single key signing
+  - MPC’s decentralization benefits are real, but for this product goal—fast server-side signing with tight policy and attestation—the latency and complexity tradeoffs are unnecessary
+- Why not Smart Accounts
+  - Smart accounts do and can resolve most of these issues, especially with 7715 permission, however they have their limitations.
+  - One of the biggest pain points is that they may not be able to work cross-chain and with non EVM networks like Solana.
+  - The operations to update policies will be significantly expensive as compared to a TEE policy engine.
+  - Performance will also be a bottleneck for different chains. General trading bots are also used for high frequency trading, which is where the issue lies.
+
+## How does this fit ERC‑8004?
+
+With ERC 8004 in action, every AI agent needs a signing identity that can register itself on‑chain and prove control of that identity when it interacts, so others can discover, trust, and audit the agent’s actions across ecosystems. In practice, this means pairing a signer with the ERC‑8004 identity registry entry and the agent’s off‑chain registration file so requests are attributable and verifiable end to end.
+
+Hence server wallets by default become an integral part of making AI agents with ERC 8004\.
+
+:::info Coming soon
+
+MetaMask Embedded Wallets is packaging this architecture into a one‑click server wallet experience so teams can go from idea to production with attestation, policy, and secure signing out of the box, with optional ERC‑8004 alignment for interop when you need it. Watch this space for early access details as we finalize SDKs, tutorials, and reference deployments.
+
+:::