Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MIPX v1 - New json rpc method for swaps #25

Merged
merged 44 commits into from
Jul 1, 2024
Merged

Conversation

tommasini
Copy link
Contributor

@tommasini tommasini commented Nov 10, 2023

MIP for new json rpc method wallet_swapAsset

@vandan
Copy link
Collaborator

vandan commented Nov 11, 2023

Probably worth referencing the related EIP as part of the MIP: https://github.com/tommasini/EIPs/blob/64090fe54761906fc9bde31ad46eb85230de5e8d/EIPS/eip-swap-rpc.md

@tommasini
Copy link
Contributor Author

Thanks for the review @vandan
Added!

@vandan
Copy link
Collaborator

vandan commented Nov 11, 2023

Just sharing some initial thoughts:

Is there anything that should be different or more explicit when a swap operation is triggered from a dapp rather than manually in the wallet UI?
I noticed that the request params are abstracted away from specific accounts. If a dapp populates swap values in the swap form, but the user wants to run the swap off of a different account address, then the UI should probably attempt to retain the other swap parameters (when possible). As an example, MetaMask mobile doesn't appear to support this behavior right now.
You can add a section for User Experience Considerations to add any UI guidelines that relate to this MIP.

Can you add more detail to the Motivation section? It would help other developers to understand when and why they should use this method.
Try to explain why this proposal is necessary and what impact it would have for the developer ecosystem. What problem does it solve (helping users get tokens they may need for a specific operation with a dapp, ensuring that users get the right tokens in their swaps, etc.)? What alternatives were considered (ex. extending via a Snap)? Why is this proposal preferred over the alternatives?

I'm also curious about what transparency should be provided when something goes wrong. What errors might be returned to the requesting dapp?

@vandan
Copy link
Collaborator

vandan commented Nov 11, 2023

Please set this MIP as Type: Community

MIPs/mip-2.md Outdated Show resolved Hide resolved
@vandan
Copy link
Collaborator

vandan commented Nov 15, 2023

I assume this method would be limited to accepting ERC-20 tokens, right? Is there anything that should be considered for future flexibility?
We might want to consider making the method name a little more specific to something like: wallet_swapToken or wallet_swapAsset

MIPs/mip-2.md Outdated Show resolved Hide resolved
@shanejonas
Copy link
Collaborator

I assume this method would be limited to accepting ERC-20 tokens, right? Is there anything that should be considered for future flexibility? We might want to consider making the method name a little more specific to something like: wallet_swapToken or wallet_swapAsset

I do like wallet_swapAsset to be more in-line with wallet_watchAsset that supports multiple asset types now.

@tommasini
Copy link
Contributor Author

tommasini commented Nov 27, 2023

@vandan @shanejonas
Thanks for the review and amazing point on the account not being on the params!

Shane Jonas suggestion makes a lot of sense! We can use the same logic as we use on the send transaction rpc method, and use the account connected to the dapp, adding the from field that way!

In the other hand it would be nice to use the current screens with the swaps logic that already exist, what do you think if we ask the user to switch the selected account to account to the new from address field (if it's different than the one selected) instead of creating a new screen with all the swaps logic? (We can also do the first implementation since it's quicker and re-uses logic, and improve it to the second one if we see a big adoption, in order to improve it)

Curious, what do you think it's the best name for the property, from_address, user_address or just address?

Can you add more detail to the Motivation section? It would help other developers to understand when and why they should use this method.

I will add! Thanks!

I'm also curious about what transparency should be provided when something goes wrong. What errors might be returned to the requesting dapp?
In terms of error handling to the dapp right now we validate the params, we send a message back when some property is wrong on these formats:

  • from is not defined

  • to is not defined

  • amount property of from is not defined

  • chainId property of from is not defined

  • token_address property of from is not defined

  • token_address property of to is not defined

  • chainId property of from is not defined

@tommasini
Copy link
Contributor Author

wallet_swapAsset It's sounds amazing to me as well!!

@tommasini
Copy link
Contributor Author

Updated motivation section

MIPs/mip-3.md Outdated Show resolved Hide resolved
@tommasini
Copy link
Contributor Author

I assume this method would be limited to accepting ERC-20 tokens, right? Is there anything that should be considered for future flexibility?

@vandan When you say ERC-20 tokens, are you excluding BEP-20 and main tokens? I don't see a reason why limit it to ERC-20 tokens

@tommasini tommasini changed the title MIP2 v1 - New json rpc method for swaps MIP3 v1 - New json rpc method for swaps Nov 29, 2023
@vandan
Copy link
Collaborator

vandan commented Nov 29, 2023

Random thought since I'm hearing more about cross-chain DEXs recently.
Should we at least think about the implications for how non-EVM tokens might be accommodated in a wallet swap API. Just in case there is something we can do to keep it flexible enough for something like that in the future.

@vandan
Copy link
Collaborator

