-
Notifications
You must be signed in to change notification settings - Fork 7
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
sending tokens from Aurora to Near #10
Comments
Update: Here's what I came up with: function deposit(
IERC20 token,
string memory tokenIdOnNear,
uint128 amount
) public {
token.transferFrom(msg.sender, address(this), amount);
bytes memory input = abi.encodePacked(uint(amount));
input[0] = 0x01;
(bool ok, ) = address(0xE9217BC70B7ED1f598ddD3199e80b093fA71124F).call(
abi.encodePacked(input, AuroraSdk.currentAccountId())
);
require(ok);
// ... According to the docs I can call this precompile to bridge erc20 back to Near. Somehow my tx gets reverted, so I'll need to investigate this. |
Hi @Tarnadas Could you explain what you are trying to do on a conceptual level? (What kinds of tokens are involved, what users/contracts control them, etc). Then I might be able to help you with the technical details more efficiently. One key point to understand is that it matters whether the token is Near-native or not (i.e. it existed as a NEP-141 token first then was bridged to Aurora as an ERC-20). |
Hey @birchmd, I have been developing an on chain orderbook DEX for Orderly Network and want to develop a proxy contract to seamlessly use it from Aurora without the need of token bridging. I wanted to start easy and do a deposit which is done via ft_transfer_call. It also includes more complex things like a swap where the msg data for the transfer is somewhat similar to ref finance. It also has functions to do limit or market orders either via deposited tokens or via transferred tokens. The tokens can be either native NEP-141 or native ERC-20, but the dapp will be able to find out. |
Thanks @Tarnadas . Let me see if I understand this correctly. We are assuming that there is some Aurora user Alice who does not have any Near account. We want to design a way for Alice to submit an order to the Orderly orderbook on Near. Submitting an order involves depositing some asset into the orderbook contract. For simplicity we must assume that the assets Alice will be depositing are bridged to Aurora so that they all have NEP-141 counterparts. It is possible to make something that works with Aurora-native ERC-20 tokens, but it introduces a lot more complexity, so unless this is a hard requirement for you then I think we ignore these assets for now. For the technical solution to this, there will be two steps. First using the exit_to_near to move Alice's ERC-20 token to it's NEP-141 counterpart, owned by Alice's XCC account (of the form An alternative solution, which might be able to do it all in a single Aurora transaction would be to have an EVM contract make all the necessary calls, but then if all users use the same contract it would not be possible to distinguish who deposited the tokens on the Near side I don't think. |
Yes you understand it correctly. The order creation is designed that it can also be done without a prior deposit via How can I use the I am more interested in the solution with a single tx. If it's done from within the Solidity smart contract it would still be the XCC account that sends the tokens to the orderbook, so I would be able to use that address to distinguish them I assume? It would be great to have an example to interact with Ref Finance from Aurora and perform a swap. Similar to the Uniswap example, but the other way around. |
You do not use the precompile directly. You call the function that is available on the bridged ERC-20 tokens (that function is actually called
There isn't just one XCC account. A different account is created for each address that calls the XCC precompile (of the form |
Oh so my misunderstanding was that I thought for every user who interacts with the contract a different account will be created. The way you described it, it is actually a lot better and also makes a lot more sense, because of the 2N funding requirement. Looks like I need to use the |
Right now I'm trying to figure out where my tokens went after calling My Solidity contract deposit function looks like this: function deposit(
IEvmErc20 token,
string memory tokenIdOnNear,
uint128 amount
) public {
token.transferFrom(msg.sender, address(this), amount);
token.withdrawToNear(
abi.encodePacked(AuroraSdk.nearRepresentative(address(this))),
uint(amount)
);
// ... I commented out the rest of the code, so there are no more token transfers involved. In my integration test I assume that the address the tokens should now be deposited on Near is this address: let account_key = format!("{}.{}", proxy_contract.address.encode(), engine.inner.id()); but somehow they are not here. To check for the token balance on Near I simply called Update: Fixed the address encoding with |
Closing this issue as it has been resolved with the inclusion of the |
Hey,
I am trying to send tokens from Aurora to Near via
ft_transfer_call
, but I suppose I'm doing something wrong, because idk how the Near <-> Aurora bridge actually works. I am probably missing some sort of unlock.My solidity contract is fairly simple, so here it is:
When running an integration test it seems like the tokens aren't moving at all.
Unfortunately I could also not find an example how to send tokens from Aurora to Near. I would also need to be able to receive tokens, like in a swap.
If you need to I can also show my current integration test.
The text was updated successfully, but these errors were encountered: