Docs: Add SPL Token exchange integration

[t-nelson]

Problem

No documentation to assist exchanges in integrating SPL Token

Summary of Changes

Add some

Fixes #12281

TODO

• Add --verbose flag to spl-token balance for also printing the mint
• Recommend checking withdraw accounts with ☝️

I'm going to punt the TODO to solana-labs/solana-program-library#467

[t-nelson]

Do we want to mention the existing JS (no docs published yet) or RPC (explicitly tagged unstable) at this point?

[mvines]

Do we want to mention the existing JS (no docs published yet) or RPC (explicitly tagged unstable) at this point?

Na, just another place to update when that's no longer the case IMO.

[mvines]

Let's take the opportunity to flesh out the "Listening for Deposits" section, for both SOL and tokens. General recommendation is that the getConfirmedBlocks and then getConfirmedBlock RPC methods be used to monitor the chain for deposits into the exchange user accounts.

For SOL, scanning the transaction meta postBalances for increases to any deposit account is sufficient.
For tokens, they'd need to check for spl-token transfer instructions into a deposit address and then invoke getTokenAccountBalance on the deposit account to read it's current balance. This nicely adds a dependency on @jstarry's work to expose CPI instructions in RPC as well, since the exchange wouldn't want to miss those deposits

[mvines]

There's probably a small handful of issues that are going to come out of this effort @t-nelson. Consider creating a Github project so that it's easy to track them all and we can have different folks working on some in parallel potentially.

[mvines]

This seems to be the best withdrawal flow:
User provides their primary wallet address. Exchange creates a new spl-token account and assigns authority of it to the user's wallet. This will require wallets like Sollet/Solflare to support merging of spl-token accounts (but that seems generally useful regardless).

Deposit flow is through a normal spl-token transfer operation

[t-nelson]

New project: https://github.com/orgs/solana-labs/projects/2

I've populated it with the stuff I'm aware of so far

[t-nelson]

This seems to be the best withdrawal flow:
User provides their primary wallet address. Exchange creates a new spl-token account and assigns authority of it to the user's wallet. This will require wallets like Sollet/Solflare to support merging of spl-token accounts (but that seems generally useful regardless).

Is this going to fit into existing withdraw UX flows without additional integration overhead?

[t-nelson]

For SOL, scanning the transaction meta postBalances for increases to any deposit account is sufficient.

Wasn't there discussion of extending postBalances with SPL Token balance deltas as well? More of a "wouldn't it be nice" than a "let's do it right now" comment, the suggestion sounds fine in the interim

[mvines]

This seems to be the best withdrawal flow:
User provides their primary wallet address. Exchange creates a new spl-token account and assigns authority of it to the user's wallet. This will require wallets like Sollet/Solflare to support merging of spl-token accounts (but that seems generally useful regardless).

Is this going to fit into existing withdraw UX flows without additional integration overhead?

I think so. Withdraw flow is pretty simple: user provides address and amount. In this case the address is for the account authority. Then rather than running a solana transfer <address> <amount> to execute the withdraw, it's some spl-token ... commands

[mvines]

For SOL, scanning the transaction meta postBalances for increases to any deposit account is sufficient.

Wasn't there discussion of extending postBalances with SPL Token balance deltas as well? More of a "wouldn't it be nice" than a "let's do it right now" comment, the suggestion sounds fine in the interim

Ah that's probably a better solution. I think we can scope out both and then decide if we want to skip the interim option entirely

[t-nelson]

I think so. Withdraw flow is pretty simple: user provides address and amount. In this case the address is for the account authority. Then rather than running a solana transfer

to execute the withdraw, it's some spl-token ... commands

Yeah, I guess my concern is that there will be significant education required to communicate the indirection here. I could see a user providing an actual SPL Token account for w/d, which was created with a throwaway keypair for instance, which would be bad.

Ah that's probably a better solution. I think we can scope out both and then decide if we want to skip the interim option entirely

I'll add an issue!

[CriesofCarrots]

One typo, then lgtm!

Pull request has been modified.

[t-nelson]

@mvines does this cover our bases now?

[mvines]

@mvines does this cover our bases now?

Yep! I think this is a great start. There's a number of improvements of course but that's all incremental work

Pull request has been modified.

[mergify]

automerge label removed due to a CI failure