Alchemy Wallets is easy to misunderstand. It is not a downloadable consumer wallet competing with MetaMask, Rabby or Phantom. It is infrastructure that developers use to place wallets and transaction features inside their own applications. A user may therefore interact with an Alchemy-powered wallet without ever seeing Alchemy’s name.
The product also changed significantly on the way to 2026. Account Kit once combined embedded-wallet authentication, key management, interface components and smart-account infrastructure. Alchemy now labels Account Kit v4—including its built-in signer and embedded-wallet features—as deprecated. New projects are directed to Wallet APIs, while specialist providers handle login and private keys.
This distinction matters for users researching possible rewards and for developers planning an integration. The current offering is primarily a transaction layer: it prepares calls, obtains signatures from an external signer, submits transactions, sponsors gas where configured, retries eligible transactions and reports their status.
What replaced the original Account Kit?
According to the current Alchemy Wallet APIs documentation, applications now bring their own signer. Alchemy recommends Privy and also documents integrations with Turnkey, Openfort and other viem-compatible wallets. The signer manages authentication and keys; Wallet APIs manages what happens after the user authorizes an action.
A typical flow has four stages. The application first prepares one or more calls, such as a token transfer or swap. The user’s signer authorizes the request. Alchemy submits and optimizes the transaction, optionally paying its gas. The application then queries Alchemy for status and receipt data.
Developers can use a TypeScript SDK or call REST and JSON-RPC endpoints directly. Higher-level Wallet APIs cover common transaction flows, while the lower-level Bundler and Gas Manager interfaces remain available for teams that need direct control over ERC-4337 user operations, sponsorship and paymaster behavior.
Existing Account Kit applications are not automatically useless, but they should not treat the old embedded signer as the future-facing product. Alchemy’s deprecation notice tells new integrations to use Wallet APIs and recommends migrating signer responsibilities to another provider. That migration can preserve Alchemy’s transaction infrastructure and gas policies, but it introduces another vendor whose security, recovery options, pricing and availability must also be evaluated.
Smart wallets, EIP-7702 and account abstraction
A conventional externally owned account, or EOA, is controlled directly by a private key. A smart wallet adds programmable account logic. Depending on the implementation, this can enable batched calls, multiple owners, ownership transfers, scoped session permissions and sponsored transactions.
Alchemy’s stack supports ERC-4337 smart accounts, including its Modular Account v2 implementation, as well as other supported or custom account contracts. A bundler collects a user operation and submits it through the relevant EntryPoint contract. A paymaster can cover the operation’s gas under rules defined by the application.
Wallet APIs can also use EIP-7702 to give an existing embedded EOA smart-wallet capabilities without changing its address. This can reduce migration friction because the user keeps the address that already holds assets and history. The authorization is still security-sensitive: it delegates executable account behavior and should only be signed for code and applications the user trusts.
Not every signer can produce an EIP-7702 authorization. Alchemy’s non-7702 mode instead creates a separate smart-wallet address controlled by the signer. Users should therefore confirm which address actually holds assets before transferring funds. An authentication address and the deployed smart-account address may not always be the same.
“Smart” also does not mean invulnerable. Account contracts, modules, recovery systems, front ends, signers, paymasters and external protocols create a larger trust surface than a simple key-and-address model. Programmability can improve safeguards, but a badly scoped module or compromised owner can also create new routes to loss.
Embedded wallets without the old Alchemy signer
An embedded wallet lives inside an application rather than requiring a separate browser extension. Users may sign in with email, a social account or a passkey, while a wallet provider creates and protects the signing material. Wallet APIs can then connect that signer to Alchemy’s transaction services.
This separation should be made visible in any responsible application. Users deserve to know who manages their key, whether the wallet is non-custodial, how recovery works, whether private-key export is available and what happens if the application or signer provider disappears. “Sign in with email” is an interface choice, not a guarantee that funds are recoverable under every failure scenario.
Before depositing a meaningful balance, test account recovery on a low-value wallet. Record the exact wallet address and network, enable the strongest available authentication, protect the associated email account, and store any recovery material offline. Never paste an exported private key into support chat, a migration form or an “eligibility checker.” A legitimate support agent does not need the secret that controls the account.
How gas sponsorship works—and who pays
Gasless does not mean that blockchain execution has no cost. It means the application, rather than the end user, pays that cost. The developer creates a Gas Manager policy and passes its policy identifier when sending an eligible transaction. Alchemy fronts the network fee and bills the developer in its USD equivalent, so the application does not have to maintain native-token balances in every user wallet.
Policies can restrict spending by total budget, per-user limits, target contracts, function selectors and other conditions. These controls are important because a public sponsorship policy without adequate restrictions can be abused by bots or used to subsidize unintended calls. Developers should combine narrow allowlists, rate limits, monitoring and emergency shutdown procedures rather than relying on a single monthly cap.
Alchemy also supports gas payment using ERC-20 assets on supported EVM networks, plus fee and rent sponsorship on Solana. Availability is chain-specific, so applications should consult the live supported-networks table instead of assuming that bundling, sponsorship and ERC-20 gas payments exist everywhere.
Sponsored execution can make onboarding smoother, but users must still inspect the underlying action. A malicious approval remains malicious when someone else pays its gas. Gas sponsorship should never be interpreted as an endorsement by Alchemy, the wallet provider or the network.
Batching, session keys and automatic transactions
Batching combines several calls into one atomic transaction. An application might group token approval and a swap, avoiding separate signing screens and waiting periods. Atomic execution generally means the intended group succeeds together or reverts together, although cross-chain processes and external protocols can introduce additional stages and failure conditions.
Fewer prompts improve usability but can hide complexity. A clear confirmation screen should identify every target contract, token, amount, approval and recipient inside the batch. Users should reject summaries that say only “continue,” “claim” or “activate” without disclosing the actual calls.
Session keys allow a user to authorize a secondary key with limited permissions for a defined period. They can support games, trading tools and automated agents without requesting the primary signature for every action. Safe permissions should constrain time, target contracts, functions, assets and spending amounts. An unlimited session key is effectively a standing authorization and should be treated accordingly.
Users should be able to view and revoke active sessions. Developers should expire them promptly, keep session secrets away from client logs and analytics, and avoid granting broader permissions merely to simplify implementation. Alchemy’s automatic repricing and retry features may help a stuck transaction land, but they do not correct an unsafe call or protect against a bad destination.
Costs and operational risks
There are at least three cost layers: Alchemy API usage, sponsored network gas and any fees charged by the external signer or application. The current published pricing documentation lists a free allowance and pay-as-you-go compute pricing, while Wallet API methods consume different numbers of compute units. Preparing and sending calls costs more units than simple account or status queries.
For Gas Manager, the published plan table states that testnet use is free and lists an 8% administration fee for pay-as-you-go mainnet sponsorship, in addition to the underlying gas. Enterprise terms are custom. Pricing and limits can change, so a production budget should use Alchemy’s current dashboard and official pricing page, not an old tutorial or a cached quotation.
Other risks are less predictable. Network fees can surge; smart-contract calls can revert after consuming gas; third-party signers or Alchemy endpoints can experience outages; and a supported chain can behave differently from Ethereum mainnet. Cross-chain swaps add bridge, liquidity, route and destination-chain risks. Teams should set budgets and alerts, simulate transactions where possible, monitor failure rates and provide a fallback path that does not strand user assets.
Tracking wallet activity correctly
Wallet APIs returns a call identifier after prepared calls are submitted. The application can query that identifier to learn whether the batch is pending, confirmed, failed, partially failed, moving cross-chain or refunded. A confirmed response can include a transaction hash, block details, gas used, logs and receipts.
Status lookup is not a permanent accounting archive. On some chains and plan tiers, the endpoint searches only a bounded range of blocks, so an old operation may no longer be found through that call identifier. Applications should persist identifiers and transaction hashes, reconcile them with an independent block explorer or indexed history, and distinguish “not found” from “never happened.”
Users should track both the smart-wallet address and any owner or signer address. For each action, verify the network, destination, token movement and final receipt. The Gas Manager dashboard can show sponsorship spending, while on-chain explorers provide the public settlement record. A polished in-app activity feed is convenient, but the chain receipt is the stronger reference when the two disagree.
Token, rewards and airdrop status
The official Wallet APIs and Account Kit documentation reviewed for 2026 does not announce an Alchemy Wallets token, points program, retroactive reward formula or confirmed user airdrop. Using an Alchemy-powered application, sending sponsored transactions or creating many wallets therefore provides no documented entitlement to rewards.
Alchemy Wallets should also not be confused with Alchemy Pay or tokens carrying similar names. They are separate products and brands. Any site claiming that an “Alchemy wallet token” is ready to claim should be treated as unverified unless the announcement appears on Alchemy’s official domain and verified communications.
Common scam patterns include fake migration deadlines, rewards for “validating” a wallet, requests to import a private key, malicious EIP-7702 authorizations and unlimited token approvals disguised as harmless signatures. Navigate to documentation manually, check the full domain, verify contract addresses independently and test unfamiliar applications with a fresh low-value wallet. Never trust a sponsored advertisement simply because it appears above an official search result.
A practical 2026 verdict
Alchemy Wallets is now best understood as modular transaction infrastructure rather than a complete consumer wallet platform. Wallet APIs supplies smart-wallet execution, gas sponsorship, batching, retries, session permissions, swaps and status tracking. Authentication and key custody come from a separate signer provider, and the original all-in-one Account Kit model is deprecated.
For users, the safest approach is to identify the signer, understand recovery, verify the real asset-holding address, review every batched call and treat gasless transactions with the same caution as paid ones. For developers, good policy restrictions, transparent confirmations, durable activity records and a tested migration plan matter as much as a smooth login screen.
The infrastructure can remove substantial friction, but it cannot remove blockchain risk. There is also no officially documented token reward for generating activity. Use the product for its practical transaction features—not for speculative eligibility that Alchemy has not announced.
Related guides
- Rhinestone Rewards 2026: How to Track Smart Account Activity Safely
- Privy 2026: No Token or Airdrop, How to Track Embedded Wallet Activity Safely
- Dynamic Wallet in 2026: No Token or Airdrop, and How Its Embedded Wallets Really Work
- Pimlico in 2026: No Token or Airdrop, and How Its Gasless Account Abstraction Really Works
