-
Notifications
You must be signed in to change notification settings - Fork 137
Support multiple assets transfer #1628
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
base: main
Are you sure you want to change the base?
Conversation
f9d6a6c to
ea1f2dd
Compare
b77bc39 to
1af53a2
Compare
claravanstaden
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice! 👏🏻
| export type AggregatedAsset = { | ||
| tokenErcMetadata: ERC20Metadata | ||
| ahAssetMetadata: Asset | ||
| sourceAssetMetadata: Asset | ||
| amount: bigint | ||
| } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Given that we don't want to change the SDK interface too often, can we add a field to distinguish if an asset is an ERC-20 or PNA, so we don't have to change the interface later? Or does this type already support this?
We don't have to add PNA support right now, but the interface should be defined with PNA in mind so we don't need to make unnecessary changes later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
An Asset with a non-nil location field is treated as PNA; otherwise, it’s ENA.
It’s a bit implicit, though — we might consider adding an explicit flag to make this clearer.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think a flag would be cool yeah! :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| if (isNativeBalance && fee.totalFeeInNative) { | ||
| if (amount + fee.totalFeeInNative > tokenBalance) { | ||
| logs.push({ | ||
| kind: ValidationKind.Error, | ||
| reason: ValidationReason.InsufficientTokenBalance, | ||
| message: "Insufficient token balance to submit transaction.", | ||
| }) | ||
| } | ||
| } else { | ||
| if (amount > tokenBalance) { | ||
| logs.push({ | ||
| kind: ValidationKind.Error, | ||
| reason: ValidationReason.InsufficientTokenBalance, | ||
| message: "Insufficient token balance to submit transaction.", | ||
| }) | ||
| } | ||
| } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we not leave these basic token balances checks? Dry run doesn't always give a clear error to the user.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I’d prefer to remove it for simplicity. It can be detected by a dry run, and the result should already include the error code, for example:
error: {
Module: {
index: 31
error: 0x1c000900
}
}
I assume this can then be further decoded into a more detailed error description.
@alistair-singh What's your take on this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would like to remove them for simplicity. However the UI is driven by these errors. We use them for many cases such as for NeuroWeb, when the API returns InsufficientTokenBalance we pop up a pre transfer step which allows the user to wrap/unwrap.
We do similar for ETH. So I would only support it if we can get the same kind of granularity.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| const sourceParachainImpl = await paraImplementation(parachain) | ||
| const { tokenErcMetadata, sourceParachain, ahAssetMetadata, sourceAssetMetadata } = | ||
| resolveInputs(registry, tokenAddress, sourceParachainImpl.parachainId) | ||
| resolveInputs(registry, tokens[0].address, sourceParachainImpl.parachainId) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should add a check if tokens.length > 1, throw an error that only 1 PNA is supported at this time.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
…rk/snowbridge into ron/multi-assets-transfer
Context
Adds support for multiple-asset transfers in the P→E direction, along with some refactoring and cleanup. For now, since PNA is not yet widely adopted in production, this implementation supports only multiple ERC-20 assets. We can extend it in a future PR if necessary.
Resolves: https://linear.app/snowfork/issue/SNO-1637