OWS vs Namera

People have been asking how Namera compares to OWS (Open Wallet Standard), what the differences are, what the tradeoffs look like, and whether they can be paired together. This is a technical comparison covering custody model, policy enforcement, developer ergonomics, and tradeoffs.

---

Summary

OWS and Namera solve a similar problem, but from different layers.

Both care about agents. Both care about not handing raw private keys to software. But they don't put the control point in the same place.

OWS is a local wallet standard. It defines a shared vault under ~/.ows/, encrypted wallet files, API-token-based agent access, CAIP chain identifiers, and a policy engine that checks requests before signing. It asks: how should agents, CLIs, and apps access wallets without each tool inventing its own key storage?

Namera is a programmable permissions layer for smart accounts. It uses session keys, policies, UserOperations, and account-level validation so an agent can only execute actions inside explicit limits. It asks: how should an agent be allowed to act through a smart account without becoming the account owner?

That difference sounds small but it changes the entire model.

---

What is OWS?

OWS is an open standard for local wallet storage, delegated agent access, and policy-gated signing.

Today, every tool stores keys differently:

• an .env file for one bot
• browser wallet for one app
• Solana JSON keypair in another folder
• Foundry keystore somewhere else
• custom agent wallet config in a repo

OWS tries to replace that with one local standard. The core pieces are:

• encrypted wallet vault at ~/.ows/
• wallet files using AES-256-GCM and keystore-style metadata
• API keys for agent access
• CAIP identifiers for chains and accounts
• signing interface for transactions and messages
• policy engine that runs before agent-backed signing
• CLI, Node.js, and Python surfaces in the reference implementation

OWS supports a broad range of chains including EVM, Solana, Bitcoin, Cosmos, Tron, TON, Sui, Filecoin, XRPL, and more. That broad is one of its strongest points.

The flow works like this:

1. A caller asks OWS to sign a transaction or message.
2. OWS checks whether the caller is the owner or an agent.
3. If it is an agent, OWS evaluates the policies attached to that API token.
4. If policies pass, OWS decrypts the wallet secret locally.
5. It derives the right chain key, signs, wipes key material, and returns the signature or signed payload.

Important detail: the agent does not receive the plaintext private key. It receives a scoped API token that can ask the local OWS signer to sign.

---

What is Namera?

Namera is a programmable smart wallet layer for autonomous agents.

It's not trying to become a universal local wallet file format. It's focused on smart accounts, session keys, account abstraction, and policies that define what an agent can do onchain.

The core pieces are:

• Smart accounts with ECDSA and passkey flows
• Session keys with policy-constrained UserOperation signing
• Onchain validation through smart-account infrastructure
• Local CLI and MCP tooling for agents
• Batched, parallel, and multi-chain EVM execution

In Namera, an agent holds a session key, not the owner key. A session key can sign UserOperations for a smart account, but only inside the policies attached to it. If it tries to do something outside those limits, the account validation path rejects it.

Example policies:

• Call policy: only call specific contracts, functions, argument values, or native value amounts
• Gas policy: cap total gas spend or require a paymaster
• Signature policy: restrict who can validate signed messages
• Rate-limit policy: allow only a set number of UserOps per interval
• Timestamp policy: make access start or expire at specific times
• Sudo policy: full access for trusted internal automation

The Namera flow looks like this:

1. The owner creates a smart account.
2. Creates a session key for an agent.
3. Attaches policies to that session key.
4. The agent uses the session key client to send UserOperations.
5. The smart account validates the session key and policy bounds before execution.

---

How They Compare

---

Custody Model

OWS is local custody first.

Wallet secrets live on your machine inside ~/.ows/. The standard defines file layout, encryption, wallet metadata, API key metadata, policy files, and audit logs. A mnemonic wallet can derive addresses across supported chains from one encrypted secret.

For agents, OWS uses API tokens. When an API key is created, wallet secret material is re-encrypted under a key derived from that token. The agent presents the token, policies are checked, and only then does OWS decrypt the token-backed secret copy for signing.

Namera starts from a smart account.

The owner signer remains the source of authority, but the agent operates through a session key that's only valid inside specific policy bounds. The account itself is the enforcement layer.

---

Policy Model

OWS policies are pre-signing checks.

For API-token-backed requests, OWS evaluates all attached policies before touching token-backed secret material. The policy model supports simple declarative rules such as allowed chains and expiry. For more complex logic, OWS supports executable policies that receive request context and return allow or deny.

That makes OWS flexible as a local access-control layer.

