crosschain.assets.transfers contains fungible token transfer data for chains indexed by Allium.
This includes
- native tokens and erc20 equivalent tokens (bep20, trc20) transfers across EVM chains
- SOL & SPL token transfers on Solana
- coin and fungible_asset transfers on Aptos
- fungible asset transfers on Sui
Understanding Blockchain Transfers
A short primer on understanding Allium’s transfer schema.- Introduction
- EVM Blockchains
- Solana
- Aptos
- Sui
Blockchain transactions are the fundamental building blocks of blockchain networks.
- They involve the transfer of digital assets or information from one party to another.
- When a transaction is performed and confirmed, the details of the transactions are appended to the blockchain, with a unique transaction hash accompanying the transaction.
- By indexing the blockchain, we can identify all transactions and asset transfers.
EVM transfers - Mapping Allium Schemas to EVM-Compatible Blockchains
EVM-compatible chains are blockchain networks compatible with the Ethereum Virtual Machine (EVM).In this example, we will use a USDT -> USDC transaction performed on the Ethereum network and illustrate how it maps to Allium’s data schema.select * from crosschain.assets.transfers
where chain = 'ethereum'
and block_timestamp::date = '2024-05-02'
and lower(token_type) = 'erc20'
and transaction_hash = '0xfe0ae8b623268b552f40bbdb17f07ec9bff70d4fb3139eda8580a48ac299e996'
- In this transaction, the transaction sender (transaction_from_address) interacted with the Exchange Proxy contract (transaction_to_address).
- The user (0x23b7) then sends 10,679 Tether USD from its address (from_address) -> Uniswap V3 USDC-USDT contract address (to_address).
-
In turn, the Uniswap V3 contract (from_address) sends 10,687.25 USDC from itself to the user 0x23b7 (to_address).
A user performing a swap from USDT to USDC stablecoin on the Ethereum blockchain. https://etherscan.io/tx/0xfe0ae8b623268b552f40bbdb17f07ec9bff70d4fb3139eda8580a48ac299e996
Transfer event log in their receipts.We index the entire blockchain and identify and decode these transfers. Receipt event logs are only emitted for successful transfers.
Solana transfers
Token Transfers on Solana work differently from EVM chains. To begin, you need to familiarise yourself with the following account types.Account Types- Native Accounts: Handle native programs like System, Vote, Stake.
- SPL Accounts: Store tokens other than SOL and NFTs.
- Program Accounts: Execute actions and run instructions.
- From User A to User B: Direct and similar to transactions on other blockchains.
- Compartmentalized Storage: Unlike Ethereum’s single storage for all ERC-20 tokens, Solana uses multiple compartments within a user account, each dedicated to one type of SPL token.
https://solscan.io/tx/4YWQv62igJbZaUX9ifybtZiK3vqjKim58kspoazp17wJxza4krvrSxFniuqWrojiZ2UJyXMEm1b8YaoenuovX3GM
5hjTw3.. transferred 79.87 USDT to AhhoxZ... The account/address represented here is the wallet account.Under the hood, when we toggle the “View Token Account” option, the USDT is transferred across the underlying token accounts, which are represented by token_acc_from and token_acc_to
Summary of edge cases in Solana transfers
Refer here for detailed information on edge cases when dealing with solana transfers.Aptos transfers
Token Transfers on Aptos work differently from EVM chains.- Aptos adopts a debit/credit based system, where tokens are withdrawn and deposited into accounts.
- Thus, users of Aptos token transfer data need to be aware that transfer data is reconstructed from withdrawal + deposits events recorded on the blockchain.
- Token transfers provide additional info over a plain credit/debit dataset, thus Allium has painstakingly reconstructed a token transfers dataset to enable more use cases such as tracking fund movements across the blockchain(s).
Details on withdrawal/deposit design
The need to reconstruct transfers stem from the following traits of Aptos, specifically thecoinand fungible_assetmodules.- There are no
transferevents emitted
transferfunction in the coinand fungible_assetmodules allowing for point-to-point transfers of assets, only withdrawal and deposit events are emitted and *no* transfer events are emitted. This creates a challenge where the parser has to ‘reconstruct’ point-to-point transfers using withdrawal and deposit events.- Invisible withdrawals and deposits
- N-withdrawals, M-deposits
- N=1, M > 1 : parsed into M rows of asset transfer
- N > 1, M = 1 : parsed into N rows of asset transfer
- N > 1, M > 1: parsed into a max of N*M rows, to/from parties are matched in FIFO manner
Sui transfers
Token Transfers on Sui work differently from EVM chains.- Similar to Aptos, Sui adopts a debit/credit based system, where tokens are withdrawn and deposited into objects.
- Thus, users of Sui token transfer data need to be aware that transfer data is reconstructed from events, transactions and balance changes recorded on the blockchain.
- Token transfers provide additional info over a plain credit/debit dataset, thus Allium has painstakingly reconstructed a token transfers dataset to enable more use cases such as tracking fund movements across the blockchain(s).
Details on design
Sui Architecture: there are notransfer events emittedWhile there is a TransferObjectfunction in the sui modules allowing for point-to-point transfers of assets, only transactions and balance changes are emitted and *no* transfer events are emitted. This creates a challenge where the parser has to ‘reconstruct’ point-to-point transfers using a mixture of transactions and balance changes.Coverage Limitations for
sui.assets.fungible_transfersUnlike EVM chains where there are standardized Transfer events, Sui does not support transfer events. To achieve comprehensive coverage, each event type (similar to EVM’s topic0) must be individually identified, decoded, and integrated into the fungible transfers dataset.While we aim for high event coverage, users should expect potential discrepancies when reconciling transfer data against balance changes, as not all balance modifications may have corresponding decodable events. Our team continuously expands coverage through case-by-case analysis of event types.Table Columns
| Column Name | Description |
|---|---|
chain | Blockchain where the token transfer event occurred. |
token_type | Type of token transferred. Includes erc20, tr20, native tokens (eth, matic, avax, bnb), and Solana tokens (spl, system). |
from_address | Address where the token is being transferred from. |
to_address | Address where the token is being transferred to. |
token_acc_from | (Solana-only) The token account that the asset is being transferred from. |
token_acc_to | (Solana-only) The token account that the asset is being transferred to. |
token_address | Address (or Token Mint on Solana) of the token that is being transferred. |
token_name | Name of the asset transferred. |
token_symbol | Token symbol of the asset transferred. |
raw_amount | Amount of tokens moved (unnormalized). |
amount | Amount of token moved, normalized. |
usd_amount | The value of tokens moved, in USD. Not all tokens will have accompanying USD value attached. |
transaction_from_address | The address of the sending party of this transaction. (Solana: maps to transaction signer) |
transaction_to_address | The address of the receiving party of this transaction (could be a contract address). (Null for Solana) |
transaction_hash | Transaction hash of the transfers. |
block_timestamp | Block timestamp of the transfers. |
block_number | Block number of the transfers. |
block_hash | Block hash of the transfers. |
unique_id | Unique ID generated for each transfer. |