# ZeroDev > The most powerful smart account. ## Docs - [DeFi Integrations](/advanced/defi): ZeroDev partners with [Enso](https://www.enso.finance/) to support seamless token swaps and DeFi integrations, even across chains. - [Delegatecall](/advanced/delegatecall): `delegatecall` is very dangerous. Unless you know exactly what you are doing, don't do it, or you might risk losing all your funds. - [Deploying Contracts](/advanced/deploy-contract): Impatient? Check out [complete examples here](https://github.com/zerodevapp/zerodev-examples/blob/main/deploy-contract/main.ts). - [Fallback Providers](/advanced/fallback-providers): Impatient? Check out [a complete example here](https://github.com/zerodevapp/zerodev-examples/blob/main/fallback-clients/main.ts). - [Key Storage](/advanced/key-storage): The remote signer feature is a paid add-on. Please [contact us](https://t.me/derek_chiang) before you use this feature in production, in order to avoid service disruptions. - [Migration Guide](/advanced/migration): With API v3, the notable changes are: - [Multi-chain Signing](/advanced/multi-chain-signing): You can use Kernel with a "multi-chain validator" which can sign multiple UserOps in one signature, even if the UserOps are on different chains. For example, if you want to bridge some assets from chain A, and then execute a transaction on chain B with the bridged assets, you can sign both the bridging transaction and the target transaction in a single signature. - [Parallel UserOps](/advanced/parallel-transactions): Impatient? Check out [a complete example here](https://github.com/zerodevapp/zerodev-examples/blob/main/send-transactions/with-2d-nonce.ts). - [Run code when creating an account](/advanced/track-deployed-accounts): Impatient? Check out [a complete example here](https://github.com/zerodevapp/zerodev-examples/blob/main/emit-event-when-creating-account/main.ts). - [Upgrading Kernel](/advanced/upgrade-kernel): Impatient? Check out [a complete example here](https://github.com/zerodevapp/zerodev-examples/blob/main/create-ecdsa-migration-account/main.ts). - [UserOp Builder API](/advanced/userop-builder-api): The UserOp Builder API provides a server-side solution for building and sending ERC-7702 User Operations with [Kernel smart accounts](https://docs.zerodev.app/sdk/core-api/create-account). It handles gas estimation, paymaster integration, and bundler submission—perfect for backend services that need to construct user operations without client-side SDKs. - [WalletConnect](/advanced/wallet-connect): The `@zerodev/walletconnect` Core SDK facilitates the connection between a WalletConnect-compatible wallet and a blockchain application, handling session proposals, requests, and responses. It leverages a kernel EIP1193 provider to sign transactions or messages. - [Quickstart](/get-started/quickstart): Create a new project with `npm` (or whatever package manager you use): - [Reflections on Ethereum Governance Following the 3074 Saga](/blog/3074-governance): [Vitalik](https://twitter.com/VitalikButerin) and [Yoav](https://twitter.com/yoavw) kindly reviewed this post, but opinions are my own. - [Why the process made people unhappy](/blog/3074-governance): [Vitalik](https://twitter.com/VitalikButerin) and [Yoav](https://twitter.com/yoavw) kindly reviewed this post, but opinions are my own. - [What went wrong?](/blog/3074-governance): [Vitalik](https://twitter.com/VitalikButerin) and [Yoav](https://twitter.com/yoavw) kindly reviewed this post, but opinions are my own. - [The Root Cause](/blog/3074-governance): [Vitalik](https://twitter.com/VitalikButerin) and [Yoav](https://twitter.com/yoavw) kindly reviewed this post, but opinions are my own. - [What is a roadmap?](/blog/3074-governance): [Vitalik](https://twitter.com/VitalikButerin) and [Yoav](https://twitter.com/yoavw) kindly reviewed this post, but opinions are my own. - [When core devs are misaligned with a roadmap](/blog/3074-governance): [Vitalik](https://twitter.com/VitalikButerin) and [Yoav](https://twitter.com/yoavw) kindly reviewed this post, but opinions are my own. - [The role of Vitalik](/blog/3074-governance): [Vitalik](https://twitter.com/VitalikButerin) and [Yoav](https://twitter.com/yoavw) kindly reviewed this post, but opinions are my own. - [Every successful product starts with a vision](/blog/3074-governance): [Vitalik](https://twitter.com/VitalikButerin) and [Yoav](https://twitter.com/yoavw) kindly reviewed this post, but opinions are my own. - [What about decentralization?](/blog/3074-governance): [Vitalik](https://twitter.com/VitalikButerin) and [Yoav](https://twitter.com/yoavw) kindly reviewed this post, but opinions are my own. - [The role of the community](/blog/3074-governance): [Vitalik](https://twitter.com/VitalikButerin) and [Yoav](https://twitter.com/yoavw) kindly reviewed this post, but opinions are my own. - [The VVRC model of Ethereum governance](/blog/3074-governance): [Vitalik](https://twitter.com/VitalikButerin) and [Yoav](https://twitter.com/yoavw) kindly reviewed this post, but opinions are my own. - [How can we improve Ethereum governance](/blog/3074-governance): [Vitalik](https://twitter.com/VitalikButerin) and [Yoav](https://twitter.com/yoavw) kindly reviewed this post, but opinions are my own. - [Conclusion](/blog/3074-governance): [Vitalik](https://twitter.com/VitalikButerin) and [Yoav](https://twitter.com/yoavw) kindly reviewed this post, but opinions are my own. - [The pitfalls of EIP-3074, and how to avoid them](/blog/3074-pitfalls): (Thanks to [Yoav Weiss](https://twitter.com/yoavw) and [Dan Finlay](https://twitter.com/danfinlay) for feedback and review.) - [Why 4337 and 3074 authors are disagreeing, and who got it right](/blog/4337-and-3074-disagreements): Update: Since this post was written, [EIP-7702](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7702.md) has been proposed to replace EIP-3074. This is a good outcome -- 7702 brings about the same benefits to EOAs as 3074, while addressing concerns from the 4337 team. This post remains helpful in explaining the disagreements that led to the creation of 7702. - [The Core Disagreements](/blog/4337-and-3074-disagreements): Update: Since this post was written, [EIP-7702](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7702.md) has been proposed to replace EIP-3074. This is a good outcome -- 7702 brings about the same benefits to EOAs as 3074, while addressing concerns from the 4337 team. This post remains helpful in explaining the disagreements that led to the creation of 7702. - [Should 4337/7560 be the “official end-game”?](/blog/4337-and-3074-disagreements): Update: Since this post was written, [EIP-7702](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7702.md) has been proposed to replace EIP-3074. This is a good outcome -- 7702 brings about the same benefits to EOAs as 3074, while addressing concerns from the 4337 team. This post remains helpful in explaining the disagreements that led to the creation of 7702. - [Why 3074 is at odds with censorship resistance](/blog/4337-and-3074-disagreements): Update: Since this post was written, [EIP-7702](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7702.md) has been proposed to replace EIP-3074. This is a good outcome -- 7702 brings about the same benefits to EOAs as 3074, while addressing concerns from the 4337 team. This post remains helpful in explaining the disagreements that led to the creation of 7702. - [Why 3074 and 7547 (inclusion lists) are mutually exclusive](/blog/4337-and-3074-disagreements): Update: Since this post was written, [EIP-7702](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7702.md) has been proposed to replace EIP-3074. This is a good outcome -- 7702 brings about the same benefits to EOAs as 3074, while addressing concerns from the 4337 team. This post remains helpful in explaining the disagreements that led to the creation of 7702. - [Is CR or UX the more urgent problem for Ethereum?](/blog/4337-and-3074-disagreements): Update: Since this post was written, [EIP-7702](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7702.md) has been proposed to replace EIP-3074. This is a good outcome -- 7702 brings about the same benefits to EOAs as 3074, while addressing concerns from the 4337 team. This post remains helpful in explaining the disagreements that led to the creation of 7702. - [Why UX is an urgent problem](/blog/4337-and-3074-disagreements): Update: Since this post was written, [EIP-7702](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7702.md) has been proposed to replace EIP-3074. This is a good outcome -- 7702 brings about the same benefits to EOAs as 3074, while addressing concerns from the 4337 team. This post remains helpful in explaining the disagreements that led to the creation of 7702. - [How Ethereum Governance Works](/blog/4337-and-3074-disagreements): Update: Since this post was written, [EIP-7702](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7702.md) has been proposed to replace EIP-3074. This is a good outcome -- 7702 brings about the same benefits to EOAs as 3074, while addressing concerns from the 4337 team. This post remains helpful in explaining the disagreements that led to the creation of 7702. - [Conclusion](/blog/4337-and-3074-disagreements): Update: Since this post was written, [EIP-7702](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7702.md) has been proposed to replace EIP-3074. This is a good outcome -- 7702 brings about the same benefits to EOAs as 3074, while addressing concerns from the 4337 team. This post remains helpful in explaining the disagreements that led to the creation of 7702. - [What does EIP-7702 mean for YOU? Part 1 -- The Adoption Cycle of 7702](/blog/7702-adoption): [This article was originally published on X.](https://x.com/decentrek/status/1846216581979734156) - [What does EIP-7702 mean for YOU? Part 2 -- DApp Developers](/blog/7702-for-dapps): [This article was originally published on X.](https://x.com/decentrek/status/1900231172640432580) - [Quick overview of EIP-7702](/blog/7702-for-dapps): [This article was originally published on X.](https://x.com/decentrek/status/1900231172640432580) - [Two types of DApps](/blog/7702-for-dapps): [This article was originally published on X.](https://x.com/decentrek/status/1900231172640432580) - [EIP-7702 for Open DApps](/blog/7702-for-dapps): [This article was originally published on X.](https://x.com/decentrek/status/1900231172640432580) - [Do I need to know 100 different ERCs to use EIP-7702?](/blog/7702-for-dapps): [This article was originally published on X.](https://x.com/decentrek/status/1900231172640432580) - [EIP-7702 for Closed DApps](/blog/7702-for-dapps): [This article was originally published on X.](https://x.com/decentrek/status/1900231172640432580) - [Conclusion](/blog/7702-for-dapps): [This article was originally published on X.](https://x.com/decentrek/status/1900231172640432580) - [ERC-4337 — Misconceptions and Valid Concerns](/blog/erc-4337-misconceptions-and-valid-concerns): At ZeroDev, it’s our job to help devs learn and adopt AA, so naturally we have come across a lot of questions, concerns, and objections. - [Misconceptions](/blog/erc-4337-misconceptions-and-valid-concerns): **Misconceptions**: things that are just not true. - [Yes and No](/blog/erc-4337-misconceptions-and-valid-concerns): **Misconceptions**: things that are just not true. - [Valid Concerns](/blog/erc-4337-misconceptions-and-valid-concerns): **Misconceptions**: things that are just not true. - [The Bottom Line](/blog/erc-4337-misconceptions-and-valid-concerns): **Misconceptions**: things that are just not true. - [What is ERC-6492 and why it’s important for Account Abstraction](/blog/erc-6492-and-why-its-important-for-aa): Unless you check new ERCs everyday (in which case, good for you), you probably haven’t noticed this new ERC known as [ERC-6492](https://eips.ethereum.org/EIPS/eip-6492), innocuously named "Signature Validation for Predeploy Contracts.” As this post is going to argue, ERC-6492 is critical to the wide adoption of account abstraction and smart contract wallets in general. - [Terminology](/blog/erc-6492-and-why-its-important-for-aa): For brevity, I will be using the following pairs of terms interchangeably, even though it’s not technically accurate: - [The Context](/blog/erc-6492-and-why-its-important-for-aa): “AA” and “ERC-4337” - [The Issue](/blog/erc-6492-and-why-its-important-for-aa): “AA” and “ERC-4337” - [Consequences](/blog/erc-6492-and-why-its-important-for-aa): “AA” and “ERC-4337” - [Solution](/blog/erc-6492-and-why-its-important-for-aa): “AA” and “ERC-4337” - [Next Steps](/blog/erc-6492-and-why-its-important-for-aa): “AA” and “ERC-4337” - [The Gas Sponsorship Paradox: Why Web3’s Biggest Technical Hurdle is Actually Your Biggest Growth Hack](/blog/gas-sponsorship-paradox): Imagine launching an incredible new SaaS product, only to demand that every single user first open a separate, complex bank account, buy a small amount of a specific, volatile foreign currency, and then manually transfer that currency into your platform just to click the first button. - [How Gemini Built a Universal Smart Wallet Using the ZeroDev WebAuthn Validator](/blog/gemini): At ZeroDev, we believe in the power of open standards and modular architecture. That's why we built [Kernel](https://github.com/zerodevapp/kernel), our flagship smart account, on top of [ERC-7579](https://erc7579.com/) - the modular smart account standard that's rapidly becoming the foundation for next-generation wallets across the Ethereum ecosystem. - [The Performance Leap: ZeroDev Unlocks Go-Native Account Abstraction for Mission-Critical Web3 Scale.](/blog/go-native-account-abstraction): The **long-awaited native Account Abstraction solution** for mission-critical, Go-powered infrastructure is finally here. - [SDKs are dead; long live capabilities](/blog/hello-capabilities): Building with AA is great… or is it? While the benefits of AA are well-known, people who have actually tried to build with AA know that the developer experience is far from optimal. - [Why building with AA sucks right now](/blog/hello-capabilities): The issues with using AA right now. - [Bye-bye SDKs, Hello Capabilities](/blog/hello-capabilities): The issues with using AA right now. - [What are capabilities?](/blog/hello-capabilities): The issues with using AA right now. - [How do you use capabilities?](/blog/hello-capabilities): The issues with using AA right now. - [Why capabilities are great](/blog/hello-capabilities): The issues with using AA right now. - [Why capabilities now?](/blog/hello-capabilities): The issues with using AA right now. - [What does this mean for ZeroDev?](/blog/hello-capabilities): The issues with using AA right now. - [Conclusion](/blog/hello-capabilities): The issues with using AA right now. - [ZeroDev Blog](/blog) - [Introducing Orchestra — Multi-chain Contract Deployment Made Easy](/blog/introducing-orchestra-multichain-deployment-made-easy): At ZeroDev, we deploy a lot of contracts. Every release of [Kernel](https://github.com/zerodevapp/kernel) or [a plugin](https://docs.zerodev.app/use-wallets/overview) involves deploying contracts on 10+ networks, including both mainnets and testnets. This is a super tedious process because we have to acquire gas tokens on all these networks; testnet tokens, in particular, can be hard to acquire due to faucet limits. - [How it works](/blog/introducing-orchestra-multichain-deployment-made-easy): How is Orchestra able to deploy contracts on multiple chains without requiring tokens for each chain? You guessed it — ERC-4337 paymasters. - [Limitations](/blog/introducing-orchestra-multichain-deployment-made-easy): We have successfully employed Orchestra to deploy multiple plugins, cutting the deployment time from hours to minutes. However, the tool can still be improved: - [Get Started](/blog/introducing-orchestra-multichain-deployment-made-easy): Orchestra currently uses only ZeroDev infra, but it can in principle work with any AA infra. We welcome PRs to add support for other infra providers such as StackUp, Pimlico, Alchemy, etc. - [Introducing Kernel — Minimal & Extensible Smart Contract Account for ERC-4337 Wallets](/blog/kernel-minimal-extensible-account-for-aa-wallets): With the launch of ERC-4337, we are seeing tremendous excitement from Web3 developers to build the next generation of crypto wallets using account abstraction. - [Introducing ](/blog/kernel-minimal-extensible-account-for-aa-wallets): Seeing this need, ZeroDev has developed an *account abstraction wallet kernel*. The term *kernel* comes from the lingo of operating systems. The Linux kernel, for example, is used by a wide range of operating systems such as Android, Raspberry Pi, etc. The reason why the Linux kernel exists is so that different operations systems do not have to build the basic OS functionalities (e.g. file systems and networking) from scratch. Rather, operating systems builders can focus on building the OS *features* that make the OS unique, whether it’s great UI, integration with popular apps, or whatnot. - [Kernel ](/blog/kernel-minimal-extensible-account-for-aa-wallets): Compatibility with ERC-4337 - [Kernel makes it easy for users to ](/blog/kernel-minimal-extensible-account-for-aa-wallets): Compatibility with ERC-4337 - [Kernel vs Safe](/blog/kernel-minimal-extensible-account-for-aa-wallets): Compatibility with ERC-4337 - [Kernel, ERC-6900, and Interoperability](/blog/kernel-minimal-extensible-account-for-aa-wallets): Compatibility with ERC-4337 - [Start building on Kernel now](/blog/kernel-minimal-extensible-account-for-aa-wallets): Compatibility with ERC-4337 - [Kernel v2 and the Lessons We Learned](/blog/kernel-v2-and-the-lessons-we-learned): Ever since releasing [Kernel v1](https://twitter.com/zerodev_app/status/1650936162436128769), we have seen a flurry of activities from developers building novel plugins on Kernel. However, developers soon ran into significant limitations that exposed some of the shortcomings of Kernel, which prompted us to start working on Kernel v2. - [Scaling the Future of Account Abstraction: Introducing ZeroDev Credits](/blog/pricing-update): We have an exciting update to share about how ZeroDev is evolving to support the next generation of our platform! - [Session Keys are the JWTs of Web3](/blog/session-keys-are-the-jwts-of-web3): Web3 UX today faces many challenges. High gas costs, long transaction times, and difficulties managing seed phrases are some of the most common issues that many projects, including ZeroDev, strive to fix. - [Authentication vs Authorization](/blog/session-keys-are-the-jwts-of-web3): Before we delve deeper, let's clarify the difference between authentication and authorization. - [Authorization on Web2](/blog/session-keys-are-the-jwts-of-web3): Authentication is the process of proving *who you are*. For instance, if you arrive at an NFT drop that you've been whitelisted for, how do you prove that you have indeed been whitelisted? Typically, the NFT drop will request you to sign a message. By cryptographically signing this message, you are *authenticating* to prove ownership of the whitelisted wallet. - [Authorization is broken on Web3](/blog/session-keys-are-the-jwts-of-web3): Authentication is the process of proving *who you are*. For instance, if you arrive at an NFT drop that you've been whitelisted for, how do you prove that you have indeed been whitelisted? Typically, the NFT drop will request you to sign a message. By cryptographically signing this message, you are *authenticating* to prove ownership of the whitelisted wallet. - [Use the wallet, duh](/blog/session-keys-are-the-jwts-of-web3): Authentication is the process of proving *who you are*. For instance, if you arrive at an NFT drop that you've been whitelisted for, how do you prove that you have indeed been whitelisted? Typically, the NFT drop will request you to sign a message. By cryptographically signing this message, you are *authenticating* to prove ownership of the whitelisted wallet. - [Session Keys are the JWTs of Web3](/blog/session-keys-are-the-jwts-of-web3): Authentication is the process of proving *who you are*. For instance, if you arrive at an NFT drop that you've been whitelisted for, how do you prove that you have indeed been whitelisted? Typically, the NFT drop will request you to sign a message. By cryptographically signing this message, you are *authenticating* to prove ownership of the whitelisted wallet. - [Empowering DApps with session keys](/blog/session-keys-are-the-jwts-of-web3): Authentication is the process of proving *who you are*. For instance, if you arrive at an NFT drop that you've been whitelisted for, how do you prove that you have indeed been whitelisted? Typically, the NFT drop will request you to sign a message. By cryptographically signing this message, you are *authenticating* to prove ownership of the whitelisted wallet. - [Use session keys with ZeroDev today](/blog/session-keys-are-the-jwts-of-web3): Authentication is the process of proving *who you are*. For instance, if you arrive at an NFT drop that you've been whitelisted for, how do you prove that you have indeed been whitelisted? Typically, the NFT drop will request you to sign a message. By cryptographically signing this message, you are *authenticating* to prove ownership of the whitelisted wallet. - [Towards the Most Optimized AA Wallet](/blog/towards-the-most-optimized-aa-wallet): At ZeroDev, we are obsessed with smart contract wallets (SCW), as we believe they are [necessary for realizing the full potential of Web3](https://vitalik.eth.limo/general/2023/06/09/three_transitions.html). One practical roadblock towards a wider adoption of SCW and AA, however, is the fact that SCWs cost gas to deploy. In contrast, to create an EOA, it costs nothing — the account simply *exists* once you generate a private key. - [Optimizing Kernel](/blog/towards-the-most-optimized-aa-wallet): When we first measured the gas efficiency of Kernel (v2), we were disappointed to find that it lagged behind some other implementations out there. The main reason, we quickly realized, was that there was a tension between performance and modularity. By [supporting plugins in Kernel](https://docs.zerodev.app/extend-wallets/overview), we also sacrificed some gas efficiency since the code that dispatches to plugins necessarily introduces some gas overhead. That’s why Kernel used more gas than simpler SCW implementations that don’t support plugins. - [Open-sourcing the Benchmark](/blog/towards-the-most-optimized-aa-wallet): Proxies are cheaper to deploy, since the proxy contract itself contains minimal logic. - [Account abstraction beyond ERC-4337 -- how intents (ERC-7683) can make AA cheaper & faster](/blog/ultrarelay): [This article was originally published on X.](https://x.com/decentrek/status/1879575439011979563) - [What Can You Do with Account Abstraction?](/blog/what-can-you-do-with-account-abstraction): As the saying goes, the only constant in Web3 is change. If you are building a Web3 product, you need to stay on top of technological trends, in order to identify new opportunities to grow and improve your product. - [Who, when, what — a framework for thinking about plugins, and 7579 vs 6900](/blog/who-when-what): In our [last blog post](https://docs.zerodev.app/blog/why-7579-over-6900), we argued in favor of ERC-7579 over ERC-6900 as a standard for modular smart accounts. The blog generated a lot of healthy debate, including [a detailed response](https://mirror.xyz/probablynoam.eth/ZM8k-YoVbC-ih13zPMPZ5q4iZ7wEHuWEcRbQNrRiURU) from Noam at Alchemy. - [Who, when, what](/blog/who-when-what): Every use case of smart account plugins must answer three questions: who, when, and what. - [Who puts the pieces together?](/blog/who-when-what): *Who* is authorized to perform this action? - [Which approach is reasonable?](/blog/who-when-what): *Who* is authorized to perform this action? - [Last words](/blog/who-when-what): *Who* is authorized to perform this action? - [Why we are building Kernel on ERC-7579 (and not ERC-6900)](/blog/why-7579-over-6900): (Update: we published [a follow-up blog post](https://docs.zerodev.app/blog/who-when-what). Noam from Alchemy published [a response](https://mirror.xyz/probablynoam.eth/ZM8k-YoVbC-ih13zPMPZ5q4iZ7wEHuWEcRbQNrRiURU).) - [Offchain Labs acquires ZeroDev](/blog/zerodev-acquired): Today we are excited to share that ZeroDev has been acquired by [Offchain Labs](https://www.offchainlabs.com/), the creator of Arbitrum. - [Case Study: How Glider Uses ZeroDev to Automate Cross-Chain Portfolio Management](/blog/zerodev-glider): *This post is a collaboration with Glider.* - [Case Study: Combining Smart Accounts with Secure Automation](/blog/zerodev-litprotocol): *This post is a collaboration with Lit Protocol.* - [Export Wallet](/wallets/export): Let users export their seed phrase or private key - [ZeroDev Wallet](/wallets): Smart embedded wallet for your app - [Quickstart](/wallets/quickstart): Get up and running in 5 minutes - [Session Management](/wallets/session-management): Understand and control the session lifecycle - [Batching Transactions](/smart-accounts/batch-transactions): Impatient? Check out [complete examples here](https://github.com/zerodevapp/zerodev-examples/tree/main/batch-transactions). - [Creating a Smart Account](/smart-accounts/create-a-smart-account): Impatient? Check out [a complete example here](https://github.com/zerodevapp/zerodev-examples/blob/main/create-account/main.ts). - [Paying Gas with ERC20s](/smart-accounts/pay-gas-with-erc20s): Impatient? Check out [complete examples here](https://github.com/zerodevapp/zerodev-examples/tree/main/pay-gas-with-erc20). - [Sending Transactions](/smart-accounts/send-transactions): Impatient? Check out [complete examples here](https://github.com/zerodevapp/zerodev-examples/tree/main/send-transactions). - [Signing and Verifying Messages](/smart-accounts/sign-and-verify): Signing and verifying messages for smart accounts is different than with EOAs. There are a few reasons why: - [Getting Started](/advanced/react-hooks/getting-started): ZeroDev's React SDK is called `@zerodev/waas`, which stands for Wallet-as-a-Service. This is to signal that the React SDK provides higher-level abstractions over the [low-level SDK](/). - [useBalance](/advanced/react-hooks/use-balance): Hook for getting balance of kernel account - [useChainId](/advanced/react-hooks/use-chainid): Hook for getting current connected chain id - [useChains](/advanced/react-hooks/use-chains): Hook for getting configured chains - [useCreateBasicSession](/advanced/react-hooks/use-create-basic-session): Hook for creating session for kernel v2 account - [useCreateKernelClientEOA](/advanced/react-hooks/use-create-kernelclient-eoa): Hook for creating kernel client with EOA - [useCreateKernelClientPasskey](/advanced/react-hooks/use-create-kernelclient-passkey): Hook for creating kernel client with Passkey - [useCreateKernelClientSocial](/advanced/react-hooks/use-create-kernelclient-social): Hook for creating a kernel client with social login integration - [useCreateSession](/advanced/react-hooks/use-create-session): Hook for creating session for kernel v3 account - [useDisconnectKernelClient](/advanced/react-hooks/use-disconnect-kernelclient): Hook for disconnecting kernel account client - [useKernelClient](/advanced/react-hooks/use-kernelclient): Hook for getting kernel account client - [useSendTransactionWithSession](/advanced/react-hooks/use-send-transaction-with-session): Hooks for sending transactions with session keys - [useSendTransaction](/advanced/react-hooks/use-send-transaction): Hook for sending transaction - [useSendUserOperationWithSession](/advanced/react-hooks/use-send-useroperation-with-session): Hooks for sending user operation with session keys - [useSendUserOperation](/advanced/react-hooks/use-send-useroperation): Hook for sending user operation - [useSessionKernelClient](/advanced/react-hooks/use-session-kernelclient): Hook for getting kernel account client with session plugin - [useSessions](/advanced/react-hooks/use-sessions): Hook for getting sessions - [useSetKernelClient](/advanced/react-hooks/use-set-kernelclient): Hook for setting kernel account client - [useSwitchChain](/advanced/react-hooks/use-switch-chain): Hook for switching chain - [useWalletConnect](/advanced/react-hooks/use-wallet-connect): Do you want your users to be able to use their smart accounts with other DApps? If so, you can integrate ZeroDev with WalletConnect. - [Presets](/api-and-toolings/presets/intro): ZeroDev is highly modular and composable thanks to building on top of Viem, but sometimes it can feel like you are writing a lot of boilerplate code before you can set up a functional Kernel account. **Presets** are helper functions that help you set up Kernel accounts with common configurations, including connections to bundlers and paymasters. - [ZeroDev Presets](/api-and-toolings/presets/zerodev): To set up a Kernel account using ECDSA for validation (mimicking EOAs): - [Admin API](/api-and-toolings/infrastructure/api): ZeroDev infra can be configured through APIs. [Check out all our APIs here.](https://zerodev-api.readme.io/reference/getaddresbyeoav2) - [Choosing an infra provider](/api-and-toolings/infrastructure/choose-an-infra-provider): ZeroDev is compatible with any account abstraction infra provider. Check out these guides for integrating with a specific provider: - [Coinbase Developer Platform](/api-and-toolings/infrastructure/coinbase): [Coinbase Developer Platform](https://docs.cdp.coinbase.com/) (CDP) offers bundler and paymaster services that you can use with ZeroDev. - [Custom Gas Policies](/api-and-toolings/infrastructure/custom-gas-policies): Custom gas policies enable you to tailor your sponsorship criteria using a webhook. This feature allows you to set up a custom policy that calls a URL you provide to determine whether to sponsor a transaction. - [Gas Policies](/api-and-toolings/infrastructure/gas-policies): You can configure **gas policies** for ZeroDev paymaster to have fine-grained control over what you sponsor, and how much. - [Meta AA Infrastructure](/api-and-toolings/infrastructure/intro): ZeroDev works with major AA infra providers to provide a "meta intrastructure." Our meta infra proxies traffic to the underlying bundlers and paymasters, ensuring that our users have the highest possible uptime, since traffic can be routed to a different bundler when one goes down. - [Pimlico](/api-and-toolings/infrastructure/pimlico): You can use the ZeroDev SDK with Pimlico bundlers. - [Bundler & Paymaster RPCs](/api-and-toolings/infrastructure/rpcs): To ensure utmost reliability for our customers, our RPCs use multiple bundlers under the hood, including: - [ZeroDev](/api-and-toolings/infrastructure/zerodev): ZeroDev provides a meta infrastructure that proxies traffic to multiple infra providers including Alchemy, Gelato and Pimlico. [Read more here](/api-and-toolings/infrastructure/intro). - [ZeroDev Audits](/api-and-toolings/faqs/audits): All ZeroDev contracts and plugins are audited unless otherwise noted. - [Supported Networks](/api-and-toolings/faqs/chains): Since we need to update this list manually, it may be missing some networks that we support. To see a complete list, check out [our dashboard](https://dashboard.zerodev.app/). - [Debugging UserOps with Tenderly](/api-and-toolings/faqs/debug-userop): In account abstraction (ERC-4337), the transactions sent by smart accounts are known as "UserOps." UserOps are similar to but not the same as regular transactions, so it may not be clear how to debug them. - [Can I Use a KernelClient with Ethers?](/api-and-toolings/faqs/use-with-ethers): Our KernelClient implements the Viem WalletClient interface. Although it is not directly compatible with Ethers.js, we have developed an EIP1193Provider that accepts a KernelClient as a constructor parameter. This provider enables the use of KernelClient with Ethers.js in a similar manner to how window.ethereum is utilized with Ethers.js. - [Using ZeroDev with Gelato](/api-and-toolings/faqs/use-with-gelato): Gelato's has a unique approach to handling transaction fees without the need for an EntryPoint deposit or an on-chain paymaster. Instead, transaction fees are settled post-execution via [1Balance](https://docs.gelato.network/web3-services/relay/subscriptions-and-payments/1balance-and-relay) across all supported networks, ensuring accurate charging of gas consumed without necessitating per-chain user deposits. - [Using ZeroDev with React Native](/api-and-toolings/faqs/use-with-react-native): ZeroDev works great in React Native. Our user Stephen Gordon has helpfully made starter templates for: - [UserOp Debugger](/api-and-toolings/tools/debugger): ZeroDev ships a web-based UserOp debugger at [debug.zerodev.app](https://debug.zerodev.app). Unlike similar tools on the market, the ZeroDev debugger has some major advantages: - [Status API](/api-and-toolings/tools/status): ZeroDev provides a status API for monitoring uptime and performance metrics of RPC endpoints across different chains. - [SDKs](/get-started/sdks/overview): ZeroDev ships SDKs for browser, mobile, and server-side stacks. Most non-TypeScript bindings are powered by the **[Omni SDK](https://github.com/zerodevapp/zerodev-omni-sdk)** — a single Zig core exposed through C FFI, with first-class language bindings for Swift, Kotlin, Go, Rust, Python, and C. Pick the one that matches your runtime. - [Set up a project](/get-started/sdks/setup-project): Before integrating any ZeroDev SDK, create a project on the ZeroDev dashboard and configure a gas-sponsorship policy. The project gives you an RPC URL that the SDKs use to talk to ZeroDev's bundler and paymaster. - [Smart Routing Address](/cross-chain/smart-routing-address): **Smart Routing Address** enables users to easily deposit funds from any source—CEX, fiat onramp, or any chain—to any destination chain, simply by sending funds to a unique deposit address. - [Chain abstraction](/cross-chain/chain-abstraction/overview): ZeroDev is the first smart account solution to support *cross-chain transactions,* also sometimes known as "chain abstraction." - [Supported Base Tokens](/cross-chain/chain-abstraction/supported-base-tokens): This is the full list of base tokens supported by ZeroDev's [DeFi integrations](/advanced/defi). - [Supported Defi Tokens](/cross-chain/chain-abstraction/supported-defi-tokens): This is the full list of DeFi tokens (aka "vaults") supported by ZeroDev's [DeFi integrations](/advanced/defi). - [ZeroDev Introduction](/sdk/v5_3_x): ZeroDev is a **chain-abstracted smart account** for building user-friendly Web3 experiences. - [Email OTP Authentication](/wallets/auth/email-otp): Authenticate with a one-time code sent by email - [Google OAuth](/wallets/auth/google-oauth): Authenticate with Google sign-in - [Magic Link Authentication](/wallets/auth/magic-link): Authenticate with a link sent by email - [Passkey Authentication](/wallets/auth/passkeys): Register and login with WebAuthn passkeys - [useAuthenticateOAuth](/wallets/hooks/use-authenticate-oauth): Hook for authenticating with an OAuth provider - [useExportPrivateKey](/wallets/hooks/use-export-private-key): Hook for exporting a private key - [useExportWallet](/wallets/hooks/use-export-wallet): Hook for exporting the wallet seed phrase - [useGetUserEmail](/wallets/hooks/use-get-user-email): Hook for getting the authenticated user's email - [useLoginPasskey](/wallets/hooks/use-login-passkey): Hook for logging in with an existing passkey - [useRefreshSession](/wallets/hooks/use-refresh-session): Hook for manually refreshing the current session - [useRegisterPasskey](/wallets/hooks/use-register-passkey): Hook for registering a new passkey wallet - [useSendMagicLink](/wallets/hooks/use-send-magic-link): Hook for sending a magic link email - [useSendOTP](/wallets/hooks/use-send-otp): Hook for sending a one-time verification code - [useVerifyMagicLink](/wallets/hooks/use-verify-magic-link): Hook for verifying a magic link and authenticating - [useVerifyOTP](/wallets/hooks/use-verify-otp): Hook for verifying a one-time code and authenticating - [Send a Transaction](/wallets/wallet-api/send-transaction): Gasless transactions with Wagmi hooks - [Sign a Message](/wallets/wallet-api/sign-message): Sign messages with Wagmi hooks - [Sign a Typed Message](/wallets/wallet-api/sign-typed-message): EIP-712 typed data signing - [Recovery Flow](/smart-accounts/account-recovery/flow-intro): ZeroDev provides a set of pre-built UIs to quickly integrate account recovery into your project. These are collectively referred to as "recovery flow." - [Recovery Setup](/smart-accounts/account-recovery/flow-setup): [Follow instructions here to set up the recovery flow.](https://github.com/zerodevapp/recovery-flow) - [Recovery Portal](/smart-accounts/account-recovery/portal): The recovery portal is a hosted UI where Kernel account owners can recover their accounts, if they have set up recovery. - [Recovery](/smart-accounts/account-recovery/sdk-recovery): With Kernel's [permissions system](/smart-accounts/permissions/intro), it's possible to set up a guardian (or multiple guardians) for a smart account, so that if the owner loses their key, the guardian(s) can recover the key for the owner. - [Quickstart -- EIP-7702](/smart-accounts/eip-7702/quickstart): [EIP-7702](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7702.md) is an Ethereum upgrade that allows for attaching a piece of EVM code to a EOA, effectively turning it into a "dual account" that can function simultaneously as a EOA and a smart account. You can learn more about EIP-7702 from our blog series [here](/blog/7702-adoption) and [here](/blog/7702-for-dapps). - [Use Arcana Auth with ZeroDev](/smart-accounts/authentication/arcana): [Arcana Auth](https://www.arcana.network/) offers a self-custodial Web3 wallet embedded within applications, utilizing asynchronous distributed key generation algorithms for enhanced security and privacy. This wallet, accessible without the need for a browser extension, allows authenticated users to instantly access and sign blockchain transactions within the app environment. - [Use Para with ZeroDev](/smart-accounts/authentication/capsule): [Para](https://getpara.com/) offers a signing solution enabling the creation of secure, embedded MPC wallets accessible via email or social login. These wallets, compatible across different applications, offer portability, recoverability, and programmability, eliminating the need for users to establish separate signers or contract accounts for each application. - [Custom Signer Integration](/smart-accounts/authentication/custom-signer): ZeroDev offers the flexibility to integrate various types of signers, catering to diverse application requirements. - [Use Dfns with ZeroDev](/smart-accounts/authentication/dfns): [Dfns](https://www.dfns.co/) is an MPC/TSS Wallet-as-a-Service API/SDK provider. Dfns aims to optimize the balance of security and UX by deploying key shares into a decentralized network on the backend while enabling wallet access via biometric open standards on the frontend like Webauthn. Reach out [here](https://www.dfns.co/learn-more) to set up a sandbox environment to get started. - [Use Dynamic with ZeroDev](/smart-accounts/authentication/dynamic): [Dynamic](https://www.dynamic.xyz/) is a platform that offers Web3 login solutions designed for easy integration and user-friendly experiences. It features [passkey embedded wallets](https://www.dynamic.xyz/features/embedded-wallets), crypto-native login, and profile and multi-wallet management. Additionally, the platform provides tools for authorization, orchestration, and more, aiming to streamline wallet-based authentication and identity management. Dynamic is built to cater to both casual users and crypto-savvy individuals, emphasizing non-custodial, passwordless, and flexible login options. - [Use an EOA with ZeroDev](/smart-accounts/authentication/eoa): An Externally Owned Account (EOA) is a standard Ethereum account operated via a private key. It's commonly used in wallets like MetaMask. ZeroDev is compatible with EOAs as signers, and the method of integrating an EOA varies based on your dApp's connection approach. - [Use Fireblocks with ZeroDev](/smart-accounts/authentication/fireblocks): [Fireblocks](https://www.fireblocks.com/) is a user-friendly platform designed for building blockchain-based products and managing digital asset operations. It uses a direct custody approach, combining high performance with zero counterparty risk and multi-layered security. The platform includes secure MPC-based digital asset wallets, a policy engine for governance and transaction rules, and comprehensive treasury management. Fireblocks' security framework features multiple layers, including MPC-CMP technology, secure enclaves, and a robust policy engine, ensuring protection against cyberattacks, internal threats, and human errors. It's widely used for various operations like treasury, trading, and managing NFTs, smart contracts, and user wallets. - [Use Lit Protocol with ZeroDev](/smart-accounts/authentication/lit-protocol): [Lit Protocol](https://www.litprotocol.com/) is distributed cryptography for signing, encryption, and compute. A generalizable key management network, Lit provides you with a set of tools for managing sovereign identities on the open Web. - [Use Magic with ZeroDev](/smart-accounts/authentication/magic): [Magic](https://magic.link/) is a popular embedded wallet provider that supports social logins. While social logins are great, your users still need to onramp in order to pay for gas, which introduces significant friction. - [Use Particle Network with ZeroDev](/smart-accounts/authentication/particle): [Particle Network](https://particle.network/) is an intent-centric, modular wallet-as-a-service (WaaS). By utilizing MPC-TSS for key management, Particle can streamline onboarding via familiar Web2 methods such as Google, emails, and phone numbers. - [Use Portal with ZeroDev](/smart-accounts/authentication/portal): [Portal](https://www.portalhq.io/) is an embedded blockchain infrastructure company that powers companies with an end to end platform for key management for self-custodial wallets (MPC and AA), security firewall, and web3 protocol connect kit. - [Use Privy with ZeroDev](/smart-accounts/authentication/privy): [Privy](https://privy.io/) offers a seamless user onboarding experience for both mobile and desktop platforms, accommodating users with or without existing wallets. It simplifies the process of setting up self-custodial wallets for users logging in via email, SMS, or social media accounts. Additionally, it provides flexibility for web3-savvy users to continue using their existing wallets with your application, offering them a choice based on their preference. - [Use a Smart Wallet as a Signer](/smart-accounts/authentication/smart-wallet): ZeroDev supports using one smart wallet (kernel account) as a signer for another kernel account. - [Social Login](/smart-accounts/authentication/social-login): Social login allows users to authenticate using their existing social media accounts such as Google or Facebook. - [Use Turnkey with ZeroDev](/smart-accounts/authentication/turnkey): [Turnkey](https://turnkey.com/) is a key infrastructure provider with a great developer API and a powerful security policy engine. - [Use Web3Auth with ZeroDev](/smart-accounts/authentication/web3auth): [Web3Auth](https://web3auth.io/) is a popular embedded wallet provider that supports social logins. While social logins are great, your users still need to onramp in order to pay for gas, which introduces significant friction. - [Multisig](/smart-accounts/use-plugins/multisig): Impatient? Check out our examples: - [Using Plugins](/smart-accounts/use-plugins/overview): ZeroDev is built on [Kernel](https://github.com/zerodevapp/kernel), a *modular smart account* that can be extended with *plugins* (sometimes also called *modules*). - [Auth Providers](/smart-accounts/use-plugins/signers-intro): Smart accounts, like EOAs, rely on signatures to validate transactions and messages. The difference with smart accounts is that it can use arbitrary signatures schemes, such as multisig, passkeys, etc. - [Sponsoring Gas](/smart-accounts/sponsor-gas/evm): With account abstraction, you can pay gas for users so they don't have to acquire native tokens in order to interact with your DApp. - [Sponsor Gas on Solana](/smart-accounts/sponsor-gas/solana): With ZeroDev, you can sponsor transaction fees for your users on Solana, so they don't need to hold SOL to interact with your DApp. - [Tutorial -- Transaction Automation](/smart-accounts/permissions/1-click-trading): In this tutorial, you will learn how to enable 1-click trading for your app using session keys. - [Quickstart — ZeroDev × AgentKit (LangChain chatbot)](/smart-accounts/permissions/agentkit): **Goal**: build a minimal LangChain chatbot whose on-chain wallet is a ZeroDev smart account, all in 50 lines of code. - [Installing Permissions During Account Creation](/smart-accounts/permissions/install-with-init-config): You can install permission plugins during account creation using `initConfig`. This approach allows you to set up permissions right when the account is deployed. - [Permissions (Session Keys)](/smart-accounts/permissions/intro): With Kernel, you can assign different permissions to different keys. Some of these keys might be owned by the owner(s) of the smart account, and some might be short-lived keys that you share with others to delegate transactions. The latter are also commonly known as "session keys." - [Session Keys](/smart-accounts/permissions/session-keys): Impatient? Check out [complete examples here](https://github.com/zerodevapp/zerodev-examples/blob/main/session-keys). - [Tutorial -- Transaction Automation](/smart-accounts/permissions/transaction-automation): In this tutorial, you will learn how to automate transactions for your users using [session keys](/smart-accounts/permissions/intro). This is useful when you want to send transactions for your users from your server, for instance. - [Android (Kotlin) SDK](/get-started/sdks/client-side/android): The ZeroDev Kotlin SDK is part of the [Omni SDK](https://github.com/zerodevapp/zerodev-omni-sdk) — a single Zig core shipped with first-class bindings for Kotlin, Swift, Go, Rust, Python, and C. The Android AAR bundles native libraries for arm64-v8a and x86\_64; the JVM JAR extracts the right native at runtime. It supports smart-account creation, signing, sponsored transactions, and EIP-7702 delegation on any EVM chain. - [iOS (Swift) SDK](/get-started/sdks/client-side/ios): The ZeroDev Swift SDK is part of the [Omni SDK](https://github.com/zerodevapp/zerodev-omni-sdk) — a single Zig core shipped with first-class bindings for Swift, Kotlin, Go, Rust, Python, and C. It supports smart-account creation, signing, sponsored transactions, and EIP-7702 delegation on any EVM chain. - [TypeScript / JavaScript SDK](/get-started/sdks/client-side/typescript): The ZeroDev TypeScript SDK (`@zerodev/sdk`) is the core package for building smart-account apps in JavaScript/TypeScript. This tutorial walks you through minting an NFT without paying gas. - [C SDK (FFI)](/get-started/sdks/server-side/c): The ZeroDev C SDK is the FFI surface of the [Omni SDK](https://github.com/zerodevapp/zerodev-omni-sdk) — a Zig core exposed as a C-compatible shared library. Use it to embed ZeroDev smart-account functionality from any language that can call C, including languages without a first-class Omni binding. It supports smart-account creation, signing, sponsored transactions, and EIP-7702 delegation on any EVM chain. - [Go SDK](/get-started/sdks/server-side/go): The ZeroDev Go SDK is part of the [Omni SDK](https://github.com/zerodevapp/zerodev-omni-sdk) — a single Zig core shipped with first-class bindings for Go, Swift, Kotlin, Rust, Python, and C. The module bundles precompiled static libraries for darwin/linux × arm64/amd64, so `go get` works without a Zig toolchain. It supports smart-account creation, signing, sponsored transactions, and EIP-7702 delegation on any EVM chain. - [Node.js / TypeScript SDK](/get-started/sdks/server-side/nodejs): 🚧 **This page is a stub.** Content is being written. - [Python SDK](/get-started/sdks/server-side/python): The ZeroDev Python SDK is part of the [Omni SDK](https://github.com/zerodevapp/zerodev-omni-sdk) — a single Zig core shipped with first-class bindings for Python, Swift, Kotlin, Go, Rust, and C. Published to PyPI as `zerodev-aa`, with native libraries bundled in the wheel for macOS (arm64, x86\_64) and Linux (x86\_64). It supports smart-account creation, signing, sponsored transactions, and EIP-7702 delegation on any EVM chain — ideal for backend services, scripts, and AI agents. - [Rust SDK](/get-started/sdks/server-side/rust): The ZeroDev Rust SDK is part of the [Omni SDK](https://github.com/zerodevapp/zerodev-omni-sdk) — a single Zig core shipped with first-class bindings for Rust, Swift, Kotlin, Go, Python, and C. Published to crates.io as `zerodev-aa`. The crate's `build.rs` auto-downloads precompiled native libraries from GitHub Releases — no Zig toolchain required to build. It supports smart-account creation, signing, sponsored transactions, and EIP-7702 delegation on any EVM chain. - [ZeroDev Audits](/sdk/v5_3_x/faqs/audits): All ZeroDev contracts and plugins are audited unless otherwise noted. - [Supported Networks](/sdk/v5_3_x/faqs/chains): ZeroDev supports EVM networks including: - [Debugging UserOps with Tenderly](/sdk/v5_3_x/faqs/debug-userop): In account abstraction (ERC-4337), the transactions sent by smart accounts are known as "UserOps." UserOps are similar to but not the same as regular transactions, so it may not be clear how to debug them. - [Can I Use a KernelClient with Ethers?](/sdk/v5_3_x/faqs/use-with-ethers): Our KernelClient implements the Viem WalletClient interface. Although it is not directly compatible with Ethers.js, we have developed an EIP1193Provider that accepts a KernelClient as a constructor parameter. This provider enables the use of KernelClient with Ethers.js in a similar manner to how window.ethereum is utilized with Ethers.js. - [Using ZeroDev with Gelato](/sdk/v5_3_x/faqs/use-with-gelato): Gelato's has a unique approach to handling transaction fees without the need for an EntryPoint deposit or an on-chain paymaster. Instead, transaction fees are settled post-execution via [1Balance](https://docs.gelato.network/web3-services/relay/subscriptions-and-payments/1balance-and-relay) across all supported networks, ensuring accurate charging of gas consumed without necessitating per-chain user deposits. This method relies on setting `maxFeePerGas=0`, thereby eliminating the need for upfront fee payments (`requiredPrefund=0`). - [Using ZeroDev with React Native](/sdk/v5_3_x/faqs/use-with-react-native): ZeroDev works great in React Native. Our user Stephen Gordon has helpfully made starter templates for: - [Chain Abstraction](/sdk/v5_3_x/advanced/chain-abstraction): Chain Abstraction is in public alpha and undergoing audit. Please [contact us](https://t.me/derek_chiang) if you plan on going live with it. - [DeFi Integrations](/sdk/v5_3_x/advanced/defi): ZeroDev partners with [Enso](https://www.enso.finance/) to support seamless token swaps and DeFi integrations, even across chains. - [Fallback Providers](/sdk/v5_3_x/advanced/fallback-providers): Impatient? Check out [a complete example here](https://github.com/zerodevapp/zerodev-examples/blob/main/fallback-clients/main.ts). - [Key Storage](/sdk/v5_3_x/advanced/key-storage): The remote signer feature is a paid add-on. Please [contact us](https://t.me/derek_chiang) before you use this feature in production, in order to avoid service disruptions. - [Multi-chain Signing](/sdk/v5_3_x/advanced/multi-chain-signing): You can use Kernel with a "multi-chain validator" which can sign multiple UserOps in one signature, even if the UserOps are on different chains. For example, if you want to bridge some assets from chain A, and then execute a transaction on chain B with the bridged assets, you can sign both the bridging transaction and the target transaction in a single signature. - [Multisig](/sdk/v5_3_x/advanced/multisig): Impatient? Check out [complete examples here](https://github.com/zerodevapp/zerodev-examples/tree/main/multisig). - [Parallel UserOps](/sdk/v5_3_x/advanced/parallel-orders): Impatient? Check out [a complete example here](https://github.com/zerodevapp/zerodev-examples/blob/main/send-transactions/with-2d-nonce.ts). - [Passkeys](/sdk/v5_3_x/advanced/passkeys): Passkeys are cryptographic key pairs created on end-user devices. [Apple](https://developer.apple.com/passkeys) and [Google](https://developers.google.com/identity/passkeys) are two major industry players pushing for the passkeys standard, which means that passkeys are widely available on consumer devices such as: - [Recovery](/sdk/v5_3_x/advanced/recovery): With Kernel's [permissions system](/sdk/v5_3_x/permissions/intro), it's possible to set up a guardian (or multiple guardians) for a smart account, so that if the owner loses their key, the guardian(s) can recover the key for the owner. - [Session Keys](/sdk/v5_3_x/advanced/session-keys): Impatient? Check out [complete examples here](https://github.com/zerodevapp/zerodev-examples/blob/main/session-keys). - [Social Login](/sdk/v5_3_x/advanced/social-login): Social login allows users to authenticate using their existing social media accounts such as Google or Facebook. - [Supported Base Tokens](/sdk/v5_3_x/advanced/supported-base-tokens): This is the full list of base tokens supported by ZeroDev's [DeFi integrations](/sdk/v5_3_x/advanced/defi). - [Supported Defi Tokens](/sdk/v5_3_x/advanced/supported-defi-tokens): This is the full list of DeFi tokens (aka "vaults") supported by ZeroDev's [DeFi integrations](/sdk/v5_3_x/advanced/defi). - [WalletConnect](/sdk/v5_3_x/advanced/wallet-connect): The `@zerodev/walletconnect` Core SDK facilitates the connection between a WalletConnect-compatible wallet and a blockchain application, handling session proposals, requests, and responses. It leverages a kernel EIP1193 provider to sign transactions or messages. - [Migration Guide](/sdk/v5_3_x/getting-started/migration): EntryPoint 0.7 is the most recent update to ERC-4337, but we will still be supporting EntryPoint 0.6. - [Quickstart](/sdk/v5_3_x/getting-started/quickstart): Create a new project with `npm` (or whatever package manager you use): - [ZeroDev Tutorial -- Passkeys](/sdk/v5_3_x/getting-started/tutorial-passkeys): In this tutorial, we will be building a Next.js app where your users can create smart accounts and send UserOps with [passkeys](/sdk/v5_3_x/advanced/passkeys). - [ZeroDev Tutorial](/sdk/v5_3_x/getting-started/tutorial): Impatient? Check out [the complete example here](https://github.com/zerodevapp/zerodev-examples/tree/main/tutorial/completed.ts). - [Batching Transactions](/sdk/v5_3_x/core-api/batch-transactions): Impatient? Check out [complete examples here](https://github.com/zerodevapp/zerodev-examples/tree/main/batch-transactions). - [Creating a Smart Account](/sdk/v5_3_x/core-api/create-account): Impatient? Check out [a complete example here](https://github.com/zerodevapp/zerodev-examples/blob/main/create-account/main.ts). - [Delegatecall](/sdk/v5_3_x/core-api/delegatecall): `delegatecall` is very dangerous. Unless you know exactly what you are doing, don't do it, or you might risk losing all your funds. - [Deploying Contracts](/sdk/v5_3_x/core-api/deploy-contract): Impatient? Check out [complete examples here](https://github.com/zerodevapp/zerodev-examples/blob/main/deploy-contract/main.ts). - [Paying Gas with ERC20s](/sdk/v5_3_x/core-api/pay-gas-with-erc20s): Impatient? Check out [complete examples here](https://github.com/zerodevapp/zerodev-examples/tree/main/pay-gas-with-erc20). - [Sending Transactions](/sdk/v5_3_x/core-api/send-transactions): Impatient? Check out [complete examples here](https://github.com/zerodevapp/zerodev-examples/tree/main/send-transactions). - [Signing and Verifying Messages](/sdk/v5_3_x/core-api/sign-and-verify): Signing and verifying messages for smart accounts is different than with EOAs. There are a few reasons why: - [Sponsoring Gas](/sdk/v5_3_x/core-api/sponsor-gas): With account abstraction, you can pay gas for users so they don't have to acquire native tokens in order to interact with your DApp. - [Using Plugins](/sdk/v5_3_x/core-api/using-plugins): ZeroDev is built on [Kernel](https://github.com/zerodevapp/kernel), a *modular smart account* that can be extended with *plugins* (sometimes also called *modules*). - [Coinbase Developer Platform](/sdk/v5_3_x/infra/coinbase): [Coinbase Developer Platform](https://docs.cdp.coinbase.com/) (CDP) offers bundler and paymaster services that you can use with ZeroDev. - [Choosing an infra provider](/sdk/v5_3_x/infra/intro): ZeroDev is compatible with any account abstraction infra provider. Check out these guides for integrating with a specific provider: - [Pimlico](/sdk/v5_3_x/infra/pimlico): [Pimlico](https://www.pimlico.io/) is a leading AA infra provider with a wide coverage of networks. - [ZeroDev](/sdk/v5_3_x/infra/zerodev): ZeroDev provides a meta infrastructure that proxies traffic to multiple infra providers including Alchemy, Gelato and Pimlico. [Read more here](/api-and-toolings/infrastructure/intro). - [Presets](/sdk/v5_3_x/presets/intro): ZeroDev is highly modular and composable thanks to building on top of Viem and Permissionless, but sometimes it can feel like you are writing a lot of boilerplate code before you can set up a functional Kernel account. **Presets** are helper functions that help you set up Kernel accounts with common configurations, including connections to bundlers and paymasters. - [ZeroDev Presets](/sdk/v5_3_x/presets/zerodev): To set up a Kernel account using ECDSA for validation (mimicking EOAs): - [Tutorial -- Transaction Automation](/sdk/v5_3_x/permissions/1-click-trading): In this tutorial, you will learn how to enable 1-click trading for your app using session keys. - [Permissions (Session Keys)](/sdk/v5_3_x/permissions/intro): With Kernel, you can assign different permissions to different keys. Some of these keys might be owned by the owner(s) of the smart account, and some might be short-lived keys that you share with others to delegate transactions. The latter are also commonly known as "session keys." - [Tutorial -- Transaction Automation](/sdk/v5_3_x/permissions/transaction-automation): In this tutorial, you will learn how to automate transactions for your users using [session keys](/sdk/v5_3_x/permissions/intro). This is useful when you want to send transactions for your users from your server, for instance. - [Use Arcana Auth with ZeroDev](/sdk/v5_3_x/signers/arcana): [Arcana Auth](https://www.arcana.network/) offers a self-custodial Web3 wallet embedded within applications, utilizing asynchronous distributed key generation algorithms for enhanced security and privacy. This wallet, accessible without the need for a browser extension, allows authenticated users to instantly access and sign blockchain transactions within the app environment. - [Use Capsule with ZeroDev](/sdk/v5_3_x/signers/capsule): [Capsule](https://usecapsule.com/) offers a signing solution enabling the creation of secure, embedded MPC wallets accessible via email or social login. These wallets, compatible across different applications, offer portability, recoverability, and programmability, eliminating the need for users to establish separate signers or contract accounts for each application. - [Custom Signer Integration](/sdk/v5_3_x/signers/custom-signer): ZeroDev offers the flexibility to integrate various types of signers, catering to diverse application requirements. - [Use Dfns with ZeroDev](/sdk/v5_3_x/signers/dfns): [Dfns](https://www.dfns.co/) is an MPC/TSS Wallet-as-a-Service API/SDK provider. Dfns aims to optimize the balance of security and UX by deploying key shares into a decentralized network on the backend while enabling wallet access via biometric open standards on the frontend like Webauthn. Reach out [here](https://www.dfns.co/learn-more) to set up a sandbox environment to get started. - [Use Dynamic with ZeroDev](/sdk/v5_3_x/signers/dynamic): [Dynamic](https://www.dynamic.xyz/) is a platform that offers Web3 login solutions designed for easy integration and user-friendly experiences. It features [passkey embedded wallets](https://www.dynamic.xyz/features/embedded-wallets), crypto-native login, and profile and multi-wallet management. Additionally, the platform provides tools for authorization, orchestration, and more, aiming to streamline wallet-based authentication and identity management. Dynamic is built to cater to both casual users and crypto-savvy individuals, emphasizing non-custodial, passwordless, and flexible login options. - [Use an EOA with ZeroDev](/sdk/v5_3_x/signers/eoa): An Externally Owned Account (EOA) is a standard Ethereum account operated via a private key. It's commonly used in wallets like MetaMask. ZeroDev is compatible with EOAs as signers, and the method of integrating an EOA varies based on your dApp's connection approach. - [Use Fireblocks with ZeroDev](/sdk/v5_3_x/signers/fireblocks): [Fireblocks](https://www.fireblocks.com/) is a user-friendly platform designed for building blockchain-based products and managing digital asset operations. It uses a direct custody approach, combining high performance with zero counterparty risk and multi-layered security. The platform includes secure MPC-based digital asset wallets, a policy engine for governance and transaction rules, and comprehensive treasury management. Fireblocks' security framework features multiple layers, including MPC-CMP technology, secure enclaves, and a robust policy engine, ensuring protection against cyberattacks, internal threats, and human errors. It's widely used for various operations like treasury, trading, and managing NFTs, smart contracts, and user wallets. - [Auth Providers](/sdk/v5_3_x/signers/intro): Smart accounts, like EOAs, rely on signatures to validate transactions and messages. The difference with smart accounts is that it can use arbitrary signatures schemes, such as multisig, passkeys, etc. - [Use Lit Protocol with ZeroDev](/sdk/v5_3_x/signers/lit-protocol): [Lit Protocol](https://www.litprotocol.com/) is distributed cryptography for signing, encryption, and compute. A generalizable key management network, Lit provides you with a set of tools for managing sovereign identities on the open Web. - [Use Magic with ZeroDev](/sdk/v5_3_x/signers/magic): [Magic](https://magic.link/) is a popular embedded wallet provider that supports social logins. While social logins are great, your users still need to onramp in order to pay for gas, which introduces significant friction. - [Use Particle Network with ZeroDev](/sdk/v5_3_x/signers/particle): [Particle Network](https://particle.network/) is an intent-centric, modular wallet-as-a-service (WaaS). By utilizing MPC-TSS for key management, Particle can streamline onboarding via familiar Web2 methods such as Google, emails, and phone numbers. - [Use Portal with ZeroDev](/sdk/v5_3_x/signers/portal): [Portal](https://www.portalhq.io/) is an embedded blockchain infrastructure company that powers companies with an end to end platform for key management for self-custodial wallets (MPC and AA), security firewall, and web3 protocol connect kit. - [Use Privy with ZeroDev](/sdk/v5_3_x/signers/privy): [Privy](https://privy.io/) offers a seamless user onboarding experience for both mobile and desktop platforms, accommodating users with or without existing wallets. It simplifies the process of setting up self-custodial wallets for users logging in via email, SMS, or social media accounts. Additionally, it provides flexibility for web3-savvy users to continue using their existing wallets with your application, offering them a choice based on their preference. - [Use Turnkey with ZeroDev](/sdk/v5_3_x/signers/turnkey): [Turnkey](https://turnkey.com/) is a key infrastructure provider with a great developer API and a powerful security policy engine. - [Use Web3Auth with ZeroDev](/sdk/v5_3_x/signers/web3auth): [Web3Auth](https://web3auth.io/) is a popular embedded wallet provider that supports social logins. While social logins are great, your users still need to onramp in order to pay for gas, which introduces significant friction. - [Passkeys](/smart-accounts/use-plugins/passkeys/overview): Passkeys are cryptographic key pairs created on end-user devices. [Apple](https://developer.apple.com/passkeys) and [Google](https://developers.google.com/identity/passkeys) are two major industry players pushing for the passkeys standard, which means that passkeys are widely available on consumer devices such as: - [ZeroDev Tutorial -- Passkeys](/smart-accounts/use-plugins/passkeys/tutorial): In this tutorial, we will be building a Next.js app where your users can create smart accounts and send UserOps with [passkeys](/smart-accounts/use-plugins/passkeys/overview). - [Build Your Own Action](/smart-accounts/permissions/actions/build-your-own): Guide coming soon. - [Build Your Own Signer](/smart-accounts/permissions/signers/build-your-own): Guide coming soon. - [ECDSA Signer](/smart-accounts/permissions/signers/ecdsa): The ECDSA signer signs with a single ECDSA key, specifically with the `secp256k1` curve, which is the same algorithm that EOAs use. - [Multisig Signer](/smart-accounts/permissions/signers/multisig): The weighted ECDSA (multisig) signer signs with a collection of ECDSA keys. Each key is weighted, so that the signature will pass as long as enough signers with enough weight have signed. - [WebAuthn Signer](/smart-accounts/permissions/signers/passkeys): The WebAuthn (passkeys) signer signs with a single passkey. Read [the passkeys doc](/smart-accounts/use-plugins/passkeys/overview) for a more detailed intro to passkeys. - [Build Your Own Policy](/smart-accounts/permissions/policies/build-your-own): Guide coming soon. - [Call Policy](/smart-accounts/permissions/policies/call): The call policy limits the target (either contract or EOA) that the UserOp can interact with. If the target is a contract, then you can further specify the functions the UserOp can interact with, as well as putting constraints on the values of the function arguments. - [Gas Policy](/smart-accounts/permissions/policies/gas): The gas policy specifies how much gas the signer can use in total, across all UserOps it sends. It can also enforce that the UserOps must use paymasters, or use a specific paymaster. - [Rate Limit Policy](/smart-accounts/permissions/policies/rate-limit): The rate limit policy specifies the frequency at which the signer is allowed to send UserOps. - [Signature Caller Policy](/smart-accounts/permissions/policies/signature): The signature caller policy specifies a list of addresses that are allowed to validate messages signed by the signer. - [Sudo Policy](/smart-accounts/permissions/policies/sudo): The sudo policy gives full permission to the signer. The signer will be able to send any UserOps and sign any messages. - [Timestamp Policy](/smart-accounts/permissions/policies/timestamp): The timestamp policy specifies the start and end time for when the signer is valid. - [Build Your Own Action](/sdk/v5_3_x/permissions/actions/build-your-own): Guide coming soon. - [Build Your Own Policy](/sdk/v5_3_x/permissions/policies/build-your-own): Guide coming soon. - [Call Policy](/sdk/v5_3_x/permissions/policies/call): The call policy limits the target (either contract or EOA) that the UserOp can interact with. If the target is a contract, then you can further specify the functions the UserOp can interact with, as well as putting constraints on the values of the function arguments. - [Gas Policy](/sdk/v5_3_x/permissions/policies/gas): The gas policy specifies how much gas the signer can use in total, across all UserOps it sends. It can also enforce that the UserOps must use paymasters, or use a specific paymaster. - [Rate Limit Policy](/sdk/v5_3_x/permissions/policies/rate-limit): The rate limit policy specifies the frequency at which the signer is allowed to send UserOps. - [Signature Caller Policy](/sdk/v5_3_x/permissions/policies/signature): The signature caller policy specifies a list of addresses that are allowed to validate messages signed by the signer. - [Sudo Policy](/sdk/v5_3_x/permissions/policies/sudo): The sudo policy gives full permission to the signer. The signer will be able to send any UserOps and sign any messages. - [Timestamp Policy](/sdk/v5_3_x/permissions/policies/timestamp): The timestamp policy specifies the start and end time for when the signer is valid. - [Build Your Own Signer](/sdk/v5_3_x/permissions/signers/build-your-own): Guide coming soon. - [ECDSA Signer](/sdk/v5_3_x/permissions/signers/ecdsa): The ECDSA signer signs with a single ECDSA key, specifically with the `secp256k1` curve, which is the same algorithm that EOAs use. - [Multisig Signer](/sdk/v5_3_x/permissions/signers/multisig): The weighted ECDSA (multisig) signer signs with a collection of ECDSA keys. Each key is weighted, so that the signature will pass as long as enough signers with enough weight have signed. - [WebAuthn Signer](/sdk/v5_3_x/permissions/signers/passkeys): The WebAuthn (passkeys) signer signs with a single passkey. Read [the passkeys doc](/sdk/v5_3_x/advanced/passkeys) for a more detailed intro to passkeys.