Engine - AA account salt, new API reference, retry errors, + bugfixes

Engine has been updated to v2.0.25 which brings a handful of improvements.

Account salt: make AA calls before deploying the contract

First what is an account salt? The account salt is a unique ID that deterministically predicts a wallet address for a given admin + smart account factory.

This means your backend can provide a unique ID (like your dApp's user ID) as an account salt to Engine, and Engine will consistently reference and/or deploy the same smart account address each time (for the same admin + factory).

Here's an example:

My game has user IDs uid1, uid2, and uid3.

When a user signs up, the user's smart account calls my game contract.

Steps without account salt
1. User signs up.
2. Backend calls Engine to create a smart account.
3. Backend waits for the transaction to be mined.
4. Backend calls Engine with x-account-address: <address from step 2> to call the contract on behalf of the account.

Steps with account salt
1. User signs up.
2. Backend calls Engine with x-account-salt: uid1 to call the contract on behalf of the account.

💡 Bonus: The account is not deployed until a write transaction, deferring gas fees until the account is actually used!

The following endpoints now accept the x-account-salt header (more to come!):

• /contract/:chain/:contractAddress/write
• /contract/:chain/:contractAddress/erc20/claim-to
• /contract/:chain/:contractAddress/erc721/claim-to
• /contract/:chain/:contractAddress/erc1155/claim-to

To deploy a smart account from the account salt, call Create Smart Account and set the extraData arg to the salt.

To predict a smart account address from the account salt without deploying it, call Predict Address and set the extraData arg to the salt.

Improved API reference

Our API reference page has moved! 👉 engine-api.thirdweb.com

This new API reference docs make it easier to search for endpoints (try CTRL/⌘+K), see path/query/body params, and view sample code.

You can even test requests right in the API docs page! Select Test Request and provide the following details:

Improved retry endpoint

The Send Retry (Synchronous) endpoint now allows retrying any transaction that was sent (either still waiting to be mined or "timed out"). This commonly occurs when a transaction is stuck because of gas spikes or other network congestion.

If a transaction appears stuck, try to resend with aggressive (3-10x) gas fees:

await fetch('https://<YOUR_ENGINE_URL>/transaction/sync-retry', {
  method: 'POST',
  headers: {
    'Content-Type': 'application/json',
    Authorization: 'Bearer <YOUR_SECRET_TOKEN>'
  },
  body: JSON.stringify({
    queueId: '9eb88b00-f04f-409b-9df7-7dcc9003bc35',
    maxFeePerGas: '500000000000', // 500 gwei
    maxPriorityFeePerGas: '100000000000', // 100 gwei
  })
})

Plenty of bugfixes + improvements

• Fixed issue signing messages with Google Cloud KMS and AWS KMS wallets.
• Fixed import of Google Cloud KMS wallets. (Thanks @yukia3e !)
• Fixed 500 response when using an unrecognized backend wallet.
• Updated userOp code to the latest thirdweb SDK -> simpler code and performance optimizations.
• Fix nonce resync worker exiting early when there are multiple wallets sending transactions concurrently.
• Handle errors of different types better to avoid "empty" error messages.
• Fallback if the contract write call is provided an incomplete ABI (missing inputs or outputs fields).
• Updated log lines to be single-line for improved debuggability.
• Added lots of new route tests around signMessage, contract write, and userOps.

thirdweb is hiring!

The small team at thirdweb is on a mission to build the most intuitive and complete web3 platform. Our products empower over 70,000 developers each month including Shopify, AWS, Coinbase, Rarible, Animoca Brands, and InfiniGods.

See our open roles. We’d love to work with you!