The XCC feature was designed to allow users to spend their own wNEAR ERC-20 tokens on Aurora in Near native interaction as if it were the base token. This works by bridging the wNEAR from Aurora out to the user's XCC account, then unwrapping it. The Rainbow bridge team noticed an issue where it is possible for the wrap.near:withdraw_near promise to resolve before the wrap.near:ft_transfer promise. This causes the XCC flow to fail if the user's XCC account does not carry a wNEAR balance because we attempt to withdraw tokens we don't yet have.
This PR aims to solve that issue. To see why this fix works, we need to know why the issue happens in the first place. The problem is the XCC flow used to use the call entry point to trigger the exit to Near function on the wNEAR ERC-20 token. That function invokes the exit to Near precompile which creates a promise to transfer the corresponding NEP-141 token from aurora to the destination account. However, that promise is not returned from call because instead it must return the EVM SubmitResult (the normal use-case for call is simply to invoke the EVM).
By not returning the ft_transfer promise, it is disconnected from the subsequent execution graph and therefore Near does not make any guarantees about when it will resolve relative to other promises the execution will create. Under normal (non-congested) conditions, the ft_transfer does resolve first because there is one block before the wrap.near:withdraw_near call is created (since after aurora:call comes xcc_router:unwrap_and_refund_storage which then makes the withdraw call). However, if the shard containing wrap.near is congested then the ft_transfer call can delayed by one block and then need to execute in the same block as near_withdraw, resulting in a 50% chance of failure.
Therefore, to fix the issue we must make sure the promise from the exit precompile is given as the return value of the call in the XCC flow to make sure it stays connected with the rest of the execution graph. Doing this will ensure wrap.near:ft_transfer resolves before xcc_router:unwrap_and_refund_storage is allowed to execute.
To that end, in this PR I introduce a new private function called withdraw_wnear_to_router. The only purpose of this function is to make the call to the exit precompile while capturing its promise and then return that promise. With that context, this change should be pretty easy to follow. The new function is defined in contract_methods::xcc, and that logic is applied in both lib.rs and the standalone engine.
Performance / NEAR gas cost considerations
All costs should remain unchanged. The same work is done, just in a different method to allow the promise return.
Testing
The bug described above only occurs under congested conditions, so I do not know how to write a good test for it in near-workspaces. I am relying on the existing XCC tests to at least be sure this change does not break the feature.
Description
The XCC feature was designed to allow users to spend their own wNEAR ERC-20 tokens on Aurora in Near native interaction as if it were the base token. This works by bridging the wNEAR from Aurora out to the user's XCC account, then unwrapping it. The Rainbow bridge team noticed an issue where it is possible for the
wrap.near:withdraw_nearpromise to resolve before thewrap.near:ft_transferpromise. This causes the XCC flow to fail if the user's XCC account does not carry a wNEAR balance because we attempt to withdraw tokens we don't yet have.This PR aims to solve that issue. To see why this fix works, we need to know why the issue happens in the first place. The problem is the XCC flow used to use the
callentry point to trigger the exit to Near function on the wNEAR ERC-20 token. That function invokes the exit to Near precompile which creates a promise to transfer the corresponding NEP-141 token fromaurorato the destination account. However, that promise is not returned fromcallbecause instead it must return the EVMSubmitResult(the normal use-case forcallis simply to invoke the EVM).By not returning the
ft_transferpromise, it is disconnected from the subsequent execution graph and therefore Near does not make any guarantees about when it will resolve relative to other promises the execution will create. Under normal (non-congested) conditions, theft_transferdoes resolve first because there is one block before thewrap.near:withdraw_nearcall is created (since afteraurora:callcomesxcc_router:unwrap_and_refund_storagewhich then makes the withdraw call). However, if the shard containingwrap.nearis congested then theft_transfercall can delayed by one block and then need to execute in the same block asnear_withdraw, resulting in a 50% chance of failure.Therefore, to fix the issue we must make sure the promise from the exit precompile is given as the return value of the call in the XCC flow to make sure it stays connected with the rest of the execution graph. Doing this will ensure
wrap.near:ft_transferresolves beforexcc_router:unwrap_and_refund_storageis allowed to execute.To that end, in this PR I introduce a new private function called
withdraw_wnear_to_router. The only purpose of this function is to make the call to the exit precompile while capturing its promise and then return that promise. With that context, this change should be pretty easy to follow. The new function is defined incontract_methods::xcc, and that logic is applied in bothlib.rsand the standalone engine.Performance / NEAR gas cost considerations
All costs should remain unchanged. The same work is done, just in a different method to allow the promise return.
Testing
The bug described above only occurs under congested conditions, so I do not know how to write a good test for it in near-workspaces. I am relying on the existing XCC tests to at least be sure this change does not break the feature.