I've been integrating the Aurora SDK in my orderbook implementation on Near (not yet open source) to do XCC from Aurora to Near, however there is one essential thing missing which are refunds on token transfers.
Imagine the following two scenarios:
Scenario 1:
Solidity contract bridges ERC-20 from Aurora to Near
XCC precompile sends ft_transfer or ft_transfer_call to FT contract
receipt at FT contract fails (e.g. because XCC address did not pay storage deposit)
FT are stuck in XCC address on Near
Scenario 2:
Solidity contract bridges ERC-20 from Aurora to Near
XCC precompile sends ft_transfer_call to FT contract
FT contract sends ft_on_transfer to receiver contract (e.g. a DEX)
receiver contract receipt fails (e.g. because of slippage)
FT contract calls ft_resolve_transfer and does the refund to XCC address
FT are stuck in XCC address on Near
Tokens being stuck without the possibility for a recovery is unacceptable for obvious reasons. Receipts can easily fail as you can see in scenario 2 where slippage constraint might not be met.
I have been in contact with @birchmd for quite a while to help me integrate Aurora SDK into the orderbook contract and everything works really good so far except the lack of refund. The orderbook I develop will be an upcoming product of Orderly Network. I really want to emphasize how essential a refund mechanism for bridged FT is. Without it you basically can't use Aurora SDK in DeFi.
Solution
My solution is WIP and I need help to fully implement it.
Let me demonstrate the solution for the updated scenario 2:
bridge, ft_transfer_call, ft_on_transfer receipt fail, ft_resolve_transfer refund to XCC
XCC address calls ft_transfer_call to Aurora engine address to bridge FT back to EVM address
I stumbled across the following problems:
we don't know in the XCC contract what the EVM address is for the refund
(Solution): we need to extend the PromiseCreateArgs to also include the EVM sender address
it seems like the XCC account no longer gets created with my changes and all I can see is a revert of the Aurora tx, but the Near tx seems to succeed
no solution so far, but I am clearly missing a change to update the input of the Near call to also include the sender. Where do I need to look for this?
(As a side note I have some problems compiling rocksdb even though I have llvm and clang installed. Not sure what's the exact problem, but if I check out the most recent rocksdb from crates.io it can be compiled. Maybe worth looking into upgrading the dep?)
I know this is quite a drastic change and I haven't created a prior AIP. Please let me know what we need to do to get this implemented.
Motivation
I've been integrating the Aurora SDK in my orderbook implementation on Near (not yet open source) to do XCC from Aurora to Near, however there is one essential thing missing which are refunds on token transfers.
Imagine the following two scenarios:
Scenario 1:
ft_transferorft_transfer_callto FT contractScenario 2:
ft_transfer_callto FT contractft_on_transferto receiver contract (e.g. a DEX)ft_resolve_transferand does the refund to XCC addressTokens being stuck without the possibility for a recovery is unacceptable for obvious reasons. Receipts can easily fail as you can see in scenario 2 where slippage constraint might not be met.
I have been in contact with @birchmd for quite a while to help me integrate Aurora SDK into the orderbook contract and everything works really good so far except the lack of refund. The orderbook I develop will be an upcoming product of Orderly Network. I really want to emphasize how essential a refund mechanism for bridged FT is. Without it you basically can't use Aurora SDK in DeFi.
Solution
My solution is WIP and I need help to fully implement it. Let me demonstrate the solution for the updated scenario 2:
ft_transfer_call,ft_on_transferreceipt fail,ft_resolve_transferrefund to XCCft_transfer_callto Aurora engine address to bridge FT back to EVM addressI stumbled across the following problems:
PromiseCreateArgsto also include the EVM sender address(As a side note I have some problems compiling rocksdb even though I have llvm and clang installed. Not sure what's the exact problem, but if I check out the most recent rocksdb from crates.io it can be compiled. Maybe worth looking into upgrading the dep?)
I know this is quite a drastic change and I haven't created a prior AIP. Please let me know what we need to do to get this implemented.