Introduction
Welcome to the "Solana Simplified" series. In the first article, we delved into Solana's operating mechanism, account model, and transaction structure. In the second article, we explored how to write a Solana program in Rust for publishing and displaying articles, and how to test it using a script written in TypeScript.
As the third and final part of this series, this article will guide you through analyzing a simple Solana transaction using Phalcon Explorer. Before we dive into that, let’s first explore how tokens are implemented on Solana.
About Tokens
Tokens on Solana can be classified into two categories: Native Token and Other Tokens.
Native Token refers to Solana Token (SOL). As mentioned in the first article, every account in Solana has a Lamports field, which records the balance of SOL in the account. Lamports are the smallest unit of SOL (1 SOL = 1 billion Lamports).
For Other Tokens, Solana utilizes a program account (Token Program) and two types of data accounts (Mint Account and Token Account) to implement all the necessary functionalities for tokens.
Token Program
The Token Program is a program account provided by the Solana Program Library (SPL), and therefore, the Executable field of its AccountInfo is True.
As mentioned in the first article, the owner of all program accounts is the BPF Loader, and the Token Program is no exception. Additionally, similar to the System Program, the Token Program is deployed at a fixed address on Solana.
As a program account, it implements many instructions to provide various functionalities. For example, some instructions are used to create a Mint Account to initialize a new token, or to create a Token Account to record the number of tokens held by a particular address. Other instructions provide all the necessary functionalities for using tokens, such as the MintTo instruction for increasing the token supply, or the Transfer instruction for transferring tokens between two addresses.
It is important to note that since the Token Program is responsible for creating Mint Accounts and Token Accounts, it is also the owner of these accounts.
Mint Account
The structure of a Mint Account is as follows:
Mint Account is a data account, therefore, the Executable field of its AccountInfo is False. On Solana, each token corresponds to a Mint Account. Mint Account stores information such as the total supply of the token and the address of the account with the authority to mint the token.
Token Account
A Token Account records the amount of a specific token held by an individual. For each type of token, every account holding that token has a corresponding Token Account. If a user holds five different tokens, he will have five Token Accounts.
Token Account is a data account, and the Data field of its AccountInfo consists of three sub-fields:
- Mint: The address of the Mint Account corresponding to this Token Account;
- Owner: The account with the privilege to transfer tokens from the Token Account, i.e., the true "owner" of the tokens;
- Amount: The number of tokens currently held in the Token Account.
It should be emphasized that the owner field in AccountInfo and the owner in the Data field are entirely different. The former is a field present in every account in Solana, indicating which address has the authority to directly modify the current account's data. The latter specifies who actually owns the tokens recorded in the Token Account and it is part of the AccountInfo Data field.
Connecting the aforementioned concepts, we can derive the following account relationship diagram. Both the System Program and the Token Program are deployed at unique addresses on the blockchain and exist as libraries. A wallet account may hold multiple Token Accounts, and it is the true "owner" of these Token Accounts. The Mint field in Token Accounts of the same type points to the unique Mint Account for that token, which records information such as the token's total supply.
Viewing Token Accounts in Solscan
We can use Solscan to view the changes in Token Accounts within this transaction:
The Address column lists all the Token Accounts involved in the transaction;The Owner column indicates the true "owner" of the token, which is the owner in the Token Account Data field;The Token column corresponds to the Mint Account of the current token. We can click on the "$SON" on the right side of the first row for more details:
The Owner Program in the Profile Summary indicates that the owner of the current Mint Account is the Token Program. By now we have matched all three types of accounts in Solscan.
However, this display way in Solscan can be somewhat misleading. For instance, in the previous image, it is unclear whether the increased balance in the first row belongs to the address CHS9WajyFfuaAZRk2JC7hRJvPHXmG5fC94gtAPbnLjuY or Raydium Authority V4. Such ambiguity increases the difficulty for users to understand the transaction.
Additionally, readers might notice that SOL Token and other tokens are displayed in separate sections in Solscan. While this separation is technically reasonable, it would be easier to understand if they were presented together under a unified token section.
Phalcon Explorer not only addresses the aforementioned issues but also introduces many other innovations. Now let's use Phalcon Explorer to examine the same transaction.
We recommend opening the link and following along with our steps to analyze it together. This way, you can better understand the transaction details and appreciate the powerful features of Phalcon Explorer 💪
Viewing and Analyzing Transactions in Phalcon Explorer
At the top left corner of the page, you can see that the current transaction has been identified as a JITO MEV transaction.
You can also click on the Solana icon next to the transaction signature to jump directly to Solscan. The information about this transaction is divided into four sections: Basic Info, Fund Flow, Balance Changes, and Invocation Flow. You can switch to the respective section by clicking the icons in the top right corner.
Basic Info
The Basic Info section offers some key details about the current transaction. You can click on the block number and signer's address to jump to Solscan.
Fund Flow
The Fund Flow section provides information on the movement and timing of funds during the transaction execution:
- The transaction initiator and signer, 59vLEsmV5VCCGTxjHCoRiXkNgHDVcq7dGx98v9HCn2F, first transferred a certain amount of a token to the address labeled as Raydium Authority V4;
- Next, Raydium Authority V4 transferred approximately 6.747 Wrapped SOL Tokens back to the signer, 59vLEsmV5VCCGTxjHCoRiXkNgHDVcq7dGx98v9HCn2F;
- Finally, the signer provided 0.000003 SOL to Jito as a tip to Jito validator for executing the transaction.
Below is the fund flow diagram from Solscan. Compared to Solscan, each address in Phalcon Explorer's fund flow diagram corresponds uniquely to a single node, making it easier to identify the relationships between addresses and thus improving analysis efficiency.
If you want to conduct a deeper analysis of the transaction's fund flow, you can click on the brown icon in the top right corner to enter MetaSleuth.
Balance Changes
The Balance Changes section clearly shows the token changes of different accounts after the transaction ends.
For example, the signer of the transaction, 59vLEsmV5VCCGTxjHCoRiXkNgHDVcq7dGx98v9HCn2F, had changes in three types of tokens: the native token SOL, a token named 61Hh8Udg7zruvG3BhyNiHF4UmULnC8reB9RBFtwi8uKp, and Wrapped SOL Token.
Each Account Address that appears in Balance Changes has one or more Token Accounts. By clicking on the respective address, you can copy it or jump to Solscan.
Phalcon Explorer does not distinguish between SOL token and other tokens, which directly reflects changes in all tokens for a given account. This also makes it easier to visualize the relationship between a Token Account and its Owner.
Invocation Flow
The Invocation Flow records the execution process of the transaction's instructions, with each line corresponding to an instruction executed during the transaction.
Here, we focus on instructions 2 and 4, which involve token transfers.
The second instruction calls Raydium AMM's swapBaseIn to sell the token. Expand this instruction and we can see that it consists of two CPI (Cross Program Invocation) instructions, which facilitate the token transfer between Raydium Authority V4 and the transaction signer. The fourth instruction is the process where the signer pays a tip to Jito.
As shown in the figure below, by clicking on the Accounts tab following each instruction, we can view all the accounts involved in that instruction. Compared to Solscan, this display method is more concise, allowing analysts to focus on the more critical information in the transaction.
Conclusion
In this article, we first introduced the implementation principles of Solana tokens. We then used Solscan to examine the changes in Token Accounts for a specific transaction. Finally, we conducted a further analysis of the transaction using Phalcon Explorer and introduced the innovative features of Phalcon Explorer.
This concludes the "Solana Simplified" series. Did you find it helpful? If you have other topics you'd like to learn about, such as security incidents, ecosystem introductions, or BlockSec products, feel free to leave a comment! 🫡
