search

solana-labs / solana-program-library

A collection of Solana programs maintained by Solana Labs
https://solanalabs.com
Apache License 2.0
3.56k stars 2.07k forks source link

Inconsistency between spl_associated_token_account::get_associated_token_address and @solana/spl-token getAssociatedTokenAddressSync #6669

Closed vvvvq closed 6 months ago

vvvvq commented 6 months ago

In Rust, spl_associated_token_account::get_associated_token_address works just fine for a PDA. However in @solana/spl-token, this fails with a TokenOwnerOffCurveError.

It's unclear to me why this is considered an error. Using the associated token address for a PDA is useful- chain explorers recognize it and display the token balances associated with the data account, and they would not if I used some nonstandard convention for this. The rust crate does not consider it an error. I think that this interface should not throw this error. It's obvious that the associated token address was meant to solve a problem unrelated to PDAs, but I do not think that this use case is invalid, given that it has real benefits.

joncinque commented 6 months ago

This functionality was added because people kept incorrectly creating associated token accounts owned by associated token accounts. People using the Rust crates didn't report running into this issue, so we didn't add the check there.

You can pass allowOwnerOffCurve https://github.com/solana-labs/solana-program-library/blob/6968859e2ee0a1764da572de340cdb58e2b4586f/token/js/src/state/mint.ts#L193 if you want to create an ATA owned by a PDA though, does that satisfy your use-case?

vvvvq commented 6 months ago

Yes, this explains everything. I just didn't notice this argument.