ERC‑20 deposit webhook returns base asset ID instead of token assetId in multi‑token vault

Support
1

Environment: Fireblocks Sandbox / testnet (Sepolia)

I’m integrating Fireblocks transaction‑creation webhooks (transaction.created and transaction.status.updated) into my backend to automatically credit user balances for incoming ERC‑20 deposits. However, I’m seeing inconsistent assetId values for ERC‑20 transfers on testnet, which makes it impossible to reliably identify the correct token on my side.

Setup

  • Workspace: Sandbox / testnet.

  • Blockchain/network: Ethereum Sepolia / Arbitrum Sepolia testnet.

  • Vault account: One ETH‑based vault with three different ERC‑20 tokens configured on top of the same base chain.developers.

  • All tokens in this vault share the same deposit address, derived from the underlying ETH wallet (standard Fireblocks behavior for EVM tokens).

  • Example token configuration:

    • One wallet uses USDC_ARB_SEPOLIA_V84S (USDC on Arbitrum Sepolia).

    • Other ERC‑20 tokens are configured on the same vault and share the same deposit address.

Observed behavior

When I send an ERC‑20 transaction to the vault (e.g. to the USDC_ARB_SEPOLIA_V84S wallet), the webhook payload I receive from Fireblocks shows a different asset ID in the transaction details than the token that was actually used:

  • The webhook event is transaction.created or transaction.status.updated.

  • In the data.transactionDetails object, the assetId field is not USDC_ARB_SEPOLIA_V84S as expected, but instead USDC_ETH_TEST5_0GER (or another base‑chain/test asset ID).

  • This assetId value appears to correspond to a different ETH‑based USDC test asset rather than the concrete Arbitrum Sepolia token that was sent.

Because all three ERC‑20 tokens share the same vault deposit address, I cannot distinguish which token was actually deposited based only on:

  • The destination address (same for all ERC‑20 tokens on that vault).

  • The returned assetId when it points to the base asset or to the wrong testnet variant.

In my backend, the only reliable way to credit the correct currency is to know the precise Fireblocks asset ID of the ERC‑20 token that was sent (e.g. USDC_ARB_SEPOLIA_V84S vs USDC_ETH_TEST5_0GER vs other tokens configured in the same vault). If the webhook’s assetId does not match the token that actually arrived on‑chain, then my internal asset mapping breaks.

Questions

  1. In this testnet setup, which field in the webhook payload should be used as the authoritative Fireblocks asset ID for the deposited ERC‑20 token: data.assetId, or another property?

  2. Is the behavior where transactionDetails.assetId returns USDC_ETH_TEST5_0GER instead of USDC_ARB_SEPOLIA_V84S expected on testnet, or is this a misconfiguration / bug?

  3. Is there any additional configuration required (per‑token vault setup, network connection settings, token linking, etc.) to ensure that ERC‑20 deposits in a multi‑token vault always expose the correct token‑level asset ID in webhooks?

  4. What is the recommended best practice for mapping incoming ERC‑20 deposits to specific Fireblocks asset IDs in a scenario where several tokens share the same EVM address on testnet?