Skip to main content
This guide shows you how to work with ERC-4337 smart accounts linked to a HyperAuth identity — from predicting the account address before deployment through signing, sponsoring, and confirming a UserOperation.

Predict the smart account address

Before the account is deployed on-chain you can predict its deterministic address from the passkey’s public key coordinates.
The pubKeyX and pubKeyY values come from the identity’s verification method, available after calling client.query(). Pass a salt to derive alternative account addresses from the same key pair:
If you run a self-hosted vault, pass vaultUrl to point at your own deployment:

Inspect on-chain account state

getAccountState reads the deployed account’s on-chain state — nonce, associated DID, active status, and public key.
If you need to know whether an account has been deployed yet, check state.isActive. A newly predicted address that has not been used returns isActive: false.

Sign a UserOperation

signUserOp reads the account’s encrypted key material from the vault and produces a WebAuthn-compatible ERC-4337 signature. The vault must be unlocked.

Estimate gas

Before submitting, get gas estimates from the bundler:
To make the transaction gasless for the user, call sponsorUserOp. This calls the paymaster’s pm_sponsorUserOperation method and returns the UserOp with paymaster fields populated. It also fills in gas estimates internally, so there is no need to call estimateUserOpGas first.
Sign after sponsoring:

Send the UserOperation

All bundler functions use /api/bundler by default. To use a different bundler URL or a non-default entry point:

Wait for confirmation

waitForReceipt polls the bundler until the UserOperation is confirmed or the timeout expires (default 120 seconds).
Adjust polling behaviour:

Fetch a receipt directly

If you already have the hash and want a one-shot check without polling:

Full UserOp lifecycle example