Appendix A: Openfort Wallet Infrastructure Evaluation
1. Why Openfort
Section titled “1. Why Openfort”Capxul handles people’s salaries. The infrastructure that manages their wallet keys should be something we can own, audit, and run ourselves if needed. Privy (our previous provider, acquired by Stripe) uses proprietary TEE-based key management that cannot be self-hosted, audited, or forked. If Stripe changes Privy’s pricing, direction, or shuts it down, our users’ keys are inaccessible.
Openfort’s key management layer (OpenSigner) is MIT-licensed, open-source, and self-hostable. Their smart account contracts are open source (GPL-3.0). Their recovery server (Shield) is open source. The critical pieces that touch user funds and keys are code we can inspect, fork, and run on our own infrastructure.
Beyond self-hosting, Openfort offers three additional advantages:
- Native EIP-7702 support. Openfort’s V2 account architecture is built around 7702 (upgrading existing EOAs to smart accounts). This is on Capxul’s roadmap.
- Better Auth integration. Openfort maintains a first-party Better Auth plugin (
@openfort/better-auth), documented at better-auth.com/docs/plugins/openfort. - Single vendor. Replaces both Privy (auth/key management) and ZeroDev (smart accounts) with one integration.
2. Architecture: What Comes From Where
Section titled “2. Architecture: What Comes From Where”2.1 Components We Own From Day One
Section titled “2.1 Components We Own From Day One”OpenSigner (Key Management). MIT-licensed. Handles private key generation, Shamir secret sharing (3 shares), and key reconstruction. Runs client-side in an isolated browser iframe. Self-hosting means running a Node.js service.
Shield (Recovery Server). Open source. Stores encrypted recovery shares. Issues encryption sessions when users authenticate. Self-hosting means a second Node.js service.
Smart Account Contracts. GPL-3.0. ERC-4337 compliant. Upgradeable (ERC-1967). Built-in session keys, social recovery, batch transactions.
2.2 Components We Bring Our Own
Section titled “2.2 Components We Bring Our Own”Bundler. Openfort supports third-party bundlers. If Base provides free bundler access, use that.
Paymaster. Same. Openfort’s changelog confirms custom paymaster support.
Auth. Better Auth with magic links, on our infrastructure.
Backend. Convex for all application data.
2.3 Component We Depend on Openfort For (Initially)
Section titled “2.3 Component We Depend on Openfort For (Initially)”Openfort’s Hosted API (api.openfort.io). NOT open source. NOT self-hostable.
| Function | Replaceable? | Effort |
|---|---|---|
| Player management | Yes (Convex) | Low |
| Address pre-computation | Yes (viem + CREATE2) | Low |
| Transaction building | Yes (viem + permissionless.js) | Medium |
| Session key management | Yes (direct contract calls) | Medium |
| Guardian management | Yes (direct contract calls) | Medium |
| Policy engine | Unnecessary with BYO paymaster | N/A |
Nothing is architecturally irreplaceable. The question is engineering time, not lock-in.
3. OpenSigner: How Key Management Works
Section titled “3. OpenSigner: How Key Management Works”Key generated client-side in an isolated iframe. Split into 3 Shamir shares:
- Device share: on the user’s device, never leaves the browser
- Hot share: encrypted, sent to server (Openfort cloud or self-hosted)
- Recovery share: encrypted, sent to Shield (Openfort cloud or self-hosted)
Any 2 of 3 reconstruct the key. The complete key exists only temporarily in memory during signing.
Comparison to Privy
Section titled “Comparison to Privy”Privy: 2-of-2 TEE model. Proprietary. Non-exportable.
OpenSigner: 2-of-3 Shamir in standard compute. Tradeoff: no hardware-level isolation, but full auditability and self-hostability.
4. Auth Flow: Better Auth + Magic Links + Openfort
Section titled “4. Auth Flow: Better Auth + Magic Links + Openfort”Detailed auth flow as implemented in Chapter 3.
5. ERC-7579 and Why It Does Not Block Us
Section titled “5. ERC-7579 and Why It Does Not Block Us”Openfort V1 smart accounts are NOT 7579 compliant. Built-in features cover all needs. Upgradeable proxies allow future 7579 support without changing addresses.
EIP-7702 is more important for Capxul’s roadmap than ERC-7579. 7702 lets existing EOA users upgrade to smart accounts without abandoning their address. Openfort’s V2 architecture is built around this.
6. Pricing and Cost
Section titled “6. Pricing and Cost”| Scale | Openfort | Privy + ZeroDev |
|---|---|---|
| 500 MAU | Free | $368/mo |
| 1,000 MAU | Free | $368/mo |
| 2,000 MAU | Est. < $100/mo | $368/mo |
Openfort charges per operation (wallet creation or transaction). No activity, no cost. Better model for payroll where users interact infrequently.
Gas sponsorship: separate from Openfort pricing. Base/Coinbase free paymaster: $0. Funding own paymaster: ~$5-20/month for 2,000 users on Base.
Fully self-hosted end state: $0 Openfort dependency.
7. Complete Workflow
Section titled “7. Complete Workflow”Detailed end-to-end workflow as implemented in Chapter 3.
8. Recovery
Section titled “8. Recovery”Three-tier recovery model as defined in Chapter 3.
9. What We Gain vs. What We Lose
Section titled “9. What We Gain vs. What We Lose”Compared to Privy + ZeroDev
Section titled “Compared to Privy + ZeroDev”| Openfort | Privy + ZeroDev | |
|---|---|---|
| Key management | Self-hostable (MIT) | Proprietary TEE |
| Auth | BYO (Better Auth) | Privy IS the auth |
| Smart account contracts | Open source (GPL-3.0) | Kernel open source, Privy key layer not |
| 7579 modules | No (built-in equivalents) | Yes (Rhinestone ecosystem) |
| Vendor count | 1 (migrating to 0) | 2 |
| Battle-tested scale | ~150K users | 110M wallets (Privy) + 5M (ZeroDev) |
| Path to independence | Clear (phased self-hosting) | Not possible (Privy TEE proprietary) |
What We Lose
Section titled “What We Lose”- Rhinestone module ecosystem (ZK Email Recovery, Deadman Switch, ColdStorage)
- Scale confidence (fewer users in production)
- Community size (fewer tutorials, examples)
- ZeroDev’s composable permissions (more mature than Openfort’s session keys)
What We Gain
Section titled “What We Gain”- Infrastructure sovereignty with clear, incremental path
- Cost: free at launch scale
- Auth ownership (Better Auth is ours)
- 7702 readiness (first-class)
- Simplicity (one integration instead of two)
10. Open Questions for Openfort
Section titled “10. Open Questions for Openfort”- Server-side pre-generation API — exact endpoints and parameters for bulk creation
- Guardian configuration timing — can Capxul be set as guardian during server-side creation?
- Email change for pre-generated wallets — confirm create-new/orphan-old pattern
- 7579 roadmap — timeline for compliance (not a blocker)
- Self-hosted Shield + Better Auth — validated together?
11. POC Specification
Section titled “11. POC Specification”8 scenarios as consolidated in Chapter 12: Implementation Roadmap.
The 7702 Path (Future)
Section titled “The 7702 Path (Future)”- Crypto-savvy user connects MetaMask to Capxul
- Capxul proposes 7702 delegation to Openfort’s delegator contract
- MetaMask signs the authorization
- The address now has smart account capabilities
- The address stays the same. Existing tokens remain.
- Salary streams go directly to this 7702-upgraded address
- Delegation persists until explicitly revoked