# Terms > Glossary of terms related to Wallet APIs > For the complete documentation index, see [llms.txt](/docs/llms.txt). ## Wallet APIs The Wallet APIs framework is designed to embed smart wallets in web3 applications. It includes a set of tools such as [authentication integrations](/docs/wallets/signer/what-is-a-signer), [Gas Manager](https://alchemy.com/docs/gas-manager-services), and [transaction sending](/docs/reference/bundler-api-quickstart) utilities that unlock features such as [gas sponsorship](/docs/wallets/transactions/sponsor-gas), [batched transactions](/docs/wallets/transactions/send-batch-transactions), and email/social login. With [aa-sdk](https://github.com/alchemyplatform/aa-sdk), Wallet APIs makes it straightforward to deploy smart wallets, manage `UserOperation`s, and handle gas sponsorship with minimal coding effort. ## Bundler A network participant in the [ERC-4337](#erc-4337) standard that collects and submits `UserOperations` (UOs) to the blockchain, handling the associated gas fees, in exchange for payment during UO processing either directly from the user or from a [Paymaster](https://www.alchemy.com/overviews/what-is-a-paymaster). The bundler implementation used by Wallet APIs is called [Rundler](https://github.com/alchemyplatform/rundler). It is written in Rust and designed to achieve high performance and reliability. ## Client Built on top of `viem`, the [`Client`](https://viem.sh/docs/clients/custom) is extended with custom functionality as a [`BundlerClient`](/docs/wallets/resources/types#BundlerClient) and [`SmartAccountClient`](/docs/wallets/resources/types#SmartAccountClient) compliant to EIP-4337 and EIP-6900 standards. `Client`, in general, is an intermediary or connector that enables interactions between client applications and your smart wallet (either `LightAccount` or `ModularAccount`) or the transaction sender. ## EntryPoint A standardized smart contract that acts as the primary gateway for processing `UserOperations` (UOs) on the blockchain. It receives bundled UOs from [`Bundlers`](#bundler) and verifies and executes these operations according to predefined rules, ensuring security and adherence to user-specified conditions. `EntryPoint` contract is a singleton contract to execute bundles of `UserOperation`s. `Bundler`s whitelist the supported `EntryPoint`. ## ERC-4337 A standard authored by the [Ethereum Foundation](https://ethereum.foundation/) for account abstraction, establishing a uniform interface for all smart wallets. This standard also outlines the roles and functionalities of [Bundlers](/docs/reference/bundler-api-quickstart), [Paymasters](https://www.alchemy.com/overviews/what-is-a-paymaster), and [`EntryPoint`](#entrypoint). Reference: https://eips.ethereum.org/EIPS/eip-4337 ## ERC-6492 A standard designed for verifying signatures from smart wallets that haven't been deployed yet. It is important for account abstraction, allowing decentralized applications (dApps) to authenticate user signatures even before the user's smart wallet is deployed. The deployment of these accounts typically occurs during the user's first transaction, making [ERC-6492](https://eips.ethereum.org/EIPS/eip-6492) essential for early interaction verification between users and dApps. ## ERC-6900 A [standard for modular accounts](https://eips.ethereum.org/EIPS/eip-6900) authored by Alchemy and [Yoav](https://github.com/yoavw) (one of the authors of ERC-4337) from the Ethereum Foundation. It defines standard interfaces for modular accounts ([`Modular Accounts`](#modular-account)) capable of supporting all standard-conformant [`Plugins`](#plugin). ## Gas Manager [`Gas Manager`](https://alchemy.com/docs/gas-manager-services) is the [Paymaster](#paymaster) service for sponsoring gas. With robust security and customizability, Gas Manager allows you to securely sponsor the gas fees for users of your applications. Gas Managers authenticate transactions and ensure payments are carried out only when specific conditions are fulfilled, significantly reducing the chances of fraud and errors. Additionally, Gas Managers allow you to set granular rules for sponsoring your user’s gas fees, so you can determine precisely when and how the gas fees are sponsored. Head over to the [Gas Manager](https://alchemy.com/docs/gas-manager-services) documentation to learn more. ## Light Account [Light Account](/docs/wallets/smart-contracts/other-accounts/light-account/) is a collection of lightweight, production-ready [ERC-4337](https://eips.ethereum.org/EIPS/eip-4337) smart accounts. It builds on top of Ethereum Foundation's canonical [SimpleAccount](https://github.com/eth-infinitism/account-abstraction/blob/cc3893bcaf2272c163ce89d5eb9eadb8e6b52db7/contracts/accounts/SimpleAccount.sol#L22) to add key improvements such as ownership transfers, multiple owners, ERC-1271 signature support, and gas optimizations. It has been audited [multiple](https://github.com/alchemyplatform/light-account/blob/develop/audits/2024-01-09_quantstamp_aa8196b.pdf) [times](https://github.com/alchemyplatform/light-account/blob/develop/audits/2024-04-26_quantstamp_93f46a2.pdf) by Quantstamp. ## Magic Link Authentication A magic link is a one-time use link sent to a user during the authentication process. After entering their username, the user is sent a URL, either to the user's email address or their mobile phone via text. The user clicks to authenticate themselves without entering a password, and for some, this might seem like "magic," thus the name. Magic links are attractive because it is a simple way to remove the need for a customer to generate and remember a password from the process. ## Modular Account A type of smart account enabled by the [ERC-6900](https://eips.ethereum.org/EIPS/eip-6900) standard and characterized by its [modular structure](/docs/wallets/smart-contracts/modular-account-v2/overview). This structure segments different functionalities of the account into distinct, independently upgradeable modules or plugins. Each plugin can have specific functions such as validation, execution, or hooks, enabling the smart account to extend its capabilities or modify its behavior without altering the core account logic. Modular Accounts enhance the flexibility, upgradeability, and interoperability of [ERC-4337](https://eips.ethereum.org/EIPS/eip-4337) smart accounts. Modular Account contracts have been audited by both [Spearbit](https://github.com/alchemyplatform/modular-account/blob/develop/audits/2024-01-31_spearbit_0e3fd1e.pdf) and [Quantstamp](https://github.com/alchemyplatform/modular-account/blob/develop/audits/2024-02-19_quantstamp_0e3fd1e.pdf). Strong security requires strong collaboration with skilled security researchers to improve the resilience of the code and everything it can do. If you believe you have found a security issue in the source code or smart contracts, participate in the [Bug Bounty](https://hackerone.com/alchemyplatform) program and notify us. ## Passkey Passkeys are a safer and easier alternative to passwords. With passkeys, users can sign in to apps and websites with a biometric sensor (such as a fingerprint or facial recognition), PIN, or pattern, freeing them from having to remember and manage passwords. ## Paymaster A [Paymaster](https://eips.ethereum.org/EIPS/eip-4337#paymasters) is an onchain contract that allows an entity to sponsor the gas fees for another entity. It can be used by dApps or companies to abstract away the concept of gas from their users. This significantly enhances the UX of dApps and can help onboard the next wave of Web3 users. ## Plugin A module for [ERC-6900](https://eips.ethereum.org/EIPS/eip-6900#terms) smart wallets, plugins are deployed smart contracts that host any amount of the EIP-6900 modular functions: execution functions, validation functions, or hooks. These plugins ensure modularity, upgradeability, and adherence to standardized interfaces. ## Authentication and ownership A service or application that manages the private key and signs either arbitrary messages or structured data objects such as `UserOperations` or `Transactions` before sending to the network. Types of authentication providers include: * **Custodial**: Managed by a third party, it holds and autonomously uses the private key for transactions, necessitating complete user trust. * **Non-custodial**: While a third party manages the private key, user involvement is required for signing transactions. Examples: Metamask. * **MPC (Multi-Party Computation)**: Partial or complete key shares are managed by third parties, but user participation is needed for transaction signatures. Examples: Privy, Portal, Fireblocks, Fordefi. * **Decentralized MPC**: Operated by a decentralized network, it manages key shares and requires node consensus for transaction signatures. Examples: Lit, Web3auth, 0xpass. ## Wallet A [wallet](/docs/wallets/resources/types#smartcontractaccount), or smart wallet in short, is an individual onchain account located at a public address where an ERC-4337 compatible smart account [`contract`](https://ethereum.org/developers/docs/smart-contracts) is deployed to. This address is controlled by one or more owners of the wallet. The [aa-sdk](https://github.com/alchemyplatform/aa-sdk) supports different smart account implementations such as [Modular Account V2](/docs/wallets/smart-contracts/modular-account-v2/overview), [Light Account](/docs/wallets/smart-contracts/other-accounts/light-account/), or [Simple Account](https://github.com/eth-infinitism/account-abstraction/blob/cc3893bcaf2272c163ce89d5eb9eadb8e6b52db7/contracts/accounts/SimpleAccount.sol#L22). ## Transaction `Transactions` in blockchain are cryptographically signed data messages that contain a set of instructions. These instructions can be interpreted to send native tokens from one account to another or interact with a smart contract deployed on the blockchain. A `Transaction` usually consists of the following parameters: `nonce`, `gasPrice`, `gasLimit`, `to`, `value`, `data`, `v`, `r`, `s`. Ethereum and other EVM blockchains have evolved to allow other transaction standards such as [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559), to allow more predictable gas fees and a more efficient transaction market. ## Transaction Calldata Transaction `calldata` refers to the data passed along with a transaction that allows accounts to send messages to other entities or interact with smart contracts. When calling smart contracts onchain (either from an `EOA` or another contract), the `calldata` is the encoded data within the `Transaction` containing the input parameters (or arguments) of the function being called on the contract. ## User Operation User Operations are pseudo-transaction objects introduced by the ERC-4337 standard that are issued to execute actions via a smart wallet. It encapsulates the intended actions or transactions of the user, which are executed onchain by a [Bundler](#bundler) through an [`EntryPoint`](https://eips.ethereum.org/EIPS/eip-4337#definitions) contract on different EVM chains. ## Wallet [Wallets](https://ethereum.org/wallets) are applications that give you control over your account. Like your physical wallet, it contains everything you need to prove your identity and handle your assets. Your wallet allows you to sign in to applications, read your balance, send transactions, and verify your identity. Your wallet is a tool for interacting with your account, which can be either an [Externally-Owned Account (EOA)](https://ethereum.org/developers/docs/accounts) or [`SmartContractAccount`](/docs/wallets/resources/types#smartcontractaccount). Conventionally, wallets used to interact with `SmartContractAccounts` are called `Smart Contract Wallets`, while wallets used to interact with Externally-owned accounts (EOA) are called `EOA Wallets`. ## Wallet-as-a-Service (WaaS) Also called a key management service (KMS). WaaS is an infrastructure-as-a-service provider that stores private key material. A WaaS provider would be classified under one of the [authentication custody types](#authentication-and-ownership).