Closed karim-en closed 1 year ago
Why treat WNEAR differently than every other ERC-20 bridged token?
@joshuajbouw this is because $NEAR is a native token in NEAR, and not NEP-141. So this change could allow users to create and/or top-up NEAR accounts easier and in more convenient way (it doesn't require a separate NEAR transaction and thus NEAR gas to unwrap wNEAR from the user).
Also, on NEAR->Aurora transfers of $NEAR we automatically wrap them so users receive wNEAR on Aurora. This PR will allow unwrapping on the way back.
@karim-en could you please merge the latest changes from the develop
branch?
Looks like CI is still failing.
Can you resolve conflicts please? Thanks.
Description
NEAR instead of wNEAR on AuroraStoring native NEAR tokens on aurora account on NEAR - issues:
aurora
balance is used for storage, which is used for bridged NEAR, and which is free and available.The solution:
aurora
balance on NEAR side.wrap.near near_withdraw()
) and then send native NEAR tokens for users.{}:unwrap
so it won't break the cross-chain swaps for Ref.Finance.Implementation: Modify the
ExitToNear
precompile:near_withdraw
instead offt_transfer
if theerc20_address
is awnear_address
and therecipient
end with the suffix{}:unwrap
.refund_on_error
callback toexit_to_near_precompile_callback
.TransferNearCallArgs
and an already existingRefundCallArgs
but make it optional.exit_to_near_precompile_callback
transfer near on successful promise result and refund on the failed result.Performance / NEAR gas cost considerations
The gas consumption increased a little bit due to a callback call.
Testing
Integration tests are added
How should this be reviewed
The reviewer should focus on the changed components that are described in the
implementation
section, and verify that the implementation is backward compatible and doesn't break any other components likeXCC
andrefund
logic.