avatarsec3 (formerly Soteria)

Summary

The Solana programs Part 2 article delves into the technicalities of the SPL Associated Token Account, explaining its purpose, benefits, and instructions for creating and managing these accounts within the Solana ecosystem.

Abstract

The article "Solana programs Part 2: understanding SPL Associated Token Account" builds upon the foundational knowledge of SPL Token Mint from Part 1, focusing on the SPL associated token program. This program is designed to simplify the management of user token accounts by creating a Program-Derived Account (PDA) for each token a user owns, linked to their wallet address and a token mint. The main advantages of this approach are the consolidation of a user's token accounts and the ability to send tokens directly to a user's PDA, which is particularly useful for airdrops. The article details two key instructions: Create for generating a new associated token account (ATA) and RecoverNested for closing nested ATAs and transferring their tokens to the main ATA. It also emphasizes that any ATA is a PDA, owned by the wallet address, and can be created by anyone, not just the wallet owner. The SPL associated token program ensures that the ATA's program-level owner is immutable, securing the ownership of the tokens.

Opinions

  • The SPL associated token program is considered a convenient and efficient way to manage token accounts on the Solana blockchain.
  • The creation of a PDA for each token a user owns is seen as a beneficial feature for identity management and token transfers.
  • The ability for anyone to create an ATA for a wallet address is acknowledged as a feature that can streamline the token account creation process.
  • The RecoverNested instruction is presented as a solution to a potential issue where users might end up with nested ATAs, which restricts their ability to move funds.
  • The article suggests that the SPL associated token program enhances security by ensuring that the program-level owner of an ATA cannot be changed after initialization.
  • The ownership model of ATAs, where the wallet address fully owns the ATA and must sign for token transfers, is highlighted as a key aspect of the program's design.
  • The article concludes by hinting at future articles that will cover more Solana programs, indicating a commitment to educating the community on Solana's technical infrastructure.

Solana programs Part 2: understanding SPL Associated Token Account

Following Part 1: understanding SPL Token Mint, this article introduces the technical details of the SPL associated token program, another popular official Solana smart contract.

The program provides a convenient way to manage user’s token accounts from a wallet address. Its program id: ATokenGPvbdGVxr1b2hvZbsiqW5xWH25efTNsLJA8knL

The idea is to create a PDA (i.e., program-derived account) from a user’s wallet address and a token mint. There are two main benefits:

  1. The PDA can serve as the user’s identity token account for each token they own (with respect to a mint)
  2. Tokens can be sent to any user directly using the user’s PDA as the transfer destination, e.g., in airdrop.

A few take-aways on associated token account (ATA):

  • Every ATA is a PDA
  • Every ATA is a token account
  • Every ATA corresponds to a public key (e.g., wallet address)* and a token mint, and is owned by the *wallet address* (see below for *)
  • ATA may be created by anybody (not necessarily the wallet address’ signer)
  • Nested ATA may be created and the RecoverNested instruction can be used to close a nested ATA.

*wallet address — in fact it can be any pubkey that can be signed by an authority, e.g., a System account or a PDA (see deep dive on Solana account model).

Details

In the following, we will elaborate on two instructions:

  • AssociatedTokenAccountInstruction::Create
  • AssociatedTokenAccountInstruction::RecoverNested
Instructions provided by the SPL associated token program

Create AssociatedTokenAccount

To create a new associated token account (ATA), users need to supply the following six accounts to function process_create_associated_token_account:

  1. funder_info — Funding account (must be a system account)
  2. associated_token_account_infothe ATA address to be created
  3. wallet_account_info — Wallet address for the new ATA
  4. spl_token_mint_info — The token mint for the new ATA
  5. system_program_info— System program
  6. spl_token_program—SPL Token program

The function first calls get_associated_token_address_and_bump_seed_internal to compute the associated_token_address (i.e., the PDA) and validates the user input:

Internally, the PDA is computed using Pubkey::find_program_address and is uniquely determined by three addresses (in seeds):

  • wallet_address
  • token_program_id
  • token_mint_address

Then, the ATA is created by calling create_pda_account , and its program owner is set to spl_token_program_id (i.e., only the spl_token_program can modify the PDA account’s data):

In spl_token_2022 , it also ensures that the ATA’s owner cannot be changed by calling initialize_immutable_owner:

Finally, the ATA (which is a Token account) is initialized by setting its account.mint to token_mint_address and account.owner to wallet_address :

The initialize_account3 function initializes a token account

Note 1: account.owner here is not the program-level owner (i.e., the spl_token_program) of the ATA, but its real authority (i.e., the wallet_address). In other words, wallet_address fully owns the newly created ATA and the owner of wallet_address must sign to transfer tokens from the ATA.

Note 2: If the ATA for a given wallet_address does not yet exist, it may be created by anybody by issuing a transaction containing the AssociatedTokenAccountInstruction::Create instruction.

RecoverNested

A caveat of using the associated token program is that users may (unintentionally) create a nested ATA:

an associated token account owned by an associated token account

Once that happened, users cannot move funds from a nested ATA because it is not owned by the user’s wallet address, but a PDA.

The RecoverNested instruction is used to address this issue. It closes a nested ATA and transfers its tokens to the wallet’s ATA (and transfers its lamports to the wallet).

The input wallet_account_info account must be signed, and the destination_associated_token_account_info account is the recipient of the transferred tokens:

The transferred token amount and mint decimals are extracted from the nested ATA. The signer_seeds (i.e., owner_associated_token_account_signer_seeds) include three addresses and the bump_seed:

  1. wallet_account_info.key
  2. spl_token_program_id
  3. owner_token_mint_info.key
  4. bump_seed

The bump_seed is the bump seed returned from creating owner_associated_token_address , which is the PDA owner of the nested ATA (i.e., nested_associated_token_account_info ).

In the next few articles, we will continue to highlight the technical details of a few more Solana programs that are frequently used.

Soteria audit

Soteria is founded by leading minds in the fields of blockchain security and software verification.

We are pleased to provide audit services to high-impact Dapps on Solana. Please visit soteria.dev or email [email protected]

Join Coinmonks Telegram Channel and Youtube Channel learn about crypto trading and investing

Also, Read

Smart Contracts
Token
Wallet
Crypto
Solana Blockchain
Recommended from ReadMedium