This is a special kind of transaction that occurs when a series of actions have taken place in a complex function call (for example
multicall()), but that sequence cannot be flattened into a single transaction type.
For example, if a user executes a batch of actions in the same atomic transaction, such as: adding liquidity, staking, swaping, and removing liquidity (all in the same transaction), we'll report a
composite and return the full list of actions that took place.
In most cases, complex function calls are simply translated to a single transaction type (for example, Uniswap v3
multicalls are typically translated to
add/remove liquidity, or
claimRewards, depending on each case).
We rarely encounter cases where the sequence of actions cannot be reported as a single type. However, when we do encounter such cases, we report those as a
This type is reported for all transactions that failed to execute. The intended action of the user (for example, a swap) is still reported as a separate field in these cases.
This type is returned when we're unable to classify the transaction.
Depending on the reason for the unclassified, our expected turnaround time ranges between 24 hours and a few days to resolve any unclassifieds detected in our system.
When an unclassified is returned, all relevant asset transfers are still reported to allow for full reconciliation of assets, even if we're unable to say at the time what transaction type it is.
This type is reported when the underlying contract being called in the transaction is unverified (no ABI available), and we're unable to match it via bytecode with known contracts, or match the function hash with existing databases of known functions.
In such cases, as we're unable to see the source code of the contract being called, we aren't able to properly classify the transaction.
Unverified contract classifications still return all asset transfers that are relevant to the perspective address.