Skip to main content
Smart wallets enable transaction batching and gas sponsorship, providing a better user experience than traditional EOA wallets. This guide covers integration patterns for both Privy Smart Wallets and Alchemy Smart Accounts (ERC-4337).
Key difference from EOA wallets: Smart wallets cannot sign EIP-712 permit messages, so they must use the approval flow. However, they can batch the approval and deposit into a single user confirmation.

Wallet Type Comparison

AspectEOA (Privy)Privy Smart WalletAlchemy Smart Account
Send MethodsendTransaction()sendTransaction({ calls })sendTransactions({ requests })
BatchingNoYesYes
Permit SupportYesNoNo
Gas PaymentUserSponsoredSponsored
Return ValuetxHashtxHashuserOpHash
Receipt PollinguseWaitForTransactionReceiptuseWaitForTransactionReceiptwaitForUserOperationReceipt
USDT Deposit2 transactions1 batched tx1 UserOperation
USDC Deposit1 tx (permit)1 batched tx1 UserOperation

Privy Smart Wallet

Uses Privy’s embedded smart contract wallet with gas sponsorship and transaction batching.

Imports

usePrivySmartWalletDeposit Hook

Key Characteristics

  • Uses smartWalletClient.sendTransaction({ calls }) for batching multiple contract calls
  • sponsor: true enables gas sponsorship (users don’t pay gas)
  • Cannot use permit signatures (smart contracts can’t sign EIP-712)
  • Batches approve + deposit into a single user confirmation
  • Returns a standard transaction hash

Alchemy Smart Account (ERC-4337)

Uses ERC-4337 Account Abstraction via Alchemy’s SDK with Dynamic as the auth provider.
Alchemy Smart Accounts return a userOpHash instead of a standard transaction hash. You must use waitForUserOperationReceipt() instead of wagmi’s useWaitForTransactionReceipt.

Imports

useAlchemyDeposit Hook

Key Characteristics

  • Uses alchemyClient.sendTransactions({ requests }) for batching
  • Returns userOpHash (not a standard transaction hash)
  • Must use waitForUserOperationReceipt() instead of wagmi’s receipt hook
  • Bundler submits the UserOperation to the network
  • Gas can be sponsored via paymaster configuration

USDT Special Handling

USDT requires special handling because its approve() function requires resetting to 0 before setting a new value if there’s an existing non-zero allowance:
When batching is not possible (e.g., non-smart-wallet USDT deposits with existing partial allowance), these three steps must be sent sequentially.

Token-Specific Behavior

TokenSupports PermitBest Flow
USDCYesPermit (EOA) or Batched (Smart)
USDGYesPermit (EOA) or Batched (Smart)
pyUSDYesPermit (EOA) or Batched (Smart)
USD0YesPermit (EOA) or Batched (Smart)
USDTNoBatched approval + deposit

Troubleshooting

IssueSolution
”Smart wallet not connected”Ensure user has a smart wallet configured in Privy/Dynamic
UserOperation failsCheck gas estimation, paymaster may need funding
waitForUserOperationReceipt times outBundler may be congested, increase timeout
Batched tx revertsCheck individual call data, one call may be failing
For standard EOA wallet examples, see Deposits.