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

spl-token-cli: Add support for account delegates #367

Closed mvines closed 2 years ago

mvines commented 4 years ago

The account delegate feature of SPL Token is not exposed in the spl-token command-line tool yet.

buretto commented 3 years ago

CLI supports the approve command to assign a delegate to a token account, but AFAICT transfers using delegates are not yet supported.

Correct me if I'm wrong, but I believe the javascript interface function for token transfers also does not yet support delegates. There appears to be efforts into exposing/supporting them but I think it's unusable atm. https://github.com/solana-labs/solana-program-library/blob/58221fc9ae05e258ee903b49c5e8f5abbeb7796c/token/program/src/processor.rs#L198

I think if authority_info.key == delegate is wrong, it should be something like if authority_info.key == delegate.owner.

t-nelson commented 3 years ago

CLI supports the approve command to assign a delegate to a token account, but AFAICT transfers using delegates are not yet supported.

Correct me if I'm wrong, but I believe the javascript interface function for token transfers also does not yet support delegates. There appears to be efforts into exposing/supporting them but I think it's unusable atm.

This is all correct AFAIK, hence the issue still being open

https://github.com/solana-labs/solana-program-library/blob/58221fc9ae05e258ee903b49c5e8f5abbeb7796c/token/program/src/processor.rs#L198

I think if authority_info.key == delegate is wrong, it should be something like if authority_info.key == delegate.owner.

No the logic is correct as is. The delegate is not required to exist as an account on-chain, just as a keypair the delegate controls. AccountInfo::owner is the the Program that owns a native account, not the owner authority specified in the SPL Token account state

buretto commented 3 years ago

Thanks for the reply. Yup, everything works perfectly, it was just a little misunderstanding on my part. I thought delegates had to be specified as token accounts (CLI explains it like this, and perhaps other documentation I can't remember); but they can also be specified as native accounts which was the solution for me at least. Is this correct thinking? I'm not sure how/why a token account would be specified over a native account, AFAICT they are not usable that way. Probably just another misunderstanding on my part though :).

So just to sum up and clarify: Everything is working perfectly AFAICT.. delegate token transfers are supported on the CLI, as well as delegate creation/approval. Apart from that, maybe one minor suggestion would be to change the argument name here: https://github.com/solana-labs/solana-program-library/blob/813aa3304022528cbf3cf7a3d32bca339194a492/token/cli/src/main.rs#L1771 e.g. from DELEGATE_TOKEN_ACCOUNT_ADDRESS to DELEGATE_ACCOUNT_ADDRESS Since token accounts can be set as either a 'token' or 'native' account, but this naming suggests using token account. IDK and I apologize if I am just misunderstanding this entirely. Actually I am curious if someone could clarify the use case of using native vs token account as a delegate, because right now I only see reasons for use a native one. Good news is everything appears to work, so perhaps it's okay to close this issue now.