Approval Step for BTP Message transfer on ICON

[manishbista28]

Terms Used: NativeCoin, NativeToken, WrappedCoin
NativeCoin: ICX for ICON
NativeToken: IRC2 Token created on ICON (sICX, bnUSD)
WrappedCoin: Tokens created on other chains and which has been registered as IRC2 token on ICON (BNB, ICZ, BUSD, etc)

Current Implementation:
Approve step is different for native token and wrapped coin in ICON side of contract.
For native token, transfer() method of token contract is called with BTS Contract address as "_to" argument
For wrapped coin, approve() method of token contract is called with argument "spender" as BTS Contract address

For EVM chains (SNOW, BSC), approve step is simply done by calling approve() method.

Questions:

1. Why should native token use transfer() method for approval if IRC2 has approve method available ?
2. If a user accidentally transfers a wrapped coin to BTS using transfer() method in case of approve(), what are the consequences ? Is the amount reclaimable ?
3. Could a consistent method of approval be possible ?

@izyak @sdpisreddevil @bbist
I'd like to request you to check the queries above.

[izyak]

IRC2 is the token standard on ICON (similar to ERC20, but with a few differences).
ERC20 has the logic of allowance and approval, where certain amount of tokens can be approved to other address. This is required, when a contract has to move the funds of user. User approves certain amount of ERC20 tokens to the contract, and contract implement any logic they want to. Like moving the funds, and setting certain amount to locked on our case.

However, on IRC2, there is no allowance and approval. The transfer function of IRC2 checks if the _to address, or the destination is a contract. If it is a contract, tokenFallback method of the contract is called. So, the contract, can implement tokenFallback method, and implement any logic they need in the tokenFallback method, which bypasses the need to implement approve and allowance on IRC2.

[izyak]

If a user accidentally transfers wrapped coin to BTS using transfer method, the amount user transfers is sent to the BTS Contract. The amount will be set as usable.
However, on based on the current implementation of balanceOf method, (which checks for allowance for wrapped tokens), the usable amount is not visible. We can't see the balance user transferred to BTS Contract by calling the balanceOf method.

User can claim the amount back by calling refund method.

[FidelVe]

im checking the BTP contract and it doesnt have the refund method, it has reclaim.

do you mean reclaim?

here is the link for the BTP contract on lisbon

Link

[izyak]

There is a internal refund method.
If txn fails on destination chain, contract will try to refund back to user on source chain.
If this refund process fails, the amount will be set to refundable and user can claim it later by calling reclaim

Also, on ICON, if you have to transfer tokens, first you transfer to BTS Contract, and call transfer method. However, if you just transfer tokens to BTS Contract, but then change your mind and do not want to transfer cross chain, you can reclaim those tokens.

[FidelVe]

thanks for the reply.

quick question, the response from balanceOf returns an object with keys, locked, refundable, usable and userBalance

tell me if im wrong with this descriptions:

• locked: amount of token that has been bridged cross chain.
• refundable: amount of tokens that can be refundable back to the user or used to transfer crosschain
• usable: userBalance - locked
• userBalance: total balance in the wallet.

is this correct? im just guessing by the names because I havent found a definition for these in the repo.

[izyak]

Currently, the logic for approval on wrapped tokens is coded on the BTS Contract itself. The javascore BTS should be changed for respective logic and should be updated.

[mj-hana]

@izyak IRC2 seems to define approval/allowance functions - https://docs.opendevicon.io/score-library/irc2standard/irc2
What's the benefit of doing it this other way for some ICON tokens?

[izyak]

@mj-hana
The above implementation seems like an extension of IRC2 than a general IRC2 contract.

The actual IRC2 implementation is here:
Standard: https://github.com/icon-project/IIPs/blob/master/IIPS/iip-2.md
Implementation: https://github.com/sink772/javaee-tokens/blob/master/tokens/src/main/java/com/iconloop/score/token/irc2/IRC2Basic.java