[TASK] Support Native and PSP22 Token in the Mixer contract

[dharjeezy]

We are following the PSP22 Token standard which is similar to the ERC-20. We need to ensure that the contract is able to do transfer both in native tokens and psp22 standard token.

A todo was put up here

[iTranscend]

Hi @dharjeezy @dutterbutter

I noticed that work on this issue has not yet started. Can I take a stab at it?

In my attempt to understand what the issue requires I have a question regarding the desired interface for the mixer module.

I looked at the vanchor contract and noticed that there are separate functions for dealing with native and PSP22 tokens. ref1 | ref2
Should there be separate functions for handling native and psp22 token depositions into, and withdrawals from the mixer?

[drewstone]

This might be supported already but I’ll defer to Dami atm. Nonetheless there’s difference in what you mentioned for the vanchor. A PSP22 token is only ever deposited into the vanchor. Specifically, it is a PSP22 token that can be minted by wrapping either a native token or another PSP22 token (it’s configurable). If you do see missing functionality, we always welcome PRs. Please make sure to add tests as well to ensure that your changes work. Although, do make sure this doesn’t exist because I thought we may already have added this support.

…

On Thu, Jul 14, 2022 at 3:10 PM Femi Bankole ***@***.***> wrote: Hi @dharjeezy <https://github.com/dharjeezy> @dutterbutter <https://github.com/dutterbutter> I noticed that work on this issue has not yet started. Can I take a stab at it? In my attempt to understand what the issue requires I have a question regarding the desired interface for the mixer module. I looked at the vanchor contract and noticed that there are separate functions for dealing with native and PSP22 tokens. ref1 <https://github.com/webb-tools/protocol-ink/blob/bf9a4fda175d0c94390c9e394c86b873927b8325/contracts/vanchor/lib.rs#L393> | ref2 <https://github.com/webb-tools/protocol-ink/blob/bf9a4fda175d0c94390c9e394c86b873927b8325/contracts/vanchor/lib.rs#L458> Should there be separate functions for handling native and psp22 token depositions into, and withdrawals from the mixer? — Reply to this email directly, view it on GitHub <#40 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADELLFZDWVVW75XHQG4QZCTVUBQZTANCNFSM5XVCICBA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[dharjeezy]

So, @iTranscend you will need to do these:

1. Introduce a PSP22 token_address optional property in mixer storage. With this, if the token_address is set, then we can always do a transfer to the recipient and pay relayer the fee of the PSP22 Token. If the PSP22 token_address is not set in the mixer contract storage, then we do a native token transfer in the mixer for the recipient and possibly pay the relayer fee with native token transfer too.

2. We also need to introduce another contract function which will be non-payable for depositing/accepting PSP22 token into the mixer. This contract function will fail to execute(throw an error) if there is no PSP22 token address set for the mixer contract.

3. Finally, We'd need to add another integration test for testing PSP22 token deposit and withdrawal in the mixer.

[iTranscend]

Oh, great. Thanks a lot for the detailed responses @drewstone & @dharjeezy.
I'll go ahead to work on the outlined tasks and open a PR soonest.