> For the complete documentation index, see [llms.txt](https://docs.pepeunchained.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.pepeunchained.com/onboarding-and-wallets/smart-accounts.md). # Smart Accounts Pepe Unchained V2 has an ERC-4337 foundation deployed on mainnet: both EntryPoint versions, a ZeroDev Kernel v3 smart-account factory, and a v2 sponsored paymaster contract. Smart accounts are available here, and sponsorship runs on top of them through PEPU's hosted bundler (`https://bundler.pepeunchained.com`) and paymaster service (`https://paymaster.pepeunchained.com`). Keep the two claims separate: an account existing is not the same as gas being sponsored for it. Terms used on this page: [UserOperation](/reference/glossary.md), [bundler](/reference/glossary.md), [paymaster](/reference/glossary.md), [EntryPoint](/reference/glossary.md), [Kernel](/reference/glossary.md). All are defined in the [Glossary](/reference/glossary.md). Which smart-account setup to use: [Smart Account Paths](/concepts/smart-account-paths.md). ## What is live (mainnet only) Deployed via ZeroDev's one-click Conduit Marketplace integration, plus a project-deployed paymaster: | Contract | Address | | -------------------------------- | -------------------------------------------- | | EntryPoint v0.6 | `0x5FF137D4b0FDCD49DcA30c7CF57E578a026d2789` | | EntryPoint v0.7 | `0x0000000071727De22E5E9d8BAf0edAc6f37da032` | | Kernel v3 account factory | `0xaac5D4240AF87249B3f71BC8E4A2cae074A3E419` | | Kernel MetaFactory | `0xd703aaE79538628d27099B8c4f621bE4CCd142d5` | | Kernel ECDSA validator | `0x845ADb2C711129d4f3966735eD98a9F09fC4cE57` | | Sponsored paymaster v2 | `0xdb28528C9399C33c9A0297E8A62F39145acbC30D` | | Verifying paymaster v1 (retired) | `0x2B6FED323bFA24f0475f4e1Dd3C7F6Cc1f3ae8B0` | Both EntryPoints are at their canonical addresses and the Kernel contracts are ZeroDev's standard v3 deployment. The v2 paymaster is this project's own contract, The v1 paymaster is retired (its EntryPoint deposit is 0), so it cannot sponsor anything; never deposit to it. See [Deployed Contracts](/contracts-and-addresses/deployed-contracts.md) for the full table. None of it is deployed on testnet. Testnet is out of scope for development; see [Network Reference](/get-started/network-reference.md#testnet-out-of-scope-today). ## What you can do * **Deploy and control a Kernel v3 smart account.** The factory and its ECDSA validator are live, so an account owned by an embedded wallet's key can be created at its counterfactual address and used. Without a paymaster it pays its own gas, exactly like an EOA. * **Compute an account's address ahead of time**, from the factory's own on-chain `getAddress`, with [`@pepu-chain/sdk`](/sdk/aa.md) (`getKernelAccountAddress`) or the `pepu_smart_account_info` tool in the [MCP server](/agent-tooling/mcp-and-skills.md). * **Inspect the infrastructure.** The contracts are verified on pepuscan. A smart account is a separate address from the embedded wallet that owns it. Read [The Two-Address Model](/onboarding-and-wallets/two-address-model.md) before you build UI around one. ## Sponsorship See [Sponsored Transactions](/onboarding-and-wallets/sponsored-transactions.md) for the full picture. In short: * **Zero-balance accounts can transact.** A Kernel smart account holding 0 PEPU sends a transaction and the paymaster pays, through the hosted [Alto](https://github.com/pimlicolabs/alto) bundler and ERC-7677 policy service. * **Hosted URLs:** bundler `https://bundler.pepeunchained.com`, paymaster service `https://paymaster.pepeunchained.com`; the ERC-7677 URL is `https://paymaster.pepeunchained.com/v2/paymaster/`. SDKs built around "construct a UserOperation, hand it to a bundler client" (permissionless.js, ZeroDev, Pimlico) can point at the bundler. The chain's standard RPC endpoints do not implement the ERC-4337 bundler methods. * **You must bring a project:** the free tier needs a verified Privy token from PEPU's own Privy app and is not available to third-party apps. Your app claims a project, sets targets and limits, deposits and gets a token. See [Sponsorship Tiers](/onboarding-and-wallets/sponsorship-tiers.md). Deposits are one-way, so deposit only what your project needs. ## The manual path, and when it makes sense `EntryPoint.handleOps()` is an ordinary public function. A determined developer can construct a UserOperation by hand, sign it with a Kernel account's owner key, and submit it in a plain transaction from any funded EOA, acting as a single-operation bundler. It is a valid use of the deployed contracts and exercises a Kernel account without a hosted bundler. It is also low-level and easy to get wrong (UserOperation hashing, gas-limit packing and signature encoding must match the EntryPoint's expectations exactly), and the submitting EOA pays real gas, with no sponsorship shortcut. Treat it as a way to validate the infrastructure or build tooling on it, not a path for a typical app. For popup-free interaction, use [Session Keys](/onboarding-and-wallets/session-keys.md), which works on a plain embedded wallet. ## Related * [Sponsored Transactions](/onboarding-and-wallets/sponsored-transactions.md) * [The Two-Address Model](/onboarding-and-wallets/two-address-model.md) * [Session Keys](/onboarding-and-wallets/session-keys.md) * [Privy Setup](/privy/privy-setup.md) * [Deployed Contracts](/contracts-and-addresses/deployed-contracts.md) * [EntryPoints and Kernel](/contracts-and-addresses/entrypoints-and-kernel.md) * [Sponsored Session](/onboarding-and-wallets/sponsored-session.md): Kernel session keys on this stack --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.pepeunchained.com/onboarding-and-wallets/smart-accounts.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.