@desplega.ai/agent-swarm 1.20.0 → 1.49.0

package/thoughts/research/2026-02-28-openfort-viem-x402-research.md

@@ -0,0 +1,679 @@
+---
+date: 2026-02-28T10:25:00Z
+researcher: Researcher
+git_commit: n/a
+branch: n/a
+repository: desplega-ai/agent-swarm
+topic: "Openfort viem integration as a robust alternative for x402 payments in agent-swarm"
+tags: [research, x402, openfort, viem, payments, eip-3009, managed-wallets]
+status: complete
+autonomy: autopilot
+last_updated: 2026-02-28T11:25:00Z
+last_updated_by: Researcher (transaction testing update)
+---
+
+# Research: Openfort Viem Integration as a Robust Alternative for x402 Payments
+
+**Date**: 2026-02-28
+**Researcher**: Researcher (agent-swarm worker)
+**Context**: PR #108 adds x402 payment capability; feedback that current approach is "too yolo"
+
+## Research Question
+
+Can Openfort's viem integration replace the raw `EVM_PRIVATE_KEY` approach in PR #108 for x402 payments, and is it a production-ready improvement?
+
+## Summary
+
+**Yes, Openfort's backend wallets are technically compatible with the x402 payment flow.** The x402 SDK's `ClientEvmSigner` interface only requires `address` and `signTypedData` — Openfort's backend wallet provides both. The integration would require ~20 lines of adapter code. However, the trade-off is not straightforward: Openfort adds managed key custody and eliminates raw private keys in env vars, but introduces API latency (~125ms per sign), a vendor dependency on a small startup (7 employees, $3M raised, 658 weekly npm downloads), and per-operation costs.
+
+**Recommendation: Implement a provider-agnostic signer abstraction** in `src/x402/` that supports both raw viem accounts (current) and Openfort accounts (new option). This avoids vendor lock-in while giving operators the choice of managed key infrastructure. The current approach should remain as the default for simplicity; Openfort becomes an opt-in upgrade for production deployments that need managed custody.
+
+## Detailed Findings
+
+### 1. What is Openfort?
+
+Openfort is a wallet-as-a-service platform providing embedded wallets, backend wallets, account abstraction (ERC-4337/EIP-7702), gas sponsorship, and key management. They position themselves as "Money Movement Infrastructure for AI Agents & Stablecoins."
+
+**Company facts:**
+- Founded 2022, CEO Joan Alavedra
+- ~7 employees, $3M raised (Seed, May 2023)
+- Originally gaming-focused, pivoting to AI agents and stablecoins
+- Open-source key management (OpenSigner) using Shamir Secret Sharing (2-of-3 threshold)
+- SOC2 Type II claimed (unverified), Quantstamp audit in progress for OpenSigner
+
+**Key products relevant to our use case:**
+| Product | Description |
+|---------|-------------|
+| Backend Wallets | Server-side EOA wallets, keys secured in Google Cloud TEE. Up to 500 write TPS claimed. |
+| OpenSigner | Open-source, self-hostable key management using Shamir Secret Sharing |
+| Gas Sponsorship | Native ERC-4337 paymaster (not needed for x402 — the facilitator pays gas) |
+| Session Keys | Scoped, time-limited signing permissions (potential future feature for agents) |
+
+**Pricing:**
+| Plan | Monthly | Included Ops | Overage |
+|------|---------|-------------|---------|
+| Free | $0 | 2,000 | $0.01/op |
+| Growth | $99 | 25,000 | $0.008/op |
+| Pro | $249 | 100,000 | $0.006/op |
+| Scale | $599 | 500,000 | $0.004/op |
+
+For our use case (agents making x402 payments), each payment requires one `signTypedData` API call = 1 operation. At the Free tier, that is 2,000 payments/month before charges. At Growth ($99/mo), 25,000 payments/month.
+
+**Supported chains:** 25+ EVM chains (Ethereum, Base, Polygon, Arbitrum, etc.) + Solana.
+
+### 2. How the Openfort Viem Integration Works
+
+The `@openfort/openfort-node` SDK (v0.9.1) provides a `toEvmAccount()` internal factory that creates an account object with viem-compatible signing methods.
+
+**Architecture:**
+```
+@openfort/openfort-node
+  └── src/wallets/evm/
+        ├── accounts/evmAccount.ts   ← toEvmAccount() factory
+        ├── actions/                  ← signHash, signMessage, signTransaction, signTypedData
+        ├── evmClient.ts             ← EvmClient class
+        └── types.ts                 ← Uses viem types (Address, Hex, etc.)
+```
+
+**How it works:**
+1. You instantiate the SDK with an API key + wallet secret
+2. `openfort.accounts.evm.backend.create()` creates a backend wallet (EOA secured in TEE)
+3. The returned account object has `signMessage()`, `signTypedData()`, `signTransaction()`, `sign()`
+4. Each signing operation makes an HTTP API call to Openfort's backend — the private key never leaves the TEE
+
+**The account is NOT a native viem `LocalAccount`** — it has the same method signatures but different TypeScript types (`id`, `custody` fields). To use with viem's `WalletClient`, you wrap it via `toAccount()`:
+
+```typescript
+import { toAccount } from "viem/accounts";
+
+const openfortAccount = await openfort.accounts.evm.backend.create();
+const viemAccount = toAccount({
+  address: openfortAccount.address,
+  async signMessage({ message }) { return openfortAccount.signMessage({ message }); },
+  async signTransaction(tx) { return openfortAccount.signTransaction(tx); },
+  async signTypedData(data) { return openfortAccount.signTypedData(data); },
+});
+```
+
+**Signing flow per operation:**
+| Operation | Client-side (viem utils) | API call | Latency |
+|-----------|-------------------------|----------|---------|
+| `signMessage` | EIP-191 prefix via `toPrefixedMessage()` | Backend hashes + signs | ~125ms |
+| `signTypedData` | Hash via `hashTypedData()` | Backend signs hash | ~125ms |
+| `signTransaction` | Serialize via `serializeTransaction()` | Backend signs serialized tx | ~125ms |
+
+### 3. Current x402 Implementation (PR #108)
+
+PR #108 adds x402 payment capability with this architecture:
+
+```
+src/x402/
+  ├── index.ts              ← Public API
+  ├── client.ts             ← Core: privateKeyToAccount + x402 SDK wiring
+  ├── config.ts             ← Env var loading (EVM_PRIVATE_KEY, limits)
+  ├── spending-tracker.ts   ← In-memory 24hr spending limits
+  └── cli.ts                ← Testing CLI
+```
+
+**The "yolo" part — wallet creation in `client.ts`:**
+```typescript
+const account = privateKeyToAccount(config.evmPrivateKey);  // Raw key from env
+const publicClient = createPublicClient({ chain, transport: http() });
+const signer = toClientEvmSigner(account, publicClient);    // x402 signer adapter
+```
+
+**Payment flow:**
+1. Agent calls `paidFetch(url)` (wrapped `fetch`)
+2. If server returns HTTP 402 with `PAYMENT-REQUIRED` header → x402 SDK intercepts
+3. SDK constructs EIP-712 typed data for `TransferWithAuthorization` (EIP-3009)
+4. `signer.signTypedData(...)` signs off-chain (gasless for the agent)
+5. Signature sent in `PAYMENT-SIGNATURE` header on retry
+6. Facilitator submits on-chain, moves USDC, returns content
+
+**Required env vars:**
+| Variable | Required | Default | Purpose |
+|----------|----------|---------|---------|
+| `EVM_PRIVATE_KEY` | Yes | — | Raw private key (0x-prefixed hex) |
+| `X402_MAX_AUTO_APPROVE` | No | 1.00 | Max USD per request |
+| `X402_DAILY_LIMIT` | No | 10.00 | Max USD per UTC day |
+| `X402_NETWORK` | No | Base Sepolia | CAIP-2 network ID |
+
+### 4. Can Openfort Replace the Current Signer?
+
+**Yes.** The x402 SDK's `ClientEvmSigner` interface is minimal:
+
+```typescript
+interface ClientEvmSigner {
+  address: `0x${string}`;
+  signTypedData: (message: {
+    domain: { ... };
+    types: Record<string, Array<{ name: string; type: string }>>;
+    primaryType: string;
+    message: Record<string, unknown>;
+  }) => Promise<`0x${string}`>;
+}
+```
+
+It does NOT require a `LocalAccount`, a private key, `signMessage`, or `signTransaction`. Any object with `address` + `signTypedData` works.
+
+**Openfort adapter code (complete):**
+```typescript
+import Openfort from "@openfort/openfort-node";
+import type { ClientEvmSigner } from "@x402/evm";
+
+const openfort = new Openfort(process.env.OPENFORT_API_KEY!, {
+  walletSecret: process.env.OPENFORT_WALLET_SECRET,
+});
+
+const account = await openfort.accounts.evm.backend.create();
+
+const signer: ClientEvmSigner = {
+  address: account.address,
+  signTypedData: async (message) => {
+    return account.signTypedData({
+      domain: message.domain,
+      types: message.types,
+      primaryType: message.primaryType,
+      message: message.message,
+    });
+  },
+};
+```
+
+### 5. EIP-3009 Compatibility — Critical Analysis
+
+EIP-3009 (`transferWithAuthorization`) requires:
+1. An **EIP-712 typed data signature** — Openfort supports this via `signTypedData()`
+2. A **standard ECDSA signature** verified by `ecrecover` on-chain — Openfort's backend wallets are EOAs that produce standard ECDSA signatures
+3. The **signer's address must hold the USDC tokens** — must fund the EOA address from `account.address`
+
+**Compatibility verdict: COMPATIBLE.** Openfort's backend wallet is an EOA that produces ECDSA signatures. The `signTypedData` method has the right interface. EIP-3009's `ecrecover` will accept the signature.
+
+**One critical caveat:** Openfort also pairs accounts with ERC-4337 smart accounts. For x402, you MUST use the EOA address (from `account.address`) and fund USDC there — NOT any paired smart account address. Smart contract signatures (EIP-1271) are NOT compatible with EIP-3009.
+
+### 6. What Changes Are Needed in `src/x402/`
+
+The changes would be minimal if we adopt a provider-agnostic approach:
+
+**Option A — Minimal (add Openfort as alternative signer):**
+```
+src/x402/
+  ├── config.ts        ← Add OPENFORT_API_KEY, OPENFORT_WALLET_SECRET, X402_SIGNER_TYPE
+  ├── client.ts        ← Add createOpenfortSigner() alongside existing createViemSigner()
+  └── (rest unchanged)
+```
+
+Modify `client.ts` to select signer based on config:
+```typescript
+async function createSigner(config: X402Config): Promise<ClientEvmSigner> {
+  if (config.signerType === 'openfort') {
+    return createOpenfortSigner(config);
+  }
+  // Default: current raw key approach
+  return createViemSigner(config);
+}
+```
+
+**New env vars:**
+| Variable | Required | Default | Purpose |
+|----------|----------|---------|---------|
+| `X402_SIGNER_TYPE` | No | `viem` | `viem` or `openfort` |
+| `OPENFORT_API_KEY` | If openfort | — | Openfort API key (sk_test_/sk_live_) |
+| `OPENFORT_WALLET_SECRET` | If openfort | — | Openfort wallet encryption secret |
+
+**Estimated effort:** ~50-80 lines of new code in `client.ts`, ~20 lines in `config.ts`, tests.
+
+**Option B — Openfort-only (replace viem signer entirely):**
+Not recommended. This would make Openfort a hard dependency, add latency to all payments, and remove the simple local-key option for development.
+
+### 7. Security Comparison
+
+| Dimension | Current ("yolo") | Openfort |
+|-----------|-----------------|----------|
+| **Key storage** | Raw hex in `EVM_PRIVATE_KEY` env var | TEE-secured on Google Cloud, never exposed |
+| **Key exposure risk** | Env var leak = full wallet compromise | API key leak = can create wallets but not access existing keys without wallet secret |
+| **Key rotation** | Manual — change env var, update address | API call — rotate keys without changing address (with smart accounts) |
+| **Blast radius of compromise** | Immediate full access to all funds | Requires both API key AND wallet secret; Openfort can freeze accounts |
+| **Audit trail** | None — local signing is invisible | Full API audit log of every signing operation |
+| **Compliance** | None | SOC2 Type II (claimed), audit logs |
+| **Multi-agent isolation** | Same key shared across all agents | Each agent can have its own backend wallet with separate permissions |
+| **Recovery** | Lose key = lose funds | 2-of-3 Shamir recovery via OpenSigner |
+
+**The security upgrade is real but not transformational.** The biggest win is eliminating raw private keys from env vars — a genuine operational security improvement. The managed audit trail and per-agent wallet isolation are nice-to-haves. But the keys are still ultimately held by a third-party service (Openfort), so it shifts trust rather than eliminating it.
+
+### 8. Limitations and Trade-offs
+
+**Concerns:**
+
+| Concern | Severity | Detail |
+|---------|----------|--------|
+| **Company risk** | High | 7 employees, $3M raised. Competitors (Privy, Dynamic, Web3Auth, Sequence) have all been acquired. Openfort's independence is uncertain. |
+| **Low adoption** | High | 658 weekly npm downloads on Node SDK. 8 GitHub stars. Very few external users. |
+| **Pre-1.0 SDK** | Medium | Version 0.6.74 — API surface may change without semver guarantees |
+| **Signing latency** | Medium | ~125ms per API call vs <1ms local. Adds latency to every x402 payment. |
+| **Cost** | Low | Free tier covers 2,000 ops/month. Growth at $99/mo covers 25,000. Unlikely to be a budget issue. |
+| **Vendor lock-in** | Medium | Wallets are Openfort-managed — migrating away requires exporting keys or creating new wallets |
+| **Package size** | Low | 3.21 MB (bundled OpenAPI specs). Bloated but functional. |
+| **No 1.0 stability guarantee** | Medium | Breaking changes possible between 0.x versions |
+
+**Mitigating factors:**
+- OpenSigner is open-source and self-hostable — reduces lock-in risk
+- The provider-agnostic signer approach (Option A) means we can swap Openfort out without changing the x402 flow
+- Openfort is actively maintained (multiple commits per day as of Feb 2026)
+
+### 9. Alternatives Considered
+
+| Alternative | Pros | Cons |
+|-------------|------|------|
+| **Keep raw viem (current)** | Simplest, fastest, zero vendor dependency | Raw private key in env, no audit trail, "yolo" |
+| **Openfort backend wallet** | Managed keys, audit trail, per-agent isolation | Vendor risk, latency, cost |
+| **Coinbase CDP MPC wallet** | Backed by Coinbase (ecosystem alignment with x402) | More complex setup, heavier dependency |
+| **Turnkey** | TEE-based (strong security), backed by Sequoia | Low-level primitives, harder to integrate, no free tier |
+| **Fireblocks** | Enterprise-grade, 150+ chains | Expensive, overkill for our use case |
+| **Vault + local signer** | Keep local signing but store key in HashiCorp Vault / AWS KMS | Same speed as current, better key management, no vendor lock-in | Key still decrypted in memory |
+
+## Recommendation
+
+### Short-term (PR #108): Ship as-is with the raw viem signer
+
+The current implementation in PR #108 is functional and well-guarded (spending limits, safe config pattern, testnet default). For an MVP/initial release, it works. The "yolo" concern is about raw private keys in env vars — which is a standard practice for dev/test and acceptable for early production with small balances.
+
+### Medium-term: Implement provider-agnostic signer abstraction
+
+Add a `SignerProvider` interface to `src/x402/` that abstracts over the signing backend:
+
+```typescript
+interface SignerProvider {
+  type: string;
+  createSigner(): Promise<ClientEvmSigner>;
+  getWalletAddress(): Promise<`0x${string}`>;
+}
+```
+
+Implement two providers:
+1. `ViemSignerProvider` — current approach (default)
+2. `OpenfortSignerProvider` — opt-in via `X402_SIGNER_TYPE=openfort`
+
+This keeps the simple path simple while allowing production deployments to upgrade to managed keys.
+
+### Long-term: Evaluate based on Openfort's trajectory
+
+Openfort is a small, early-stage startup in a consolidating market. Before making it a primary dependency:
+- Monitor their adoption (npm downloads, GitHub activity)
+- Watch for acquisition or shutdown signals
+- Consider Coinbase CDP as the ecosystem-aligned alternative (same company behind x402)
+
+## Code References
+
+| File | Description |
+|------|-------------|
+| `src/x402/client.ts` (PR #108) | Core payment client — where the signer is created |
+| `src/x402/config.ts` (PR #108) | Config loading — where new env vars would be added |
+| `src/x402/spending-tracker.ts` (PR #108) | Spending limits — unchanged by signer swap |
+| `@x402/evm` (npm) | `ClientEvmSigner` interface and `toClientEvmSigner` helper |
+| `@openfort/openfort-node` (npm) | Openfort Node SDK with `accounts.evm.backend.create()` |
+
+## Historical Context
+
+- Previous x402 research: `/workspace/shared/thoughts/16990304-76e4-4017-b991-f3e37b34cf73/research/2026-02-28-x402-payments-protocol.md`
+- x402 uses EIP-3009 (gasless USDC transfers via EIP-712 typed data signatures)
+- The x402 SDK is intentionally wallet-agnostic — any object with `address` + `signTypedData` works
+
+## Open Questions
+
+- **Wallet persistence:** Does `openfort.accounts.evm.backend.create()` create a new wallet each time, or can you retrieve an existing one by ID? For agent-swarm, we need the same wallet address across restarts.
+- **Coinbase CDP alternative:** Should we also evaluate Coinbase's own MPC wallet as a signer? It would be more ecosystem-aligned with x402.
+- **Multi-agent wallets:** Should each agent have its own wallet (better isolation) or share one (simpler treasury management)?
+- **Key export:** Openfort supports private key export — should we document this as an escape hatch?
+
+## Hands-on Testing Results
+
+**Date**: 2026-02-28
+**Tested by**: Researcher (agent-swarm worker)
+**SDK Version**: \`@openfort/openfort-node\` v0.9.1
+**API Key Type**: Test (\`sk_test_...\`)
+**Environment**: Node.js v22.22.0
+
+### Setup
+
+Two secrets were configured in the swarm's global config:
+- \`OPENFORT_TEST_SECRET_KEY\` — Test API secret key (\`sk_test_...\`)
+- \`OPENFORT_TEST_WALLET_PRIVATE_KEY\` — ECDSA P-256 private key in base64-encoded DER format
+
+**Key discovery:** The \`walletSecret\` parameter in the SDK constructor is NOT a simple string or hex key — it's a **P-256 (ES256) ECDSA private key in PKCS#8 DER format, base64-encoded**. The SDK uses it to generate JWT tokens (with \`ES256\` algorithm) that are sent as the \`X-Wallet-Auth\` HTTP header on backend wallet API calls. This provides request-level authentication: each JWT includes the request method, path, and a hash of the request body.
+
+### Test Results Summary
+
+**17 tests executed, 16 passed, 1 expected failure** (error handling test).
+
+| # | Test | Result | Duration | Notes |
+|---|------|--------|----------|-------|
+| 1 | SDK Initialization | PASS | 1ms | Instantaneous, no API call |
+| 2 | List Existing Wallets | PASS | 257ms | First API call (cold start) |
+| 3 | Create Backend Wallet | PASS | 696ms | First wallet creation (cold start) |
+| 4 | Get Wallet by ID | PASS | 101ms | Fast lookup |
+| 5 | Get Wallet by Address | PASS | 110ms | Uses list API internally |
+| 6 | Create Second Wallet | PASS | 222ms | Subsequent creates are faster |
+| 7 | Sign Message | PASS | 251ms | Includes get + sign (two API calls) |
+| 8 | **Sign EIP-712 Typed Data** | **PASS** | **251ms** | **x402 critical path — works** |
+| 9 | Sign Raw Hash | PASS | 247ms | Includes get + sign |
+| 10 | signMessage Latency (5x) | PASS | 799ms total | **Avg 140ms** (128-145ms range) |
+| 11 | signTypedData Latency (5x) | PASS | 742ms total | **Avg 130ms** (120-143ms range) |
+| 12 | Export Private Key | PASS | 245ms | Returns 64-char hex (32 bytes) |
+| 13 | List All Wallets | PASS | 101ms | Pagination works |
+| 14 | Delete Wallet | PASS | 122ms | Clean deletion |
+| 15 | V2 Accounts API | PASS | 121ms | Alternative list endpoint |
+| 16 | Error: Bad Wallet ID | FAIL (expected) | 77ms | Clear error message |
+| 17 | Wallet Persistence | PASS | 411ms | Create → Get → Same address |
+
+### x402 Compatibility: Verified
+
+**This is the most important finding.** The Openfort backend wallet signature was **verified** using viem's \`verifyTypedData()\` (which internally uses \`ecrecover\`). This proves:
+
+1. Openfort backend wallets produce **standard ECDSA signatures** (not EIP-1271 smart contract signatures)
+2. The signatures are **65 bytes** (r + s + v), as expected by EIP-3009
+3. The \`signTypedData()\` method correctly handles EIP-712 structured data
+4. A minimal \`ClientEvmSigner\` wrapper works perfectly with the x402 interface:
+
+\`\`\`typescript
+const clientEvmSigner: ClientEvmSigner = {
+  address: account.address,
+  signTypedData: async (msg) => {
+    return account.signTypedData({
+      domain: msg.domain,
+      types: msg.types,
+      primaryType: msg.primaryType,
+      message: msg.message,
+    });
+  },
+};
+\`\`\`
+
+**Verification output:**
+\`\`\`
+Signature: 0xbaf71652df562e10...efd7eb68e01
+Verifying with viem (ecrecover)... ✓ VALID
+ClientEvmSigner wrapper... ✓ VALID
+\`\`\`
+
+### Wallet Secret Deep Dive
+
+The SDK's wallet authentication mechanism is more sophisticated than documented:
+
+1. The \`walletSecret\` is a **PKCS#8-encoded ECDSA P-256 private key** (base64 of the DER bytes)
+2. On every backend wallet mutation (POST/PUT/DELETE to \`/accounts/backend/*\`), the SDK:
+   - Generates a JWT with \`ES256\` algorithm
+   - Claims include: \`uri\` (method + path), \`iat\`, \`nbf\`, \`jti\` (nonce), and \`reqHash\` (SHA-256 of sorted request body)
+   - Signs it with the wallet secret key
+   - Attaches it as \`X-Wallet-Auth\` header
+3. This means **each API request is individually authenticated** — stealing the API key alone is insufficient to perform wallet operations
+4. The wallet secret can be generated by the Openfort dashboard or via their CLI
+
+### Wallet Persistence: Confirmed
+
+**Critical question answered:** Wallets persist indefinitely. \`create()\` always generates a new wallet; you retrieve existing ones via \`get({ id })\` or \`get({ address })\` or \`list()\`. For the agent-swarm use case, the workflow would be:
+
+\`\`\`typescript
+// On agent startup:
+const wallets = await openfort.accounts.evm.backend.list({ limit: 1 });
+const account = wallets.accounts.length > 0
+  ? wallets.accounts[0]
+  : await openfort.accounts.evm.backend.create();
+\`\`\`
+
+Or better, store the wallet ID in agent config and use \`get({ id })\` directly.
+
+### Latency Analysis
+
+| Operation | Avg Latency | Notes |
+|-----------|------------|-------|
+| \`signMessage\` | **140ms** | 128-145ms range, very consistent |
+| \`signTypedData\` | **130ms** | 120-143ms range — the x402 path |
+| \`create\` wallet | **222-696ms** | First call is cold (~700ms), subsequent ~220ms |
+| \`get\` wallet | **101-110ms** | Fast retrieval |
+| \`list\` wallets | **101ms** | Pagination supported |
+| \`delete\` wallet | **122ms** | Clean cleanup |
+| \`export\` key | **245ms** | RSA encrypt/decrypt overhead |
+
+**For x402 payments:** A single \`signTypedData\` call adds ~130ms to each payment. The x402 flow already involves HTTP requests to the facilitator, so this is negligible in practice. Total payment flow: agent → x402 SDK → signTypedData (130ms) → facilitator → blockchain.
+
+### Private Key Export
+
+The SDK supports exporting the raw private key from a backend wallet:
+- Returned as a **64-character hex string** (32 bytes, no \`0x\` prefix)
+- Uses RSA-OAEP encryption for transport: SDK generates ephemeral RSA key pair, sends public key to Openfort, Openfort encrypts the private key, SDK decrypts locally
+- This serves as an **escape hatch** if you need to migrate away from Openfort
+
+### Cost Implications
+
+With 17 tests executed, each involving 1-6 API calls, we consumed ~35-40 operations. The free tier allows 2,000 operations/month. For the agent-swarm:
+- Each x402 payment = **1 signTypedData call** = 1 operation
+- Agent startup = **1 list or get call** = 1 operation
+- At the free tier: **~2,000 payments/month** before charges
+- At Growth (\$99/mo): **~25,000 payments/month**
+
+### SDK Quirks & Observations
+
+1. **No \`0x\` prefix on exported keys:** The \`export()\` method returns a bare hex string without \`0x\` prefix. When importing or using with viem, you need to add \`0x\` yourself.
+
+2. **\`get()\` by address uses list internally:** The SDK calls \`listBackendWallets({ address, limit: 1 })\` rather than a dedicated endpoint. This is fine but means address lookups are slightly slower than ID lookups.
+
+3. **\`walletSecret\` is required for all mutations:** Without it, any POST/PUT/DELETE to backend wallet endpoints throws \`MissingWalletSecretError\`. Read-only operations (list, get) work without it.
+
+4. **Error messages are clear:** Invalid wallet IDs return descriptive errors like "Request has invalid parameters. Invalid acc: 'acc_nonexistent_12345'."
+
+5. **BigInt support works:** The SDK handles \`BigInt\` values in EIP-712 typed data correctly (via viem's \`hashTypedData\`).
+
+6. **No rate limiting observed:** 17 tests with ~40 API calls in rapid succession — no throttling or 429 responses.
+
+7. **SDK uses global Axios instance:** The \`configure()\` function sets up module-level configuration. This means you cannot have two Openfort instances with different API keys in the same process. Not a problem for our use case (one agent = one key).
+
+### Updated Recommendation
+
+Based on hands-on testing, I **strengthen the recommendation** for Openfort integration:
+
+1. **The integration works exactly as designed.** Zero surprises. The \`ClientEvmSigner\` adapter is 7 lines of code.
+2. **Latency is acceptable.** 130ms for signTypedData is negligible in the context of HTTP-based x402 payments.
+3. **Wallet persistence is confirmed.** Agents can reliably retrieve the same wallet across restarts.
+4. **The security model is solid.** Per-request JWT authentication with the wallet secret key means the API key alone cannot sign transactions.
+5. **Private key export provides an escape hatch.** No vendor lock-in risk.
+
+**Revised implementation plan:**
+- Use Openfort as the **default** signer (not opt-in), with raw viem as the fallback for development/testing
+- Store wallet ID in per-agent config (via swarm config system)
+- Add \`OPENFORT_API_KEY\` and \`OPENFORT_WALLET_SECRET\` to the swarm's env vars
+- Use \`X402_SIGNER_TYPE=viem\` as the escape hatch (not the default)
+
+
+## Transaction Creation Testing Results
+
+**Date**: 2026-02-28
+**Tested by**: Researcher (agent-swarm worker)
+**SDK Version**: \`@openfort/openfort-node\` v0.9.1
+**Chain**: Base Sepolia (chainId: 84532)
+
+### Overview
+
+Taras requested testing of actual transaction creation via Openfort. The SDK provides **two distinct mechanisms**:
+
+1. **\`account.signTransaction()\`** — Signs a raw transaction (EIP-1559 or legacy) but does NOT broadcast. The caller must broadcast via a JSON-RPC provider (e.g., viem's \`sendRawTransaction\`).
+2. **\`transactionIntents.create()\`** — Openfort's high-level API that handles account abstraction (ERC-4337), gas sponsorship, bundling, and broadcasting. Requires a Player + smart account.
+
+**There is no \`sendTransaction()\` method in the SDK.**
+
+### Test Results
+
+| # | Test | Result | Duration | Notes |
+|---|------|--------|----------|-------|
+| 1a | Sign EIP-1559 Tx (self-transfer) | PASS | 703ms | Signed successfully, ready to broadcast |
+| 1b | Broadcast Self-Transfer | SKIP | — | Wallet has 0 ETH for gas |
+| 2a | Create Player | PASS | 109ms | Players are Openfort's user model |
+| 2b | Create Policy + Fee Sponsorship | PASS | 189ms | Gas sponsorship setup |
+| 2c | Create Sponsored Transaction Intent | PASS | 1280ms | ERC-4337 v6, returns \`nextAction: sign_with_wallet\` |
+| 2d | Sign UserOperation Hash | PASS | 170ms | Backend wallet signs the UserOp hash |
+| 2e | Submit Signature | PASS | 1108ms | Signature accepted by Openfort |
+| 2f | Final Transaction State | PASS | 5186ms | Status 0, tx accepted but not confirmed on-chain |
+| 3 | List Transaction Intents | PASS | 4371ms | All intents listed correctly |
+
+**8/9 passed, 1 skipped** (no ETH for gas on the EOA).
+
+### Flow 1: signTransaction (Direct EOA)
+
+This is the simpler approach — sign a standard Ethereum transaction and broadcast it yourself.
+
+\`\`\`typescript
+// Sign an EIP-1559 transaction
+const tx = {
+  to: recipientAddress,
+  value: 0n,
+  nonce,
+  gas: 21000n,
+  maxFeePerGas: baseFee * 2n,
+  maxPriorityFeePerGas: 1000000n,
+  chainId: 84532,
+  type: "eip1559",
+};
+
+const signedTx = await account.signTransaction(tx);
+// signedTx is a fully serialized signed transaction hex (0x-prefixed)
+
+// Broadcast via viem
+const txHash = await publicClient.sendRawTransaction({ serializedTransaction: signedTx });
+const receipt = await publicClient.waitForTransactionReceipt({ hash: txHash });
+\`\`\`
+
+**What works:**
+- EIP-1559 (Type 2) transactions: sign perfectly ✓
+- Contract calldata: sign perfectly ✓ (tested with ERC-20 \`transfer\` calldata)
+- Signed transaction is standard RLP-encoded — compatible with any JSON-RPC provider
+
+**What doesn't work:**
+- Legacy transactions with mixed \`number\`/\`BigInt\` nonce from viem's \`getTransactionCount()\` — throws "Cannot mix BigInt and other types". **Workaround:** Use EIP-1559 transactions (always use BigInt for all numeric fields) or explicitly convert nonce to \`BigInt(nonce)\`.
+
+**Latency:** ~200-400ms per signTransaction call (includes Openfort API signing + viem serialization).
+
+**Limitation:** Requires ETH in the wallet for gas. For testnet, you'd need to use a faucet to fund the wallet. For mainnet, you'd need to transfer ETH to the wallet address.
+
+### Flow 2: transactionIntents (Smart Account + Gas Sponsorship)
+
+This is Openfort's managed transaction pipeline — uses ERC-4337 account abstraction.
+
+**Prerequisites:**
+1. Create a **Player** (\`openfort.players.create()\`)
+2. Create a **Policy** with gas sponsorship rules (\`openfort.policies.create()\`)
+3. Create a **Fee Sponsorship** linking to the policy (\`openfort.feeSponsorship.create()\`)
+
+**Full flow:**
+\`\`\`typescript
+// 1. Create player (auto-creates smart account on first tx)
+const player = await openfort.players.create({ name: "my-agent" });
+
+// 2. Create policy + sponsorship (one-time setup)
+const policy = await openfort.policies.create({
+  scope: "project",
+  rules: [{ action: "accept", operation: "sponsorEvmTransaction",
+            criteria: [{ type: "evmNetwork", operator: "in", chainIds: [84532] }] }],
+});
+const sponsorship = await openfort.feeSponsorship.create({
+  name: "agent-gas-sponsor",
+  strategy: { sponsorSchema: "pay_for_user" },
+  policyId: policy.id,
+});
+
+// 3. Create transaction intent
+const txIntent = await openfort.transactionIntents.create({
+  chainId: 84532,
+  player: player.id,
+  externalOwnerAddress: backendWallet.address,  // backend wallet as owner
+  policy: sponsorship.id,
+  interactions: [{ to: "0x...", value: "0" }],
+});
+
+// 4. If nextAction.type === "sign_with_wallet", sign the UserOp hash
+if (txIntent.nextAction?.payload?.userOperationHash) {
+  const signature = await backendWallet.sign({
+    hash: txIntent.nextAction.payload.userOperationHash,
+  });
+  
+  // 5. Submit signature
+  const result = await openfort.transactionIntents.signature(txIntent.id, {
+    signature,
+    optimistic: true,
+  });
+}
+\`\`\`
+
+**What works:**
+- Player creation ✓
+- Policy + Fee Sponsorship creation ✓
+- Transaction intent creation with \`abstractionType: "accountAbstractionV6"\` ✓
+- Returns \`nextAction: sign_with_wallet\` with \`userOperationHash\` ✓
+- Backend wallet signs the UserOp hash ✓
+- Signature submission accepted ✓
+
+**What didn't fully work:**
+- The transaction stayed at status 0 with no on-chain transaction hash. This likely means:
+  - The Openfort paymaster on Base Sepolia testnet may not be funded
+  - Or the 0-value transfer to \`address(1)\` may not pass paymaster validation
+  - The UserOp was accepted by Openfort but may have been rejected by the bundler
+
+**Critical finding: Backend wallets (EOAs) cannot directly use transactionIntents.** The API returns "Account type not supported" when you pass a backend wallet ID. You MUST create a Player, which auto-creates a smart account. The backend wallet serves as the **owner** of the smart account (via \`externalOwnerAddress\`).
+
+### Flow 3: What's NOT relevant for x402
+
+**For x402 payments, we don't need transactionIntents at all.** The x402 protocol uses EIP-3009 \`transferWithAuthorization\` — a gasless off-chain signature. The agent just signs EIP-712 typed data using \`signTypedData()\`, and the x402 facilitator handles the on-chain transaction. The agent never submits a transaction.
+
+\`signTypedData()\` was already verified in the previous testing round (130ms avg, ecrecover-compatible).
+
+### SDK Architecture: Two Transaction Paths
+
+| Feature | \`signTransaction()\` | \`transactionIntents\` |
+|---------|---------------------|----------------------|
+| **What it does** | Signs a raw tx, returns signed hex | Full lifecycle: bundle, sponsor, broadcast |
+| **Account type** | Backend wallet (EOA) ✓ | Smart account (Player) only |
+| **Gas** | Caller pays (needs ETH) | Can be sponsored (Openfort paymaster) |
+| **Broadcasting** | Caller broadcasts via JSON-RPC | Openfort handles via bundler |
+| **Abstraction** | None (standard EVM tx) | ERC-4337 v6 |
+| **Use for x402** | Not needed | Not needed |
+| **Use for funding** | Yes (sign + broadcast) | Possible but complex |
+
+### API Quirks Discovered
+
+1. **\`policies.delete()\` doesn't work with \`ply_\` IDs:** The create API returns IDs like \`ply_...\` but delete seems to expect a different format. Deleting via the fee sponsorship works fine though.
+
+2. **\`transactionIntents.list()\` is slow:** ~4 seconds. This seems to be a backend issue rather than pagination.
+
+3. **EIP-7702 not available on Base Sepolia:** Attempting to upgrade a backend wallet to a "Delegated Account" with \`implementationType: "EIP7702"\` fails with "not available in chainId '84532'".
+
+4. **Contract registration without ABI works:** You can register a contract address without providing an ABI. However, if you then try to use raw \`data\` in an interaction with that contract, Openfort tries to parse it against the (empty) ABI and fails.
+
+5. **Legacy tx BigInt issue:** viem's \`getTransactionCount()\` returns a \`number\`, but \`getGasPrice()\` returns a \`BigInt\`. Mixing them in a legacy transaction object causes "Cannot mix BigInt and other types". EIP-1559 transactions avoid this because all fields accept BigInt natively.
+
+### Relevance to x402 Implementation
+
+**Bottom line for PR #108:**
+- **\`signTypedData()\` is all we need for x402 payments** (already verified, 130ms latency)
+- \`signTransaction()\` is available as a bonus for agents that need to send ETH or interact with contracts directly
+- \`transactionIntents\` is the advanced path for gas-sponsored smart account operations — not needed for x402 but could be useful for future agent capabilities
+
+**The recommendation stands:** Openfort backend wallets are fully compatible with x402. The \`ClientEvmSigner\` adapter remains 7 lines of code.
+
+
+## Sources
+
+- [Openfort Homepage](https://www.openfort.io/)
+- [Openfort Pricing](https://www.openfort.io/pricing)
+- [Openfort Viem Integration Docs](https://www.openfort.io/docs/products/server/viem-integration)
+- [Openfort Backend Wallets Blog](https://www.openfort.io/blog/backend-wallets)
+- [Openfort Node SDK (GitHub)](https://github.com/openfort-xyz/openfort-node)
+- [@openfort/openfort-node (npm)](https://www.npmjs.com/package/@openfort/openfort-node)
+- [OpenSigner (GitHub)](https://github.com/openfort-xyz/opensigner)
+- [PR #108 — desplega-ai/agent-swarm](https://github.com/desplega-ai/agent-swarm/pull/108)
+- [x402 Protocol (GitHub)](https://github.com/coinbase/x402)
+- [x402 EVM Exact Scheme Spec](https://github.com/coinbase/x402/blob/main/specs/schemes/exact/scheme_exact_evm.md)
+- [EIP-3009: Transfer With Authorization](https://eips.ethereum.org/EIPS/eip-3009)
+- [EIP-712: Typed Structured Data Hashing](https://eips.ethereum.org/EIPS/eip-712)
+- [x402 Coinbase Developer Docs](https://docs.cdp.coinbase.com/x402/welcome)
+- [@x402/evm (npm)](https://www.npmjs.com/package/@x402/evm)
+- [Openfort AI Agent Solutions](https://www.openfort.io/solutions/ai-agents)
+- [Tiger Research: Openfort Report](https://reports.tiger-research.com/p/openfort-web3-game-eng)