Add an section for SPL Token integration to the exchange integration guide

[mvines]

Considerations:

1. The spl-token program is distributed as a source crate only. We might need to add binary release artifacts, perhaps include spl-token in the standard Solana release artifacts?
2. The per-user deposit address will require the exchange to establish a token account (ie. spl-token create-account). This requires a pinch of Sol per user for rent, and is not quite as convenient as the native token deposit workflow. The user will need to "register their intent" in the Exchange UI. There may be other alternatives such as using the SPL Token delegate facility (but sollet.io doesn't do delegates yet), "memo field" for transfers into a common exchange SPL Token deposit address, etc.
3. For withdrawals, some exchanges use solana transfer --no-wait to avoid blocking their withdrawal pipeline. spl-token transfer may be fast enough since it only waits for single confirmation, but if not then we'll need a --no-wait option here as well.
4. Highlight the mint-level freeze authority to Exchanges. When they integrate an SPL Token with Some freeze authority, an external party has the power to freeze tokens under their custody. This is something they need to be aware of

[t-nelson]

Seems like we're going to want to add an spl-token account or similar that returns a specific account. It'd be useful for verifying withdraw addresses

[mvines]

Seems like we're going to want to add an spl-token account or similar that returns a specific account. It'd be useful for verifying withdraw addresses

What would this do over spl-token balance?

[t-nelson]

Display the mint

[mvines]

Ok, so like spl-token accounts but not so much?

eg, some of my tokens:

$ spl-token accounts 
Account                                      Token                                        Balance
-------------------------------------------------------------------------------------------------
bobJGLnym1T78DkSz3fr8gT3mZ4aKCEw6AfehEHyFuW  TESTpKgj42ya3st2SQTKiANjTBmncQSCqLAZGcSPLGM  0.21
kaiPYrDEEbdEySemfudkmJjgqDzyhircGMa9k7fanxT  TESTpKgj42ya3st2SQTKiANjTBmncQSCqLAZGcSPLGM  41.58

[t-nelson]

Right. User want's to withdraw their Wrapped SOL to bobJGLnym1T78DkSz3fr8gT3mZ4aKCEw6AfehEHyFuW. Exchange queries bobJGLnym1T78DkSz3fr8gT3mZ4aKCEw6AfehEHyFuW and if it exists, that the mint is So11111111111111111111111111111111111111112 before proceeding

[t-nelson]

I suppose we'll also need to plumb the offline flags

[mvines]

Ah, I see. We could just add the token mint to getTokenAccountBalance (https://docs.solana.com/apps/jsonrpc-api#gettokenaccountbalance). Then spl-token balance --verbose kaiPYrDEEbdEySemfudkmJjgqDzyhircGMa9k7fanxT could output the mint as well.

[mvines]

I suppose we'll also need to plumb the offline flags

I think we can do this later, on demand. These aren't widely used 🙈

[CriesofCarrots]

Ah, I see. We could just add the token mint to getTokenAccountBalance (https://docs.solana.com/apps/jsonrpc-api#gettokenaccountbalance). Then spl-token balance --verbose kaiPYrDEEbdEySemfudkmJjgqDzyhircGMa9k7fanxT could output the mint as well.

We could easily add a RpcClient::getTokenAccount method that queries getAccountInfo for a jsonParsed-encoded response, which spl-token balance could use to get balance plus optional mint.

[t-nelson]

We could easily add a RpcClient::getTokenAccount method that queries getAccountInfo for a jsonParsed-encoded response, which spl-token balance could use to get balance plus optional mint.

This feels like the more flexible way to go to me. It'd replace the getTokenAccountBalance endpoint, right?

[CriesofCarrots]

The rpc plumbing is already there. It would just be a different client method for spl-token to call: RpcClient::get_token_account_with_commitment() instead of RpcClient::get_token_account_balance_with_commitment()

[t-nelson]

Yep, perfect!

[t-nelson]

FYI, this issue could perhaps be repurposed to cover the new RPC call