token-swap: Add instructions to deposit / withdraw one token - #937
Conversation
joncinque
left a comment
There was a problem hiding this comment.
Most of the tests in processor.rs mimic the checks from withdraw and deposit, so there may be some other cases to check
| ) -> Option<u128> { | ||
| // Get the trading fee incurred if the owner fee is swapped for the other side | ||
| let trade_fee = fees.trading_fee(source_amount)?; | ||
| // Get the trading fee incurred if *half* the source amount is swapped |
| } | ||
|
|
||
| /// Deposit one exact in instruction data | ||
| #[cfg_attr(feature = "fuzz", derive(Arbitrary))] |
There was a problem hiding this comment.
Fuzzing will come later
| } | ||
|
|
||
| #[allow(clippy::too_many_arguments)] | ||
| fn check_accounts( |
There was a problem hiding this comment.
This felt like a nice refactor :-)
| ), | ||
| }; | ||
|
|
||
| let burn_pool_token_amount = token_swap |
There was a problem hiding this comment.
To do exact amount out, we have to calculate the amount and then tack the fee on afterward
|
CI passes locally |
CriesofCarrots
left a comment
There was a problem hiding this comment.
Based on my understanding of the math, this looks functionally good. Wouldn't hurt to get another pair of eyes on it, though.
I think the names for the new instructions could perhaps be more clear/precise. Wdyt?
| /// 9. '[]` Token program id | ||
| Withdraw(Withdraw), | ||
|
|
||
| /// Deposit some tokens into the pool. The output is a "pool" token |
There was a problem hiding this comment.
Based on this comment, I don't see any difference between Deposit and DepositOneExactIn. Can you make it more descriptive?
There was a problem hiding this comment.
That's a good point, I didn't want to change the name of the previous instructions, but it definitely makes things clearer. We could change Withdraw / Deposit to WithdrawAll / DepositAll -- what do you think?
| /// 5. `[writable]` Pool MINT account, $authority is the owner. | ||
| /// 6. `[writable]` Pool Account to deposit the generated tokens, user is the owner. | ||
| /// 7. '[]` Token program id | ||
| DepositOneExactIn(DepositOneExactIn), |
There was a problem hiding this comment.
Also, I'm not crazy about DepositOneExactIn. "One" makes me think I'm depositing amount one, I'm not sure what is "exact", and "in" seems redundant. ...Is there precedent for this nomenclature elsewhere in swap-land? If not... what about DepositAndSwap?
There was a problem hiding this comment.
I see what you mean... I wanted to make it clear that you're only depositing one token type instead of both, and that you're specifying exactly how much is going in, as opposed to the old deposit, which specifies the exact amount of pool tokens that you'll get out. Since it's not actually performing a swap, DepositAndSwap seems misleading. What about DepositOneSideExactAmountIn to be totally clear?
There was a problem hiding this comment.
Do you expect to also support depositing one side but specifying the input in pool tokens? If not, I don't think ExactAmountIn is needed. That can just be defined in the interface.
Are we still looking toward pools of >2 tokens?
How about DepositSingleTokenType
There was a problem hiding this comment.
It would be useful for people to be able to specify which side they want to fix when depositing or withdrawing, and it's something used in Balancer, so providing that info in this instruction would be best. DepositSingleTokenType definitely clarifies the One part -- what about DepositSingleTokenTypeExactAmountIn? For reference, I was looking at Balancer's terminology at https://github.com/balancer-labs/balancer-core/blob/master/contracts/BPool.sol -- but I found functions like joinswapExternAmountIn opaque, so I'm very motivated to make this clear for us!
There was a problem hiding this comment.
So hard to find something both precise and concise! ;)
DepositSingleTokenTypeExactAmountIn is at least very clear... wfm
| Ok(()) | ||
| } | ||
|
|
||
| /// Processes DepositOneExactIn |
There was a problem hiding this comment.
| /// Processes DepositOneExactIn | |
| /// Processes [DepositOneExactIn](enum.Instruction.html) |
There was a problem hiding this comment.
I've been wondering -- what does this do?
There was a problem hiding this comment.
These are just markdown links for when the docs are published to docs.rs, eg: https://docs.rs/spl-token/3.0.0/spl_token/processor/struct.Processor.html
But it looks like we're not composing those quite right in spl-token; they need to go to ../instruction/enum.TokenInstruction.html 😳. And here, they also need to be renamed to SwapInstruction. Feel free to ignore for the time being, but let's get these updated before we publish a v1 to crates.io
There was a problem hiding this comment.
Could we use the simpler markdown as in https://doc.rust-lang.org/rustdoc/linking-to-items-by-name.html? I'm surprised this didn't get caught by the lints. Definitely something else to look into
There was a problem hiding this comment.
Oh cool, it looks like it; that's way better. I haven't dug into rustdoc as I should
There was a problem hiding this comment.
I only looked into it just now 😆
| Ok(()) | ||
| } | ||
|
|
||
| /// Processes an [Withdraw](enum.Instruction.html). |
There was a problem hiding this comment.
| /// Processes an [Withdraw](enum.Instruction.html). | |
| /// Processes an [WithdrawOneExactOut](enum.Instruction.html). |
| /// 6. `[writable]` token_(A|B) User Account to credit | ||
| /// 7. `[writable]` Fee account, to receive withdrawal fees | ||
| /// 8. '[]` Token program id | ||
| WithdrawOneExactOut(WithdrawOneExactOut), |
There was a problem hiding this comment.
Ditto with this instruction name
There was a problem hiding this comment.
WithdrawOneSideExactAmountOut for this?
|
This should be good to go with the renames now! |
CriesofCarrots
left a comment
There was a problem hiding this comment.
Much better. Thanks for the comment expansion as well!
In order to properly support the new curves, we need the ability to deposit or withdraw just one side of the token swap. This uses the interface added in #934.
Since the math part is covered in other PRs, this focuses on the interface into processor.rs, and the tests closely mirror the logic to test the normal
withdrawanddepositinstructions.