-
Notifications
You must be signed in to change notification settings - Fork 3
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
feat: EVM locker implementation #74
Conversation
I think it is better to open separate PR for these changes, so we can include it into the post-audit review:
|
if (fee >= amount) { | ||
revert InvalidFee(); | ||
} | ||
|
||
address tokenAddress = nearToEthToken[token]; | ||
uint256 extensionValue = msg.value - nativeFee; |
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.
Still feels like calculating value inside the extension method is more appropriate
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.
Nope, the difference should be calculated here for two reasons:
1- we could implement a refund later.
2- it works as a verification of msg.value >= nativeFee
EVM::initTransfer
, so it now accepts the token address instead of the token ID and message instead ofnear_account_id:msg
.SolAddress
type with validation.Todo in follow-up PRs: