Provide icx value input in contract explorer

[nightowl121]

If the method used in the contract explorer is payable method, the contract explorer needs to provide a field to input the ICX value you want to send in the method.

Currently the explorer doesn't provide this option.

[robcxyz]

Hi @nightowl121 - I like this idea but to be clear, the contract explorer is based off pulling the contract's ABI and from that perspective, I don't think there is anything to distinguish an input value as being payable vs a non-payable. I could be wrong, this is not my domain as much. Someone else would know better.

But if that is the case, this is not possible to make as a default within the contract explorer but rather could be some toggle-able item that denominates in ICX (ie *1e18). This could also be left to another section that supports token transfers and other types of payment utilities.

If I am wrong though about payable not being in the ABI please let me know otherwise any feedback on the above is appreciated.

[nightowl121]

Here is an example of a method in ABI showing that the function is payable.
https://tracker.icon.community/contract/cx21e94c08c03daee80c25d8ee3ea22a20786ec231#code
{ "inputs": [ { "name": "_path", "type": "[]Address" }, { "default": "0x0", "name": "_minReceive", "type": "int" }, { "default": null, "name": "_receiver", "type": "str" } ], "name": "route", "outputs": [], "payable": "0x1", "type": "function" }

[robcxyz]

@nightowl121 Ah got it. But then if there are multiple int fields, is it possible to differentiate between an icx denominated value vs standard int? Also does payable strictly define icx transfers or could they be token transfers as well which could have different decimals and can't be assumed?

Don't get me wrong, we should do something and not trying to figure out a reason to not incorporate this somewhere, just can't make assumptions which here and if payables / decimals etc need to be accounted for, we can build a separate tool for that

[nightowl121]

Payable is in it's own a different field or parameter. So if there is a payable function, you should add a different input box mentioning the amount of icx to send in the transaction. You can either take the input in ICX or loop (10^-18 ICX) whichever will give better UX. Etherscan allows option to add 18 zeros at once. Other parameters remain same as it is.

Payable will always be for ICX. It won't handle any other token transfers at least in ICON.

In short, if this feature has to be integrated in the current contract explorer, the additional logic would be as:

• Check if a method is payable. For payable method, add an additional input box mentioning the amount of icx to send. 0 if not provided by user.
• For rest methods, continue as it is.

[robcxyz]

@nightowl121 - I like this idea. So basically any payable method should by default be in ICX and then perhaps have a toggle between Loop and ICX here.

Would be like a radio button next to Query

Agree?

[nightowl121]

Yeah sounds good.