Openfort

• Name: Openfort
• URL: https://www.openfort.io/
• Category: wallet-infrastructure company / hosted signer-and-policy operator / embedded-wallet workflow platform
• Tags: ethereum-ecosystem solana-ecosystem
• Summary: Openfort belongs in companies/ because the useful question is not just what features does the SDK expose? A named operator runs the dashboard, issues credentials, hosts the signing and sponsorship workflow, packages recovery and session handling, and decides which wallet and transaction paths are easiest for developers to ship. That makes Openfort better read as a company-run wallet-control plane than as a neutral account primitive.
• What it does:
  • Provides embedded-wallet flows with authentication, recovery, and user-wallet management for app teams
  • Offers backend-wallet and server-signing paths for developer-controlled automation, treasury, agent, and payout use cases
  • Runs bundler, paymaster, and related transaction-infrastructure surfaces across Ethereum and Solana-facing product lines
  • Exposes policy, webhook, environment, and project-configuration controls for live wallet operations
  • Packages OpenSigner as a self-hostable component underneath a broader managed wallet-and-transaction stack
• Key claims:
  • The homepage positions Openfort as wallet infrastructure for developers spanning embedded wallets, key management, and transaction automation at scale, which is already company-shaped workflow language rather than a narrow protocol description
  • The backend-wallet docs explicitly describe backend wallets as developer-controlled, custodial wallets where Openfort generates and encrypts the private keys and the developer backend authorizes every signature with its own credentials
  • Those same docs frame agentic wallets, per-user custodial wallets, and server-side automation as first-class workflows, which makes the operator boundary more concrete than generic account-abstraction marketing
  • The infrastructure docs describe unified authenticated RPC endpoints, bundler and paymaster products, dashboard-issued keys, and dashboard visibility limits for supported smart-account implementations, which is useful because it locates the practical control surface inside one hosted vendor shell
  • Official materials also emphasize OpenSigner as a self-hostable escape hatch beneath the managed platform, which is analytically useful precisely because it highlights how much of the default stack is otherwise company-operated
• Whitepaper: No classic whitepaper or litepaper is the useful artifact here. The strongest primary materials are the homepage, backend-wallet docs, infrastructure docs, and the earlier local source capture in ../whitepapers/openfort-primary-sources-2026-04-23.md.
• Sources:
  • https://www.openfort.io/
  • https://www.openfort.io/docs/products/server
  • https://www.openfort.io/docs/products/infrastructure
  • https://www.openfort.io/docs/configuration/policies
  • https://www.openfort.io/pricing.md
  • https://raw.githubusercontent.com/openfort-xyz/openfort-js/main/README.md

Internal linkages

• Product / legacy note: openfort.
• Best adjacent hosted-wallet company reads: privy, turnkey, and dfns.
• Reusable lens: when a stack sells embedded wallets, backend wallets, sponsorship, and transaction automation together, the real leverage usually sits in credential issuance, policy workflow, dashboard administration, and the hosted signer path around the keys.

Protocol / company boundary

• Keep openfort on the product surface: embedded wallets, backend wallets, sponsorship, OpenSigner, and the feature bundle developers integrate.
• Keep this entity note focused on the named operator boundary: dashboard administration, key and credential issuance, signing-policy workflow, webhook truth, recovery packaging, hosted infrastructure, and supported transaction paths.
• That split matters because Openfort is not usefully analyzed as a neutral protocol. The practical question is who runs the wallet-control plane most developers will depend on in production.

Control surface

• Practical leverage sits in dashboard and environment administration, API-key and credential issuance, signing policy, backend-wallet authorization, sponsorship rules, webhook and telemetry visibility, recovery workflow, and supported chain or smart-account packaging.

• The sticky dependency is not only the account-abstraction or signer primitive. It is the company-run workflow around provisioning, policy, monitoring, and transaction delivery.

• Read Openfort as a hosted wallet-and-signing operator boundary, not as the durable account substrate itself.

• Last reviewed: 2026-08-09 UTC