Open Tarnadas opened 1 year ago
I got it almost working, but I don't seem to be able to get the address of the original tx signer. It's not part of the Context
and there is currently no way to retrieve it.
https://github.com/aurora-is-near/aurora-engine/blob/60682ae0e035205764018750863aa39338995cee/engine-precompiles/src/xcc.rs#L145-L148
I first thought context.caller
should be correct, but then I've seen that it's the address of the Solidity contract.
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_transfer
orft_transfer_call
to FT contractScenario 2:
ft_transfer_call
to FT contractft_on_transfer
to receiver contract (e.g. a DEX)ft_resolve_transfer
and 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_transfer
receipt fail,ft_resolve_transfer
refund to XCCft_transfer_call
to Aurora engine address to bridge FT back to EVM addressft_resolve_transfer
returns the used amount of tokens. If the receipt failed no tokens at all have been used.I stumbled across the following problems:
PromiseCreateArgs
to also include the EVM sender addressit 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 succeedno 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?wasm-opt -Oz target/wasm32-unknown-unknown/release/xcc_router.wasm -o target/wasm32-unknown-unknown/release/xcc_router_opt.wasm --strip-debug --vacuum
I shrinked the binary size from 219KB to 183KB and storage staking is now sufficient with 2NEAR. Also keep in mind that only wasm-opt v110 generates proper binary output for Near Protocol. Any newer version produces unusable WASM files. Not sure about a workaround though.(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.
TODOs
ft_transfer_call
refundft_transfer
refund