Native NEAR in Aurora

[mfornet]

This is a proposal to use Native NEAR token in Aurora instead of using Wrap NEAR.

Motivation

1. Users need to think about wrapped NEAR on Aurora, but they will be using native $NEAR on NEAR and similar on Ethereum.
2. If they send all the $NEAR to AURORA, and tried to go back, they will have all the tokens wrapped, and will not have enough $NEAR to unwrap it.
3. Direct transfers between Ethereum and Aurora are not possible today using this approach, since the tokens needs to be wrapped first when they arrive into NEAR, before being transferred to Aurora.

The third point can be addressed using the help of a smart contract, but still two first points remain.

Proposal

Create a contract on NEAR IntoAurora, and a contract on aurora NativeNear with the following methods:

class IntoAurora:
    NativeNear: AuroraAddress = '0x....'
    def deposit(self, target: AuroraAddress):
        """
        Call NativeNear contract inside aurora using `call` function interface from aurora contract
        """
        amount = env::attached_deposit()
        aurora.call(NativeNear, 'mint', target, amount)

    def withdraw(self, target, amount):
        """
        Try to burn this amount for the caller of the tx on Aurora, 
        and if the tx was successful send this amount to the target on NEAR
        """
        owner = env::predecessor_account_id()
        if aurora.call(NativeNear, 'burn', owner, amount) == 'Success':
            self.transfer(target, amount)

class NativeNear(ERC20):
    IntoAurora: AccountId = '_.near'
    def mint(self, target, amount):
        assert(msg.signer == implicitAddress(IntoAurora))
        super().mint(target, amount)

    def burn(self, owner, amount):
        assert(msg.signer == implicitAddress(IntoAurora))
        assert(self.balance[owner] >= amount)
        super().burn(owner, amount)

Workflow

NEAR -> Aurora

One single call is enough to make the transfer effective:
IntoAurora.deposit(target, {attached_near: amount})

Aurora -> NEAR

1. Transfer the tokens to the implicit address controlled by the target account on NEAR.
   `NativeNear.send(target, amount)

2. Withdraw the tokens
   IntoAurora.withdraw(target, amount)

Improved UX for withdrawals

The previous described workflow, will require that the tokens are sent first to the implicit account of the NEAR account id receiving the tokens. Manage ERC20 tokens from such an account is a problem if the transfer is stopped mid-way. Instead of forcing this approach, we can allow burning the tokens owned by address A, from address B, if B has enough allowance to support this. In this case, a call needs to be scheduled anyway to approve the tokens, but the tokens are not sent before hand.

def burn_with_allowance(self, token_owner, caller, amount):
        assert(msg.signer == implicitAddress(IntoAurora))
        assert(self.balance[token_owner] >= amount)
        assert(self.allowances[token_owner][caller] >= amount)
        self.allowances[token_owner][caller] -= amount;
        super().burn(token_owner, amount)

Ethereum <> Aurora transfers

Ethereum -> Aurora
To send $NEAR from Ethereum to Aurora, approach allowing transfer call is used, and the deposit function is invoked.

Aurora -> Ethereum
This will require a new withdrawal method that supports doing a function call after the withdrawal is successful (similar to ft_transfer_call from FT Standard).

[paouvrard]

@mfornet In case of Improved UX for withdrawals doesn't it mean that the user still needs to have some $NEAR in the NEAR account to "pull" tokens with allowance from aurora ? Also how would a direct transfer from Aurora to Ethereum work when the user doesn't have a NEAR account ?
Are there constraints preventing us from making the change in the engine and in the $NEAR locker to Ethereum, similarly to how the NEP-141 connector works and by adapting exit to NEAR and exit to Ethereum precompiles ?