Smart accounts and gas sponsorship

Why a smart account

A user’s funds live in a ZeroDev Kernel v3.3 smart account (ERC-4337), not in the Web3Auth key’s own address. This gives Numpay:

Gas sponsorship. A paymaster pays for each operation, so users never hold ETH.
Counterfactual deployment. The address exists before the contract does; it is deployed in the user’s first operation, also sponsored.
A stable address across chains. The same key gives the same smart-account address on every EVM chain with the same Kernel deployment.

Key → account relationship

Deterministic address derivation

The smart-account address is computed with no network call:

import { getKernelAddressFromECDSA } from '@zerodev/ecdsa-validator';
import { KERNEL_V3_3_BETA, getEntryPoint } from '@zerodev/sdk/constants';

export const kernelAddressForEoa = (eoaAddress: Hex) =>
  getKernelAddressFromECDSA({
    publicClient,
    entryPoint: getEntryPoint('0.7'),
    kernelVersion: KERNEL_V3_3_BETA,
    eoaAddress,
    index: 0n,
  });

This function exists in both the app (src/hooks/use-create-kernel.ts) and the backend (src/utils/kernelAddress.ts). The app registers this address with the backend, and the backend uses the same function to derive claimable-wallet addresses.

The kernel version, EntryPoint version and index are part of every user’s address. Changing any of them in one place changes the derived address and makes funds sent to the old address unreachable from the app.

The app also self-checks at startup: it compares the address of the Kernel client it actually spends from with kernelAddressForEoa(eoa) and logs a loud error if they ever differ.

Building the client

const ecdsaValidator = await signerToEcdsaValidator(publicClient, {
  signer: walletClient,            // viem wallet client over the Web3Auth provider
  entryPoint, kernelVersion,
});
const account = await createKernelAccount(publicClient, {
  plugins: { sudo: ecdsaValidator }, entryPoint, kernelVersion,
});
const kernelClient = createKernelAccountClient({
  account,
  chain: base,
  bundlerTransport: http(ZERODEV_RPC),
  paymaster: createZeroDevPaymasterClient({ chain: base, transport: http(ZERODEV_RPC) }),
  client: publicClient,
});

Web3Auth v10 doesn’t expose the raw private key through its provider, so EIP-7702 delegation (which needs a local key to sign an authorization) isn’t used. A counterfactual Kernel account gives the same user experience.

Lifecycle of a sponsored payment

Gas sponsorship

	Base (production)	Elysium (testnet)
Bundler	ZeroDev	Pimlico
Paymaster	ZeroDev, “sponsor all transactions” policy	Pimlico verifying paymaster, optional sponsorship policy
Paid by	Numpay, billed by ZeroDev	Numpay, billed by Pimlico
Covers deployment	Yes	Yes

On Base a sponsored transfer costs Numpay a fraction of a cent.

System

Networks

Core building blocks

Money flows

Smart accounts and gas sponsorship

Why a smart account

Key → account relationship

Deterministic address derivation

Building the client

Lifecycle of a sponsored payment

Gas sponsorship

​Why a smart account

​Key → account relationship

​Deterministic address derivation

​Building the client

​Lifecycle of a sponsored payment

​Gas sponsorship

Why a smart account

Key → account relationship

Deterministic address derivation

Building the client

Lifecycle of a sponsored payment

Gas sponsorship