# Introduction (/docs)



Namera is a programmable smart wallet infrastructure designed for autonomous agents and advanced users who need fine-grained control over onchain execution.

How to Use These Docs [#how-to-use-these-docs]

The documentation is structured to guide you from foundational concepts to advanced execution patterns, helping you progressively understand how Namera models transactions, permissions, and agent-driven workflows.

You can follow the docs based on sections like SDK, CLI, MCP, x402 Payments or integration guides depending on your use case. Each page is designed to be self-contained, with clear explanations and practical examples so you can quickly apply concepts in real scenarios.

To facilitate navigation within a page, you will find a table of contents on the right side of the screen. This allows you to easily jump between different sections of the page.

Docs for LLMs [#docs-for-llms]

We support the llms.txt convention for making documentation available to large language models and the applications that make use of them.

Currently, we have the following root-level files:

* <a href="/llms.txt">/llms.txt</a> — a listing of the available files
* <a href="/llms-full.txt">/llms-full.txt</a> — complete documentation for Namera


# Why Namera (/docs/why-namera)



Giving an agent the ability to act onchain sounds simple until you actually try to do it safely. The moment an agent can move funds, sign transactions, or interact with protocols, you introduce a new class of risks that traditional wallet designs were never built to handle. Namera exists to solve this exact gap: how do you give agents real execution power without giving up control?

The Problem with Agent Wallets [#the-problem-with-agent-wallets]

Today, most agent systems treat wallets as an afterthought. You either hand over full control, or you build fragile guardrails around something that was never designed to be constrained.

The most common pattern is still passing a raw private key through a `.env` file. The agent signs transactions directly, often with no granular permissions, no execution boundaries, and no visibility into what it *should* or *should not* be doing. Once the key is exposed to the runtime, the agent effectively has unrestricted authority. There is no concept of scoped access, no isolation between tasks, and no safe way to parallelize operations.

Some systems attempt to improve this by wrapping wallets behind APIs or using custodial services. Others experiment with giving agents access to payment rails credit cards, API-based billing systems, or prepaid balances. While these approaches reduce direct key exposure, they introduce a different problem: they move execution offchain or into opaque systems, limiting composability with existing protocols like Uniswap or Aave.

What Namera Does Differently [#what-namera-does-differently]

Namera does not try to replace wallets. It defines a way, how you use them in an agent-driven world.

At its core, Namera gives you a structured way to issue permissioned, programmable access to a wallet. Instead of handing over a private key, you create scoped session keys with explicit capabilities such as

* what contracts can be called
* which functions are allowed
* how much value can be moved
* how long the key can be used
* how many times the key can be used

and much more.

Under the hood, Namera builds on battle-tested smart account infrastructure [ZeroDev](https://zerodev.app/). This means you inherit the reliability, security model, and ecosystem compatibility of existing account abstraction systems. We are not introducing a new wallet standard or asking you to trust experimental primitives. We are using what already works and extending it to support agent-native workflows.

The result is a wallet that behaves less like a signer and more like a programmable execution environment.

Designed to Work with the Ecosystem [#designed-to-work-with-the-ecosystem]

Namera is built with the assumption that the ecosystem will continue to evolve and faster than before.

We are not trying to replace emerging standards or competing approaches. Instead, we aim to integrate and support them as they mature. Whether it's secure key management approaches like Foundry Keystore, payment abstractions such as [x402](https://www.x402.org/), or newer protocols like [MPP](https://docs.stripe.com/payments/machine/mpp), Namera is designed to be compatible and extensible.


# CLI Page (/docs/cli)



This is a CLI page


# Transaction Execution (/docs/cli/transaction-execution)



Namera defines a lane-based execution model for smart accounts that enables:

* Single transactions
* Atomic batching
* Parallel execution (via nonce lanes)
* Multi-chain execution
* Cross-chain parallelism

This model is designed for agents, automation, and programmable session keys.

Core Concepts [#core-concepts]

1\. Call [#1-call]

A `Call` is the smallest unit of execution.

```ts
export type Call = {
    target: Address;   // contract or EOA
    data: Hex;         // encoded calldata
    value?: bigint;    // optional ETH/native value
}
```

2\. Batch [#2-batch]

A `Batch` is a group of calls executed sequentially on a single chain.

```ts
export type Batch = {
  chainId: number;   // target chain
  calls: Call[];

  // execution lane  (2D Nonce)
  nonceKey?: string;

  // execution semantics
  atomic?: boolean;  // default: true
}
```

3\. Execute Transaction Params [#3-execute-transaction-params]

Top-level execution container.

```ts
export type ExecuteTransactionParams = {
  batches: Batch[];
}
```

***

Execution Model [#execution-model]

Sequential Execution (within a batch) [#sequential-execution-within-a-batch]

* Calls inside a batch are executed in order
* If atomic = true:
  * Any failure → entire batch reverts
* If atomic = false:
  * Partial execution may be allowed (implementation-specific)

Parallel Execution (across batches) [#parallel-execution-across-batches]

Parallelism is controlled via nonceKey (execution lanes):

* Same nonceKey → executed sequentially
* Different nonceKey → can execute in parallel

Multi-chain Execution [#multi-chain-execution]

* Each batch specifies its own chainId
* Batches are routed and executed per chain
* A single logical request can span multiple chains

***

Execution Scenarios [#execution-scenarios]

Single Transaction [#single-transaction]

**Example: Transfer USDC on Ethereum**

A user wants to send 100 USDC to a friend.

Flow:

* Token: USDC
* Chain: Ethereum
* Action: `transfer(address _to, uint256 _value)`

```ts
{
  batches: [
    {
      calls: [
        {
          data: "transfer(0xALICE, 100e6)",
          target: "0xUSDC",
        },
      ],
      chainId: 1,
    },
  ],
}
```

> Smart Account executes a single call, no batching, no parallelism.

***

Sequential Batch (Atomic) [#sequential-batch-atomic]

**Example: Swap USDC → ETH on Uniswap**

User wants to swap USDC to ETH using Uniswap.

Required steps:

1. Approve USDC to router
2. Execute swap

```ts
{
  batches: [
    {
      chainId: 1,
      nonceKey: "swap",
      calls: [
        {
          target: "0xUSDC",
          data: "approve(0xUniswapRouter, 100e6)"
        },
        {
          target: "0xUniswapRouter",
          data: "swapExactTokensForETH(...)"
        }
      ]
    }
  ]
}
```

> Smart Accounts executes a batch of calls in order, fully atomic, no parallelism.

***

Parallel Batches (Same Chain) [#parallel-batches-same-chain]

**Example: Swap on Uniswap + Deposit into Aave (Ethereum)**

User wants to:

1. Swap USDC → ETH on Uniswap
2. Deposit DAI into Aave

These actions are independent → can run in parallel.

```ts
{
  batches: [
    {
      chainId: 1,
      nonceKey: "swap",
      calls: [
        {
          target: "0xUniswapRouter",
          data: "swapExactTokensForETH(...)"
        }
      ]
    },
    {
      chainId: 1,
      nonceKey: "lend",
      calls: [
        {
          target: "0xDAI",
          data: "approve(AavePool, 1000e18)"
        },
        {
          target: "0xAavePool",
          data: "supply(DAI, 1000e18, ...)"
        }
      ]
    }
  ]
}
```

> Smart Account executes two independent nonce lanes: `swap` and `lend`, both in parallel. Two transaction hashes are generated. each batch is atomic.

***

Multi-Chain Batches [#multi-chain-batches]

**Example: Trade on Ethereum + Lend on Polygon**\*

User strategy:

1. Swap ETH → USDC on Uniswap (Ethereum)
2. Deposit USDC into Aave (Polygon)

```ts
{
  batches: [
    {
      chainId: 1, // Ethereum
      calls: [
        {
          target: "0xUniswapRouter",
          data: "swapExactETHForTokens(...)"
        }
      ]
    },
    {
      chainId: 137, // Polygon
      calls: [
        {
          target: "0xUSDC",
          data: "approve(AavePool, 1000e6)"
        },
        {
          target: "0xAavePool",
          data: "supply(USDC, 1000e6, ...)"
        }
      ]
    }
  ]
}
```

> Smart Account executes two different chains, via separate bundlers. Same user intent, split execution. Not atomic across chains.

***

Multi-Chain + Parallel Execution [#multi-chain--parallel-execution]

**Example: Full Portfolio Strategy (Ethereum + Base)**

User wants to:

On Ethereum:

1. Swap on Uniswap
2. Add liquidity on Curve

On Base:

1. Deposit into Aave
2. Stake in a vault

```ts
{
  batches: [
    // Ethereum - lane A
    {
      chainId: 1,
      nonceKey: "eth-swap",
      calls: [
        {
          target: "0xUniswapRouter",
          data: "swapExactTokensForETH(...)"
        }
      ]
    },
    // Ethereum - lane B
    {
      chainId: 1,
      nonceKey: "eth-liquidity",
      calls: [
        {
          target: "0xCurve",
          data: "add_liquidity(...)"
        }
      ]
    },

    // Base - lane C
    {
      chainId: 8453,
      nonceKey: "base-lend",
      calls: [
        {
          target: "0xAavePool",
          data: "supply(...)"
        }
      ]
    },

    // Base - lane D
    {
      chainId: 8453,
      nonceKey: "base-stake",
      calls: [
        {
          target: "0xVault",
          data: "deposit(...)"
        }
      ]
    }
  ]
}
```

> Smart Account executes four independent execution lanes: `eth-swap`, `eth-liquidity`, `base-lend`, and `base-stake`, all in parallel. Parallel execution within Ethereum and Base.

***


# Getting Started (/docs/sdk/getting-started)



Installation [#installation]

To install Namera SDK, you can use the following command:

<CodeBlockTabs defaultValue="npm" groupId="package-manager">
  <CodeBlockTabsList>
    <CodeBlockTabsTrigger value="npm">
      npm
    </CodeBlockTabsTrigger>

    <CodeBlockTabsTrigger value="pnpm">
      pnpm
    </CodeBlockTabsTrigger>

    <CodeBlockTabsTrigger value="yarn">
      yarn
    </CodeBlockTabsTrigger>

    <CodeBlockTabsTrigger value="bun">
      bun
    </CodeBlockTabsTrigger>
  </CodeBlockTabsList>

  <CodeBlockTab value="npm">
    ```bash
    npm install @namera-ai/sdk viem
    ```
  </CodeBlockTab>

  <CodeBlockTab value="pnpm">
    ```bash
    pnpm add @namera-ai/sdk viem
    ```
  </CodeBlockTab>

  <CodeBlockTab value="yarn">
    ```bash
    yarn add @namera-ai/sdk viem
    ```
  </CodeBlockTab>

  <CodeBlockTab value="bun">
    ```bash
    bun add @namera-ai/sdk viem
    ```
  </CodeBlockTab>
</CodeBlockTabs>

* [Viem](https://viem.sh/) is a TypeScript interface for Ethereum that performs blockchain operations.

Setup Public Client [#setup-public-client]

Before you can use Namera SDK, you need to set up a public client. This client will be used to interact with the Ethereum network.

```ts
import { createPublicClient, http } from "viem";
import { mainnet } from "viem/chains";

const publicClient = createPublicClient({
  chain: mainnet,
  transport: http(),
});
```

Create Signer [#create-signer]

Next, you need to create a signer. A signer is an object that can sign transactions and messages. It can be one of `EIP1193Provider`, `WalletClient`, `LocalAccount`, or `SmartAccount`.

```ts
import { generatePrivateKey, privateKeyToAccount } from "viem/accounts";

const signer = privateKeyToAccount(generatePrivateKey());
```

Create Smart Account Client [#create-smart-account-client]

Now that you have a public client and a signer, you can create an ECDSA Smart Account client.

```ts
import { createAccountClient } from "@namera-ai/sdk/account";

const client = await createAccountClient({
  type: "ecdsa",
  bundlerTransport: http("https://public.pimlico.io/v2/1/rpc"), // Public Pimlico RPC
  chain: mainnet,
  client: publicClient,
  entrypointVersion: "0.7",
  kernelVersion: "0.3.2",
  signer,
});

// Get the address of the smart account
const saAddress = client.account.address;
```


# Introduction (/docs/sdk)



# Installation (/docs/sdk/installation)



Package Manager [#package-manager]

Install the required packages.

<CodeBlockTabs defaultValue="npm" groupId="package-manager">
  <CodeBlockTabsList>
    <CodeBlockTabsTrigger value="npm">
      npm
    </CodeBlockTabsTrigger>

    <CodeBlockTabsTrigger value="pnpm">
      pnpm
    </CodeBlockTabsTrigger>

    <CodeBlockTabsTrigger value="yarn">
      yarn
    </CodeBlockTabsTrigger>

    <CodeBlockTabsTrigger value="bun">
      bun
    </CodeBlockTabsTrigger>
  </CodeBlockTabsList>

  <CodeBlockTab value="npm">
    ```bash
    npm i @namera-ai/sdk viem
    ```
  </CodeBlockTab>

  <CodeBlockTab value="pnpm">
    ```bash
    pnpm add @namera-ai/sdk viem
    ```
  </CodeBlockTab>

  <CodeBlockTab value="yarn">
    ```bash
    yarn add @namera-ai/sdk viem
    ```
  </CodeBlockTab>

  <CodeBlockTab value="bun">
    ```bash
    bun add @namera-ai/sdk viem
    ```
  </CodeBlockTab>
</CodeBlockTabs>

* [Viem](https://viem.sh/) is a TypeScript interface for Ethereum that performs blockchain operations.
* [TypeScript](https://wagmi.sh/react/typescript) is optional, but highly recommended.

CDN [#cdn]

If you're not using a package manager, you can also use Wagmi via an ESM-compatible CDN such as [esm.sh](https://esm.sh). Simply add a `<script type="module">` tag to the bottom of your HTML file with the following content.

```html
<script type="module">
    import { createClient } from 'https://esm.sh/viem@2.x'
    import { createEcdsaAccountClient } from 'https://esm.sh/@namera-ai/sdk/account'
</script>
```

Building from Source [#building-from-source]

If you'd like to build Namera SDK from source, you can do so by cloning the repository and running the following command.

```bash
gh repo clone thenamespace/namera
cd namera
bun install
bun run build
cd packages/sdk
bun link --global
```


# Introduction (/docs/sdk/policies)



# Introduction (/docs/sdk/session-keys)



# Create Smart Account (/docs/sdk/smart-accounts/create)



When you create a smart account, you can choose from a variety of validators to define how the account validates UserOps. In this tutorial, we will be using the Multi-Chain ECDSA validator, which works like a normal EOA by validating signatures from a ECDSA private key, but also supports sending multiple UserOps across multiple chains using a single signature.

***

Import [#import]

```ts
import { createAccountClient } from "@namera-ai/sdk/account";
```

***

Usage [#usage]

To create a smart account, you need a ecdsa validator, a public client, and a bundler client. The ECDSA validator can be one of: `EIP1193Provider`, `WalletClient`, `LocalAccount`, or `SmartAccount`.

In this example, we will be using the `LocalAccount`.

<CodeBlockTabs defaultValue="index.ts">
  <CodeBlockTabsList>
    <CodeBlockTabsTrigger value="index.ts">
      index.ts
    </CodeBlockTabsTrigger>

    <CodeBlockTabsTrigger value="clients.ts">
      clients.ts
    </CodeBlockTabsTrigger>
  </CodeBlockTabsList>

  <CodeBlockTab value="index.ts">
    ```ts title="index.ts" 
    import { generatePrivateKey, privateKeyToAccount } from 'viem/accounts';
    import { publicClient, bundlerClient } from './clients';
    import { mainnet } from 'viem/chains';
    import { createAccountClient } from '@namera-ai/sdk/account';

    const signer = privateKeyToAccount(generatePrivateKey());

    const client = await createAccountClient({
      type: "ecdsa",
      bundlerTransport: http("https://public.pimlico.io/v2/1/rpc"), // Public Pimlico RPC
      chain: mainnet,
      client: publicClient,
      entrypointVersion: "0.7",
      kernelVersion: "0.3.2",
      signer,
    });

    const saAddress = client.account.address; // Smart Account Address
    ```
  </CodeBlockTab>

  <CodeBlockTab value="clients.ts">
    ```ts title="clients.ts" 
    import { createPublicClient, http } from "viem";
    import { mainnet } from "viem/chains";

    export const publicClient = createPublicClient({
      chain: mainnet,
      transport: http(),
    });
    ```
  </CodeBlockTab>
</CodeBlockTabs>

***

Examples [#examples]

Create a new ECDSA Smart Account client on Ethereum Mainnet with local signer and paymaster.

```ts title="index.ts"
import { createAccountClient } from "@namera-ai/sdk/account";
import { createPublicClient, http } from "viem";
import { createPaymasterClient } from "viem/account-abstraction";
import { generatePrivateKey, privateKeyToAccount } from "viem/accounts";
import { mainnet } from "viem/chains";

export const publicClient = createPublicClient({
  chain: mainnet,
  transport: http(),
});

const paymaster = createPaymasterClient({
  transport: http("ZERO_DEV_PAYMASTER_URL"),
});

const signer = privateKeyToAccount(generatePrivateKey());

const client = await createAccountClient({
  type: "ecdsa",
  bundlerTransport: http("https://public.pimlico.io/v2/1/rpc"), // Public Pimlico RPC
  chain: mainnet,
  client: publicClient,
  entrypointVersion: "0.7",
  kernelVersion: "0.3.2",
  paymaster,
  signer,
});

const saAddress = client.account.address; // Smart Account Address
```

<CalloutContainer type="warning">
  <CalloutDescription>
    The Bundler URL above is a public endpoint. Please do not use it in production as you will likely be rate-limited. Consider using [Pimlico's Bundler](https://www.pimlico.io/), [Biconomy's Bundler](https://www.biconomy.io/), or another Bundler service.
  </CalloutDescription>
</CalloutContainer>

***

Parameters [#parameters]

signer [#signer]

* Only required when `type="ecdsa"`
* **Type:** `Signer` | `OneOf<EIP1193Provider, WalletClient, LocalAccount, SmartAccount>`

```ts title="index.ts"
const client = await createAccountClient({
  type: "ecdsa",
  signer: walletClient, // [!code focus]
  bundlerTransport: http("https://public.pimlico.io/v2/1/rpc"), // Public Pimlico RPC
  chain: mainnet,
  client: publicClient,
  entrypointVersion: "0.7",
  kernelVersion: "0.3.2",
});
```

client [#client]

* **Type:** `Client<HttpTransport, Chain, JsonRpcAccount | LocalAccount | undefined>`

```ts title="index.ts"
import { createPublicClient, http } from "viem";
import { mainnet } from "viem/chains";

export const publicClient = createPublicClient({
  chain: mainnet,
  transport: http(),
});
```

bundlerTransport [#bundlertransport]

* **Type:** `Transport`

```ts title="index.ts"
import { createPublicClient, http } from "viem";
import { mainnet } from "viem/chains";

export const publicClient = createPublicClient({
  chain: mainnet,
  transport: http(),
});
```

chain [#chain]

* **Type:** `Chain`

```ts title="index.ts"
import { mainnet } from "viem/chains";
```

entrypointVersion [#entrypointversion]

* **Type:** `EntrypointVersion` => `"0.6" | "0.7" | "0.8" | "0.9"{:ts}`

```ts twoslash title="index.ts"
// @noErrors
import { EntryPointVersion } from 'viem/account-abstraction';  // [!code focus]
//          ^?

const client = await createAccountClient({
  type: "ecdsa",
  signer: walletClient,
  bundlerTransport: http("https://public.pimlico.io/v2/1/rpc"), // Public Pimlico RPC
  chain: mainnet,
  client: publicClient,
  entrypointVersion: "0.7", // [!code focus]
  kernelVersion: "0.3.2",
});
```

kernelVersion [#kernelversion]

* **Type:** `KernelVersion` => `"0.0.2" | "0.2.2" | "0.2.3" | "0.2.4" | "0.3.1" | "0.3.2" | "0.3.3"{:ts}`

> Note: Kernel 0.2.x supports only Entrypoint 0.6. For Kernel 0.3.x, you can use Entrypoint 0.7 or 0.8.

```ts title="index.ts"
const client = await createAccountClient({
  type: "ecdsa",
  signer: walletClient,
  bundlerTransport: http("https://public.pimlico.io/v2/1/rpc"), // Public Pimlico RPC
  chain: mainnet,
  client: publicClient,
  entrypointVersion: "0.7",
  kernelVersion: "0.3.2", // [!code focus]
});
```

index [#index]

```ts title="index.ts"
import { createAccountClient } from "@namera-ai/sdk/account";

const client = await createAccountClient({
  type: "ecdsa",
  signer: walletClient,
  bundlerTransport: http("https://public.pimlico.io/v2/1/rpc"), // Public Pimlico RPC
  chain: mainnet,
  client: publicClient,
  entrypointVersion: "0.7",
  kernelVersion: "0.3.2",
  index: 0n, // [!code focus]
});
```

paymaster [#paymaster]

* **Type:** `PaymasterClient`

```ts title="index.ts"
import { createPaymasterClient } from "viem/account-abstraction";  // [!code focus]
import { createAccountClient } from "@namera-ai/sdk/account";

const paymaster = createPaymasterClient({  // [!code focus]
  transport: http("ZERO_DEV_PAYMASTER_URL"),  // [!code focus]
});  // [!code focus]


const client = await createAccountClient({
  type: "ecdsa",
  signer: walletClient,
  bundlerTransport: http("https://public.pimlico.io/v2/1/rpc"), // Public Pimlico RPC
  chain: mainnet,
  client: publicClient,
  entrypointVersion: "0.7",
  kernelVersion: "0.3.2",
  index: 0n,
  paymaster: paymasterClient, // [!code focus]
});
```

FAQs [#faqs]

When I create a account, is it deployed onchain? [#when-i-create-a-account-is-it-deployed-onchain]

No, accounts are not deployed onchain yet. Your account is deployed automatically when you send the first UserOp. You can create an infinite number of such account objects without paying any gas.

Can I create multiple accounts from the same signer? [#can-i-create-multiple-accounts-from-the-same-signer]

Yes, you can do so by providing an index when you create the account object.

```ts title="index.ts"
import { createAccountClient } from "@namera-ai/sdk/account";

const client = await createAccountClient({
  type: "ecdsa",
  signer: walletClient,
  bundlerTransport: http("https://public.pimlico.io/v2/1/rpc"), // Public Pimlico RPC
  chain: mainnet,
  client: publicClient,
  entrypointVersion: "0.7",
  kernelVersion: "0.3.2",
  index: 1n, // [!code focus]
});
```


# Introduction (/docs/sdk/smart-accounts)



Smart accounts replace the traditional “private key = control” model with programmable, contract-based accounts that define how execution happens—not just who signs. Instead of relying on a single EOA signature, a smart account validates and executes transactions through onchain logic, enabling policy enforcement, modular auth, and deterministic execution flows.

Why Namera Uses Smart Accounts [#why-namera-uses-smart-accounts]

Namera is built on top of ZeroDev smart accounts and its plugin system. We chose ZeroDev because it is battle-tested, actively maintained, and deeply aligned with the evolving account abstraction ecosystem. Instead of building a custom wallet stack, we leverage ZeroDev's contracts and extend them with agent-focused primitives.

What You Can Do with ZeroDev Smart Accounts [#what-you-can-do-with-zerodev-smart-accounts]

ZeroDev exposes a modular smart account architecture that lets you compose advanced wallet behaviors without rebuilding core logic. Through plugins and validation modules, you can extend how accounts authenticate, authorize, and execute transactions.

With this setup, you can:

* Enable session keys to delegate scoped permissions to agents without exposing the primary signer
* Support passkeys (WebAuthn) for secure, password-less authentication flows
* Construct multisig accounts with flexible threshold and signer configurations
* Add guardians and recovery mechanisms for account safety and social recovery
* Execute batched and parallel transactions with fine-grained nonce control
* Operate across chains with multi-chain signing and execution patterns

Smart Accounts in Namera [#smart-accounts-in-namera]

For now we support the following smart accounts:

* [ECDSA](/docs/sdk/smart-accounts/create)
* [Passkey](/docs/sdk/smart-accounts/passkey)

we have plans to support more like WebAuth, Multi-sig smart accounts in the future.