Our approach is to remove unnecessary complexity in the raw data, while preserving the full meaning of what each transaction is.
Take, for example, an "add liquidity" transaction. Depending on whether it gets executed against a Uniswap v3 contract, a Balancer vault, a Curve pool, a Solidly fork, or any new implementation of a DEX, the raw data will look very different.
Furthermore, it is likely that the transaction will have been executed through a multicall()or similar, which means that just looking at the name of the function being called won't be sufficient for understanding what happened.
Translate will handle that technical complexity so that regardless of the underlying protocol, and regardless of shape and structure of the smart contracts involved, the transaction will always be classified as an addLiquidity.
And so, despite the raw data being very different in each case, Translate's structured data will always have the same format.