Issue #48 added support for transferring native SOL between wallets.
SolanaWallet must also support transferring SPL tokens. This must work with tokens owned by both the original SPL Token Program and Token-2022.
Unlike a native SOL transfer, an SPL-token transfer requires the recipient to have a token account for the transferred mint. If the recipient's Associated Token Account does not exist, creating it requires additional SOL for account rent.
The caller must explicitly decide whether the sender is allowed to pay for creating the recipient's token account.
Requirements
Add a public high-level operation to SolanaWallet for transferring an SPL token to another wallet.
The operation must:
Accept the token mint, recipient wallet address and token amount.
Determine automatically whether the mint uses:
the original SPL Token Program, or
Token-2022.
Derive the sender's token account for the mint.
Derive the recipient's correct Associated Token Account using the detected token program.
Transfer the requested token amount using the correct token program.
Use the mint's configured decimal count when constructing the transfer.
Prefer the checked transfer instruction supported by the relevant token program.
Build, sign and submit the transaction internally, consistent with the design established by issue #49.
The caller must be able to choose between these two behaviours when the recipient's Associated Token Account does not exist:
Fail the operation
Do not create the recipient's token account.
Return a clear error explaining that the required token account does not exist.
Create the account at the sender's expense
Add the instruction required to create the recipient's Associated Token Account.
The sending wallet pays the account rent and transaction fee.
Perform the token transfer in the same transaction.
This choice should be represented explicitly in the public API, preferably by a clearly named enum or policy type rather than a boolean.
## Background
Issue #48 added support for transferring native SOL between wallets.
`SolanaWallet` must also support transferring SPL tokens. This must work with tokens owned by both the original SPL Token Program and Token-2022.
Unlike a native SOL transfer, an SPL-token transfer requires the recipient to have a token account for the transferred mint. If the recipient's Associated Token Account does not exist, creating it requires additional SOL for account rent.
The caller must explicitly decide whether the sender is allowed to pay for creating the recipient's token account.
## Requirements
Add a public high-level operation to `SolanaWallet` for transferring an SPL token to another wallet.
The operation must:
- Accept the token mint, recipient wallet address and token amount.
- Determine automatically whether the mint uses:
- the original SPL Token Program, or
- Token-2022.
- Derive the sender's token account for the mint.
- Derive the recipient's correct Associated Token Account using the detected token program.
- Transfer the requested token amount using the correct token program.
- Use the mint's configured decimal count when constructing the transfer.
- Prefer the checked transfer instruction supported by the relevant token program.
- Build, sign and submit the transaction internally, consistent with the design established by issue #49.
The caller must be able to choose between these two behaviours when the recipient's Associated Token Account does not exist:
1. **Fail the operation**
- Do not create the recipient's token account.
- Return a clear error explaining that the required token account does not exist.
2. **Create the account at the sender's expense**
- Add the instruction required to create the recipient's Associated Token Account.
- The sending wallet pays the account rent and transaction fee.
- Perform the token transfer in the same transaction.
This choice should be represented explicitly in the public API, preferably by a clearly named enum or policy type rather than a boolean.
For example:
```java
public enum MissingRecipientTokenAccountPolicy {
FAIL,
CREATE_AT_SENDER_EXPENSE
}
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Background
Issue #48 added support for transferring native SOL between wallets.
SolanaWalletmust also support transferring SPL tokens. This must work with tokens owned by both the original SPL Token Program and Token-2022.Unlike a native SOL transfer, an SPL-token transfer requires the recipient to have a token account for the transferred mint. If the recipient's Associated Token Account does not exist, creating it requires additional SOL for account rent.
The caller must explicitly decide whether the sender is allowed to pay for creating the recipient's token account.
Requirements
Add a public high-level operation to
SolanaWalletfor transferring an SPL token to another wallet.The operation must:
The caller must be able to choose between these two behaviours when the recipient's Associated Token Account does not exist:
Fail the operation
Create the account at the sender's expense
This choice should be represented explicitly in the public API, preferably by a clearly named enum or policy type rather than a boolean.
For example: