how to parse transactions about solana-go

[gagliardetto]

• Transactions on solana are made of one or more instructions.

• Each instruction specifies a set of accounts, and data encoded as a binary blob.

• That binary blob can be anything and is entirely depended on how the program works and what it expects.

• In the case of SOL transfers from one wallet to another, the system program is used.

• You cans see here an example of how to send SOL here: https://github.com/gagliardetto/solana-go#transfer-sol-from-one-wallet-to-another-wallet

• How to decode a raw transaction into its elemental instructions? See here: https://github.com/gagliardetto/solana-go#parsedecode-an-instruction-from-a-transaction

• The preBalances and postBalances (and preTokenBalances, postTokenBalances) are metadata that's added after the instruction has been executed.

[yifanes]

Wow, thank you for replying to me so seriously. Based on your reply, I learned some relevant knowledge points, but I'm sorry I encountered new problems again.

Suppose I have a Solana account. When I want to receive a token transfer, I must first create an associated account. Does that mean that the transferor must do this for the receiver? From the perspective of programming, do I have to judge whether this address is a token address? Then it depends on whether I want to create an associated account or not?

I noticed that Solana cli has a parameter --allow unfunded recipient --fund recipient. If the target address is a token address that has been created, this parameter will be ignored

I look forward to your valuable reply.

[gagliardetto]

I'm no expert on this topic (and you're better off asking/searching that question in the solana documentation, discord, or even better on solana stackoverflow).

The Sollet solana wallet is opensource, and you can see the code implementation of this and other dynamics: https://github.com/project-serum/spl-token-wallet

They are fairly easily portable to solana-go (often).

---

• From my limited knowledge on the topic, yes the sender must create the associated-token-account for the recipient if the associated-token-account doesn't exist.
• What is an "associated token account"? It's an account derived from the owner of the parent wallet (in your case the recipient) and the mint of the token.
• Something like this: (wallet + mint) => associated_token_account (because it's an inextricably associated token account with the wallet it's for.)
• Knowing the wallet and the mint, you can find the atok account.
• Knowing the atok account, you can find the owner wallet and the mint.
• AFAIK anyone can create an associate token account for anyone else, but the owner is always the wallet it was created for.
• The --allow unfunded recipient --fund recipient flags (I think) are there because if the atok account doesn't exist, you need to create it. To create an account on solana, you need to fund it with enough SOL so that it can pay rent and won't get deleted (evicted). (or even better, be funded enough so that it becomes rent-exempt so it can exist forever.)

---

Anyway, you're better off going to look into the documentation and the source code:

• https://spl.solana.com/associated-token-account
• https://github.com/solana-labs/solana-program-library/blob/master/associated-token-account/program/src/instruction.rs

[gagliardetto]

You need an atok for storing and transfering for anything that's a token (which means everything, except for SOL).

• NFTs are tokens.
• USDC is a token.
• Your meme coin is a token.
• Wrapped SOL is a token.

Basically everything is a token (also called "SPL token").

[yifanes]

Thank you for your serious reply. With your help, I have a new understanding of Solana access transaction. Thank you again