Openfort vs Sponge Wallet

Openfort

Backend wallets sign inside a GCP Confidential Space enclave, secret keys carry 26 scopes, and rate limits, errors and prices are published. On EVM, a backend send reaches the policy engine only as a hash, so address and value rules bind only when the caller runs the pre-flight check first.

Sponge Wallet

An agent can register a wallet with one unauthenticated call and pay x402 or MPP endpoints under daily, weekly and monthly limits enforced on Sponge's servers. No status page, rate limits, fee schedule, custody statement or security contact was found, the terms run to eleven short clauses, and the SDK was last published on 7 July 2026.

Openfort

1. Call policies.evaluate with operation signEvmTransaction before every EVM backend send. The send itself is checked only as signEvmHash
2. Keep the signing policy and the gas sponsorship policy separate. Linking a signing policy to a fee sponsorship stops it working as a guardrail
3. Pass a fee sponsorship on EVM sends. Without one the transaction stays pending with no error
4. Give an agent a secret key without accounts:export, and limit the CLI MCP server to the tools it needs
5. On a 5xx after a write, read the resource before retrying. On a 429, wait the full Retry-After

Sponge Wallet

1. Send Sponge-Version on every REST request. The skill file marks it required and the API answers with version status headers
2. Use evmTransfer and solanaTransfer, the helpers the docs describe as enforcing allowlists and spending limits, not plain transfer
3. Store the apiKey from registration at once. It is returned a single time, and losing it means registering again
4. Call GET /api/discover/{serviceId} before POST /api/paid/fetch. The skill file says direct service URLs fail with auth errors
5. Treat card details output as secret. It returns an encrypted card number and CVC with a one-time secret_key