But the final result is still a signature from a wallet key. Once a transaction is validly signed and sent, enforcement has already happened locally.

Namera policies are account permissions.

They are attached to session keys and checked during the smart-account execution path. The most important policy is the call policy because it maps directly to actions:

• which target address can be called
• which function can be called
• which argument values are allowed
• how much native value can move
• whether the operation is a call or delegatecall

This is closer to how people describe tasks in plain language:

• "This agent can swap on Uniswap, but only with this token pair."
• "This automation can pay this subscription once per month."
• "This bot can spend up to 100 USDC, not everything."
• "This service can sign orders for this protocol, not random messages."

---

Onchain vs Local Enforcement

OWS enforcement is local and pre-signing.

If the agent uses an OWS API token, policy checks happen before decryption and signing. If a policy denies a request, no signature is produced. That's a strong local boundary. But OWS doesn't turn the wallet into a programmable smart account. It controls the signing path.

Namera enforcement is account-level.

The session key can only execute if the smart account accepts the UserOperation under the attached policies. If the action doesn't match, the account refuses it.

In plain terms:

This matters because agents are not normal users. They can misunderstand, run continuously, retry operations, call tools, and can be compromised.

For agents, the safer question is not only:

Can this process access the key?

It is also:

Even if this delegated credential is used, what can the account actually do?

Namera is built around the second question.

---

Can They Work Together?

Yes.

The clean pairing is:

• OWS manages local wallet storage and signing access.
• Namera manages smart-account permissions and execution.

For example, an owner signer could live behind an OWS-style local vault, while Namera session keys define what an agent can actually do through the smart account.

They are not identical products: OWS is closer to a wallet standard, whereas Namera is closer to an account permission system.

---

Developer Experience

OWS is easier to understand if you already think in wallets and signing.

Create a wallet, sign messages, sign transactions, attach API keys, attach policies. The standard gives different tools one shared local wallet interface. That is useful for CLIs, local agents, scripts, payment tools, and multi-chain apps.

Its biggest developer advantage is breadth:

• many chain families
• one vault
• one local standard
• one signing interface
• Node.js, Python, and CLI support
• chain normalization through CAIP identifiers

Namera is easier to understand if you already think in smart accounts and permissions.

Create a smart account, create a session key, attach policies, build a session key client, execute UserOperations. The SDK hides much of the lower-level account abstraction wiring, but the model still involves bundlers, paymasters, validators, chains, and UserOps.

Its biggest developer advantage is execution control:

• policies map to onchain actions
• session keys avoid sharing the owner signer
• revocation is done by the owner
• batches can be atomic
• nonce lanes allow parallel execution
• multi-chain EVM workflows can be described in one execution request

So the tradeoff is straightforward.

OWS gives you simpler local wallet interoperability.

Namera gives you stronger smart-account execution boundaries.

---

Which One Do You Need?

Use OWS if your main problem is local wallet access across tools.

Good fit:

• You want one encrypted wallet vault on a machine.
• You want agents to request signatures without seeing raw keys.
• You need EVM, Solana, Bitcoin, Cosmos, Tron, TON, Sui, Filecoin, or XRPL under one standard.
• You want wallet artifacts that different tools can share.
• You want a local-first model instead of a cloud wallet API.
• You need broad signing support more than account-level permissioning.

OWS is especially useful for the "my tools all need a wallet" problem. It gives agents a safer way to ask for signatures.

Use Namera if your main problem is agent execution safety.

Use Namera if your main problem is agent execution safety.

Good fit:

• You are building an agent that will move funds on EVM chains.
• You need scoped access to a smart account.
• You want policies like contract allowlists, function limits, spend caps, time windows, and rate limits.
• You want the account to reject out-of-policy actions.
• You are building DeFi automation, treasury automation, subscriptions, trading agents, payroll, payments, or protocol-specific workflows.
• You want agents to operate with permissions, not owner keys.

Namera is especially useful for the "what is this agent allowed to do?" problem.

Use both if you need the full stack. Safe local key custody at the signing layer. Enforceable execution boundaries at the account layer.

---

Final Takeaway

OWS and Namera both respond to the same reality: agents should not hold unrestricted private keys. They just solve different parts of it.

OWS is best when you need a standard local wallet vault and safe signing interface across many chains and tools.

Namera is best when you need an agent to operate through a smart account with clear, enforceable limits.

The simplest way to remember it:

OWS controls access to the signer. Namera controls what the account may execute.

Agents don't need private keys. They need permissioned execution.