vandan commented Nov 29, 2023

I assume this method would be limited to accepting ERC-20 tokens, right? Is there anything that should be considered for future flexibility?

@vandan When you say ERC-20 tokens, are you excluding BEP-20 and main tokens? I don't see a reason why limit it to ERC-20 tokens

I was just thinking about that as well. Planning for some flexibility beyond ERC-20s makes sense to me as well.

@vandan
Copy link
Collaborator

vandan commented Dec 6, 2023

A potentially relevant proposal around chain identifiers from ChainAgnostic: https://github.com/ChainAgnostic/CAIPs/blob/main/CAIPs/caip-2.md

@rekmarks
Copy link
Member

rekmarks commented Jun 10, 2024

Could this be made to work in a multichain setting (i.e. using CAIP addresses), or Ethereum only?

@tommasini tommasini changed the title MIP3 v1 - New json rpc method for swaps MIPX v1 - New json rpc method for swaps Jun 10, 2024
@tommasini
Copy link
Contributor Author

@rekmarks Yes, it's totally be possible to be prepared for that!
It would be something like this structure

We could have it on the MIP as a future implementation, since on the mobile app the UI is not prepared for it yet, but when the multichain is implemented we can add this logic without breaking the default behaviour (that uses the network conected to the dapp as the default)

ethereum.request({
  method: 'wallet_swapAsset',
  params: [{
    fromToken: [{
      address: '0x1234567890abcdefABCDEF1234567890ABCDEF',
      value: '0xDE0B6B3A7640000',
      chainId: // CAIP-10 or eth
    }],
    toToken: {
      address: '0xabcdef1234567890ABCDEF1234567890abcdef',
       chainId: // CAIP-10 or eth
    },
    userAddress: '0x0000000000000000000000000000000000000000'
  },
  ]
});

Nevertheless, this was discussed and we talked about making this json rpc because the purpose would be for in first implementation to only redirect to the swaps flow already implemented on the wallet, and not with bridging functionality associated to ship it quicker and test the adoption of it! We were thinking about shipping other json rpc method for bridging/ cross chain swaps when this ones were implemented and the adoption of the builders community was validated. Happy to know your thoughts around this!

@rekmarks
Copy link
Member

Thanks @tommasini, that sounds good. I mainly wanted to make sure that you guys had multichain in mind.

Some notes about your proposed format, just for future reference:

  • The chainId field would be CAIP-2 strings, not CAIP-10.
  • Rather than having separate chainId fields, the address fields could just be CAIP-10 addresses, which are prefixed with the CAIP-2 chain id.
    • If we do have separate chainId and address fields, the addresses should probably be in the format of the chain in question, since CAIP-10 is simply <caip2>:<address>.
    • This is part of a larger question of "how do we handle CAIP addresses in our codebase?". Personally, I think we should establish sophisticated CAIP string parsing utilities, and go with the CAIP-10 approach.
  • The chain of the userAddress should also be specified, either by converting the field to CAIP-10 or by adding a chainId field.

MIPs/mip-x.md Outdated Show resolved Hide resolved
MIPs/mip-x.md Outdated

```markdown
if (parseChainIdFromCaip10(fromToken.address) !== parseChainIdFromCaip10(toToken.address)) {
throw rpcErrors.invalidParams(
throw rpcErrors.methoddNotSupported(
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is the double d in methodd on purpose? confused since i see you made this change in two different places haha

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

AHAHAHAHHA and I missed this error on two diff places XD

vandan
vandan previously approved these changes Jun 24, 2024
Copy link
Collaborator

@vandan vandan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This MIP generally looks good to me for committing as Status: Draft.

MIPs/mip-x.md Outdated Show resolved Hide resolved
MIPs/mip-x.md Outdated Show resolved Hide resolved
MIPs/mip-x.md Outdated Show resolved Hide resolved
Comment on lines +147 to +161
throw rpcErrors.invalidParams('Invalid caip-10 user address');
}

try {
parsedCaip10FromTokenAddress = parseCaip10Address(
fromToken[0].address,
);
} catch (error) {
throw rpcErrors.invalidParams('Invalid caip-10 fromToken address');
}

try {
parsedCaip10ToTokenAddress = parseCaip10Address(toToken.address);
} catch (error) {
throw rpcErrors.invalidParams('Invalid caip-10 toToken address');
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe same here: caip-10 -> CAIP-10? I know these are the actual error messages so maybe not...?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this section would be clearer in english instead of a try catch code example

adonesky1
adonesky1 previously approved these changes Jun 25, 2024
Copy link
Collaborator

@adonesky1 adonesky1 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just a few non blocking comments/requests! Ready for draft status for sure!

MIPs/mip-x.md Show resolved Hide resolved
@adonesky1 adonesky1 merged commit 1c60c00 into MetaMask:main Jul 1, 2024
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants