EDITORIAL ARTICLE
Openfort: Programmable Signing and Permissions for Agent Wallets
Project reference · Openfort Agent Wallets ↗The takeaway: Openfort primarily serves developers embedding wallets and policies in applications. Evaluate who can sign, where restrictions are enforced and what can be self-hosted, rather than treating it as a complete consumer checkout.
Official sources reviewed October 28, 2026. We have not deployed or tested the product.
Product background
Openfort offers developer wallet, signing and account infrastructure. Its agent product page describes separate wallets, spending caps, allowlists, policies and auditing. Its developer page lists SDKs, CLI, API, a test environment and open-source OpenSigner. Teams can build an agent-wallet experience with these tools, but payment providers, funding and merchant access must still be combined according to the integration.
From task to signature: where are permissions enforced?
Suppose a company allows its procurement agent to pay no more than $10 a day to specified data contracts. It can create a wallet, configure destinations and limits, and give the agent limited access. The agent prepares a payment call; a policy system checks it before signing and submission.
This is a conceptual architecture. Rules may live in server policies, on-chain smart-account permissions or a combination, depending on the wallet, network and integration. Openfort’s permissions discussion explains the distinction. Ask where enforcement occurs: if only an API applies a rule, can a caller bypass it and still use the underlying key? For a smart-account session key, which contracts, functions and amounts are allowed?
| Capability | Use | Verify |
|---|---|---|
| Spending limits | Constrain the agent budget | Per-transaction, daily and cross-account accumulation |
| Allowlists | Limit target addresses or contracts | Who approves a new target |
| Session keys | Narrow on-chain agent permissions | Expiry, revocation and on-chain effect |
| Signing service and OpenSigner | Application signing; some components can be self-hosted | Deployment responsibility, key recovery and upgrades |
| Audit | Review requests and policy results | Retention and association with a business task |
Business model
The developer page lists a self-service free tier of 2,000 operations per month and a test mode; consult current pricing for paid plans and operation definitions. Wallet operations, transactions and sponsored network fees may have separate costs. The allowance is not unlimited free transactions. Usage-based infrastructure and enterprise plans are a reasonable interpretation of public pricing, but standalone agent-product revenue is not disclosed.
| Cost question | What to confirm |
|---|---|
| What counts as an operation? | Whether creation, transactions and other API calls are separately metered |
| Gas | Whether the application sponsors it and how on-chain fees are settled |
| Self-hosting | Operations, key management and maintenance beyond the open-source signer |
| Commercial terms | Availability, support, compliance and responsibility for failures |
Coinbase and Crossmint compared
Coinbase offers a more explicit agent-payment and x402 path; Crossmint also covers cards, funding and checkout; Openfort is relevant to teams wanting control over account, signing and policy construction. If merchants accept only cards, signing alone does not complete the payment.
Before release, test the same scenarios: an over-limit request, an incorrect target, an expired session and a stolen agent credential. Check who can change policies and whether recovery is also protected. We have not performed these tests.
Owner keys and session keys
An Openfort session-permissions tutorial describes a smart account where an agent signing key is registered as a non-administrator key with a five-minute lifetime. The agent signs operations within that window; the smart account checks the key and expiry. The owner’s management key registers, changes or revokes the agent’s permission. This is an example configuration, not proof that every Openfort wallet uses it automatically.
Think of a temporary access card: expiration stops later entry, but the doors accessible before expiry depend on the other rules. A five-minute limit alone is not a spending cap. Openfort describes hooks as a way to add restrictions; verify that the validation logic is deployed and covers the intended functions.
| Permission element | Example | Risk if omitted |
|---|---|---|
| Non-administrator role | Agent cannot register more keys | A leaked administrator key may expand permissions |
| Time window | Expires after five minutes | A key may remain usable indefinitely |
| Spending rule | At most 10 USDC per day in a specified asset | Large spending may occur during the window |
| Targets and functions | Only a particular contract and function | Other dangerous functions on an allowed contract may remain callable |
| Revocation | Owner revokes agent key | Abnormal automation may be hard to stop quickly |
On-chain and server-side policies
Openfort’s permission article distinguishes on-chain smart accounts, trusted execution environments and off-chain policy engines. On-chain rules can check a transaction during smart-account execution; server rules can block some requests before signing. They can be combined, but support for on-chain rules does not mean every configuration is enforced on-chain. Likewise, a restricted API does not prove an underlying signing path cannot be bypassed.
Restricting a contract without restricting its functions may permit unrelated calls; a $1 per-transaction cap without a count or aggregate limit can still allow many rapid payments. Designers also need to handle token precision, multiple assets and aggregate budgets across chains.
A developer implementation
First identify the account holding user funds and the agent’s signing identity. Create an account and non-administrator permissions in test mode, provide test assets, set destinations, amounts and expiry, and let the agent request a signature. Finally inspect denied requests, revocation and recovery. Openfort’s developer page lists test mode, self-service API keys, CLI and SDKs.
A wallet does not automatically make an agent able to pay every website. Confirm fiat funding, card processing, merchant integrations and refunds in the actual integration and contract rather than inferring them from signing capability.
Usage charges and operating costs
The publicly listed free tier includes 2,000 monthly operations; current definitions and overage rates need confirmation. If, hypothetically, creating a wallet counts as one operation and each transaction as one, creating 100 wallets and making 1,000 transactions would consume at least 1,100 operations. This illustrates a possible counting method, not an official invoice. Check whether failures, retries and other API calls count and who pays network fees.
Teams self-hosting OpenSigner also take responsibility for deployment, monitoring, updates, key recovery and incident response. Open source may provide more control while changing staffing and operating costs. The decision depends on transaction volume, compliance and engineering capacity, not just the free allowance.