What is the special case for the CONTRACT_CALL transactions

Developer Discussion
1

Hi,

I would like to know the concept of Fireblocks contract call transactions in the transaction history API response (GET /transactions, operation = CONTRACT_CALL). In our system, we are targeting to match the balance based on assetIds. After further analysis, we found that the additional transactions must be created through ‘networkRecords’ (i.e. list of contract_call transactions → returned by API response). By doing that the balance is still negative for a couple of asset IDs (BASECHAIN_ETH, ETH, etc.).

  1. Do we need to build the new transactions from ‘networkRecords’ where the operation = CONTRACT_CALL? Is there any pattern to do that, like which type of transaction needs to be considered ?
  2. After further analysis we found that networkFee should not be considered (in ‘netwrokRecords’ transactions) as it was already charged in the main transaction.
  3. Also, consider the netAmount only for those transactions (in ‘networkRecords’) which has a different assetId as compared to the main transaction.

Please confirm the exact pattern to handle the CONTRACT_CALL transactions. We applied all the above logic to match the asset’s balance.

2

Hey @ramangarg,

CONTRACT_CALL Operation is an operation that is being used when interacting with smart contracts directly or via some dApp.

You can interact with these either by using our browser extension or directly via API by executing a CONTRACT_CALL transaction type to the relevant contract.

The context for an asset in the CONTRACT_CALL operation is always the base asset of the network, for instance: you are interacting with Uniswap on Ethereum and swapping USDC to DAI - CONTRACT_CALL transaction in Fireblocks would always be with ETH asset as this is the chain which the operation was performed on.

Each contract call has a networkRecords section which details what exactly happened on chain, in our example you’ll see 3 objects:

  1. outgoing USDC
  2. incoming DAI
  3. outgoing ETH with the fee amount.

You can differentiate the incoming/outgoing amounts by the source/destination objects of the networkRecord.
For instance outgoing is always from source type VAULT_ACCOUNT to ONE_TIME_ADDRESS/EXTERNAL types while the incoming has UNKNOWN type and “EXTERNAL” name.

Generally speaking your assumptions are correct.
The networkFee amount appears to be the same one in all the networkRecords objects hence should not be calculated per each networkRecord object.