Jetton Transfers
The ton.assets.jetton_transfers contains jetton transfers identified from ton.raw.messages with the opcode 0x0f8a7ea5.
This model does not include internal transfers and transfer notifications to prevent duplicate volume counts (read more Ton and Jetton Wallet Communication below for context).
This table is in Beta
- There may be unaccounted edge cases involving jetton transfers that do not involve
transfer
All address fields used in this table will be in Hex format and upper casing
-
There are up to 5 equivalent addresses for a given address on Ton.
- Use this website to convert the desired address https://ton.org/address/
-
Example of Hex address:
0:B113A994B5024A16719F69139328EB759596C38A25F59028B146FECDC3621DFE
Asynchronous and Non-Atomic Transactions in TON
The TON blockchain operates differently from many other blockchains, particularly in how it handles transactions.
Two key characteristics of TON transactions are their asynchronous and non-atomic nature:
Asynchronous Transactions:
In TON, when a transaction is initiated, it isn’t immediately complete. Instead, it triggers a series of message-passing events between smart contracts. These messages are processed in subsequent blocks, which means the full execution of a transaction can span multiple blocks.
Implications:
-
The final state of a transaction isn’t known immediately after it’s sent.
-
There can be a delay between when a transaction is initiated and when it’s fully executed.
Non-Atomic Transactions:
Atomicity in database systems means that a transaction is treated as a single, indivisible unit that either completes entirely or not at all. In TON, transactions are not atomic. This means that a single logical operation (like a token transfer) might involve multiple separate steps that can be partially completed.
Implications:
-
A transaction can partially succeed or fail.
-
Some effects of a transaction can occur while others don’t.
-
Error handling and state management become more complex.
Jetton Wallets Communication
For Jetton (TON’s equivalent of ERC20) transfers, this asynchronous and non-atomic nature manifests as follows:
https://docs.ton.org/develop/dapps/asset-processing/jettons#jetton-wallets-communication-overview
-
The initial transfer operation is just the first step of the transfer
-
This triggers an internal transfer between two Jetton wallets.
-
To confirm a successful transfer, we must check that this internal transfer has occurred.
In our Jetton Transfers, we check that there is a corresponding internal_transfer message that has succeded. This will be represented by succcess = true
Table Columns
Unique Key: unique_id
| Column | Description |
|---|---|
| from_address | Address that initiated the transfer [Bob’s Wallet] |
| from_jetton_address | Jetton address of the user that initiated the transfer [Bob’s Jetton Wallet] |
| to_address | Address that received the transfer [Alice’s wallet] Note: |
| jetton_master | Jetton master address in hex. This is the token contract equivalent (like ERC20) on TON. |
| token_name | Name of the token |
| token_symbol | Symbol of the token |
| amount_str | Amount of the token in string format |
| amount | Amount of the token in float format |
| raw_amount_str | The unnormalized amount of the token in string format |
| raw_amount | The unnormalized amount of the token in float format |
| response_destination | Response destination of the transfer [Joe’s wallet address] |
| forward_ton_amount | Forward TON amount of the transfer |
| forward_payload | Forward payload of the transfer |
| block_timestamp | Timestamp of the block that contains the transfer |
| utime | Timestamp of the transfer |
| hash | Message hash of the transfer |
| created_lt | Logical time of the transfer |
| masterchain_seqno | Sequence number on the masterchain |
| seqno | Sequence number on the workchain |
| shard | Shard of the transfer |
| workchain | Workchain of the transfer |
| bounce | Bounce of the transfer |
| bounced | Bounced of the transfer |
| tokens_updated_at | Timestamp of the last update of the token |
| created_at | Timestamp of the creation of the transfer |
| updated_at | Timestamp of the last update of the transfer |
| changed_since_full_refresh | Whether the transfer has changed since the last full refresh |