Welcome to the third issue of the "Playing with Solana" series. In the first article, we learned about the operating mechanism, account model and transaction structure of the Solana blockchain; in the second article, we learned how to use Rust to write a Solana program for publishing and displaying articles and test it with TypeScript scripts.
As the last issue of this series, this article will lead you to use Phalcon Explorer to analyze a simple Solana transaction. But before that, let's take a look at how the Token on Solana is implemented.
About Tokens
The tokens on Solana can be divided into two categories: Native Tokens and other tokens.
Native Token is actually Solana Token (SOL). We mentioned in the previous article that each account in Solana has a Lamports field. Lamports is actually the smallest unit of SOL Token (1 SOL = 1 billion Lamports), which records the balance of Solana Token in the current account.
For other tokens, Solana uses a program account (Token Program) and two data accounts (Mint Account and Token Account) to implement all the functions required by Token.
Token Program
Token Program Structure Diagram
Token Program is a program account provided by Solana Program Library (SPL), so the Executable field of AccountInfo is displayed as True.
As we introduced in the first article, the owner of all program accounts is the BPF Loader, and the Token Program is no exception. In addition, like the System Program, the Token Program is also deployed at a fixed address on the Solana chain.
As a program account, it implements several instructions to provide different functions. 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 certain address; while other instructions provide all the functions needed to use Tokens, such as the MintTo instruction to increase the number of Tokens, or the Transfer instruction to transfer Tokens between a pair of addresses.
It should be noted that since the Token Program is responsible for creating the Mint Account and the Token Account, it is also the owner of these two accounts.
Mint Account
The structure and relationship of Mint Account are as follows: Mint Account is a data account, which means that the Executable field of its AccountInfo is False.
On Solana, each Token corresponds to a Mint Account. Mint Account records the total supply of the Token, the account address that has the authority to mint the Token, and other information.
Token Account
Token Account is used to record the number of a specific Token held by an individual. For a certain Token, each account holding the Token has a Token Account. If a user owns 5 Tokens, then he will have 5 Token Accounts.
Token Account is a data account, and the Data part of its AccountInfo consists of three fields:
Mint: the address of the Mint Account corresponding to the Token Account;
Owner: the account that has the right to transfer the Tokens in the Token Account, that is, the real "owner" of the Token;
Amount: the number of Tokens currently held by the Token Account.
Token Account Structure Diagram
It should be emphasized that the owner field in AccountInfo and the owner in the Data field are completely different. The former is a field owned by every account in Solana, which indicates which address has the authority to directly modify the current account data; the latter indicates to whom the Token recorded by the Token Account actually belongs, and this field itself is part of the AccountInfo Data field.
Connecting the above contents in series, we can get the following diagram of account relationships. Whether it is System Program or Token Program, they are deployed at a unique address on the blockchain and exist in the form of a library; a wallet account may hold multiple Token Accounts at the same time, and it is the real "owner" of these Token Accounts; the Mint field of the same type of Token Account points to the unique Mint Account of the Token, and the account records information such as the total supply of the Token.
View Token Account Changes on Solscan
We can use Solscan to view the changes in Token accounts in a transaction:
https://solscan.io/tx/byRn8qtNAYSdvgaGCK4kmZV1m89b7uuFuy1cn96W6femp7WgwymLqJ2MP9hPbegqN9EPe7NvghWpqDFqoCDjKph#tokenBalanceChange
In addition, readers may also find that Solana Token and other Tokens in Solscan are displayed separately in two sections. Although this division method is technically reasonable, it is easier to understand if they can be displayed as Tokens and placed in the same section.
Phalcon Explorer not only solves the above problems, but also makes many other innovations for Solscan. Next, let's use Phalcon Explorer to look at the same transaction.
? It is recommended to open the link and follow our steps to analyze together, so that you can better understand the transaction details and feel the powerful functions of Phalcon Explorer?
https://app.blocksec.com/explorer/tx/solana/byRn8qtNAYSdvgaGCK4kmZV1m89b7uuFuy1cn96W6femp7WgwymLqJ2MP9hPbegqN9EPe7NvghWpqDFqoCDjKph
Use Phalcon Explorer to view and analyze transactions
Just above the Phalcon Explorer, you can see that the current transaction is identified as JITO's MEV transaction, and you can jump to Solscan with one click by clicking the Solana logo next to the transaction signature.
The information about this transaction is divided into four sections: Basic Info, Fund Flow, Balance Changes, and Invocation Flow. You can switch to the corresponding section by clicking the icon in the upper right corner.
Basic Info
The information in the Basic Info column is relatively simple, and it provides some key information about the current transaction. Similar to the transaction signature, you can also click the block number and signer address to jump to Solscan.
Fund Flow
The Fund Flow column provides analysts with the fund flow transfer and timing information generated when the transaction is executed. We can see that:
The initiator and signer of the transaction 59vLEsmV5VCCGTxjHCoRiXkNgHDVcq7dGx98v9HCn2F first transferred a certain amount of a certain token to the address marked as Raydium Authority V4;
Then Raydium Authority V4 transferred about 6.747 Wrapped SOL Token to the signer 59vLEsmV5VCCGTxjHCoRiXkNgHDVcq7dGx98v9HCn2F;
Finally, the signer also provided Jito with 0.000003 SOL Token as a tip for the Jito verifier to execute the transaction.
The following figure is a fund flow diagram in Solscan. Compared with Solscan, each address in the fund flow diagram in Phalcon Explorer uniquely corresponds to a node, so it is easier to find the fund flow relationship between addresses and improve the efficiency of analysis.
If you want to conduct a more in-depth analysis of the fund flow of the transaction, you can also click the brown logo in the upper right corner to enter MetaSleush.
Balance Changes
The Balance Changes column clearly shows us the changes of all tokens of different accounts after the current transaction.
For example, the signer of the transaction 59vLEsmV5VCCGTxjHCoRiXkNgHDVcq7dGx98v9HCn2F has three tokens that have changed, namely the native SOL Token, the Token named 61Hh8Udg7zruvG3BhyNiHF4UmULnC8reB9RBFtwi8uKp, and the Wrapped SOL Token.
Each Account Address that appears in Balance Changes has one or more Token Accounts. By clicking on the corresponding address, you can copy it or jump to solscan.
We can see that Phalcon Explorer does not distinguish between SOL Token and other Tokens, so it can directly reflect the changes of all Tokens in a certain account, and can more intuitively display the relationship between Token Account and its Owner.
Invocation Flow
Invocation Flow records the instruction execution process of the transaction, and each line corresponds to an instruction when the Solana transaction is executed.
Here, we focus on instructions 2 and 4 that involve token transfer.
The second instruction calls swapBaseIn of Raydium's AMM to sell the token. Expanding the instruction, you can see that it consists of two CPI (Cross Program Invocation) instructions, which are used to transfer tokens between Raydium Authority V4 and the transaction signer; the fourth instruction is the process of the signer paying a tip to Jito.
As shown in the figure below, by clicking the Accounts tab after the instruction, we can view all the accounts involved in the instruction. Compared with Solscan, this display method will be more concise, allowing analysts to focus on more critical information in the transaction.
Conclusion
In this article, we first introduced the implementation principle of Token in Solana, and then used Solscan to view the changes in Token Account in a transaction. Finally, we used Phalcon Explorer to further analyze the transaction and introduced the innovation and optimization details of Phalcon Explorer's functions.
