Some General Queries on xcall

[hemz10]

Hi Team,
To better understand the functionality of xcall before testing, I have some doubts. Can Someone please help me with answers

Questions

1. What is the role and functionality/permissions of admin and owner
2. What is protocol fee ? Where can we know if the exact fee is getting deducted ?
3. To whom is protocol fee transferred ? Address we add in protocol fee handler or to the owner ?
4. What is Protocol fee handler ? what is accured_fees ?
5. Fee logic in send packet
6. How does timeout height works in send packet ? What will happen if packet doesn't execute before the timeout height ?
7. Execute rollback is executed on failure of transaction, what if execute rollback itself fails ?
8. Is there any default fee value ? What will be the fee when set_fee is not set ?
9. Any maximum restriction on setting fee ?
10. How will set fee works when there are multiple admins ? Will the new fee replace already set fee ?
11. Can there be Multiple owners ?

If someone has any other questions please feel free to add it.
Thanks in Advance !!

[MuhammedIrfan]

@pragyanshrestha-ibriz @FezBox @izyak Kindly help with these queries

[pragyanshrestha-ibriz]

@sdpisreddevil can you please help with these queries?

[AntonAndell]

1. Owner defines the admin and has the ability to update the contract. Something that can be removed when we are confident the design does not need any more changes. Admin sets fee handler and protocol fee in traditional btp XCall.

In Xcall there will be two fee types. Protocol fee which is the fee for using XCall infrastructure. And then there will also be a relayer fee to incentivize the relayers. For the initial design its fine if all fees are kept in the XCall contract.

The protocol fee handler is something defined for BTP and wont necessarily be something we eventually use for XCall.

How ICON will claim accrued protocol fees is still unknown and will have to be thought more of at a later point. Protocol fee can be 0 if not configured.
The process of claiming relayer fees will be designed later as well. The initial thought is to store msgid:fee in XCall. Where it can be claimed via a IBC message from a counterparty XCall.

The feelogic in sendPacket:
A user call sendMessage with 100 xTokens.
If Protocol fee is 15 xTokens.
15 xTokens is deducted.
90 xTokens is stored as relayer fee for that message id.
Eventually we might want min and max for relayer fee.

6. Timeout is something native to IBC you can check that specification on how it will be handled internally. But if timed Out
   onTimeoutPacket callback will be called on XCall which will execute a rollback. Same as if the execution would have failed.
7. Then the whole transaction fails then the rollback can be re executed. If it is a permanent failure manual intervention will be required from the contract that causes the failure.
8. Lets just go with 0 IMO
9. No concern atm.
10. Overwrite sounds fine for now
11. Depends on blockchain implementation. On ICON this is not possible. Preferably when design is finished there shouldn't be any direct owner for security and decentralization reasons.

[hemz10]

Hi @AntonAndell / @izyak ,
Another question. Can a owner add multiple admins ?

[AntonAndell]

No it should just be one admin for now, but can be chain specific.

[hemz10]

Ok thanks, got it so just one admin for now.

[AntonAndell]

In general fee design is not completely finished, especially since ICONs goal of focusing on XCall. But if there is anything you can focus less on during testing it is the fee part. The most important and hardest part of the project is the consistent and safe communication. Since IBC support callbacks with relayer address the fee part should be trivial once finalized and designed.

[izyak]

Fee handler will most probably be a simple contract that can accept tokens and nativecoin.

For fee, if this product is to be extended for other cases than just token transfers, we'll probably only use nativecoin for fee, but then again, it's yet to be finalized.

Accrued Fees:
Based on btp xcall, when the fee handler is to be replaced, all existing fees should go to current handler. This amount is referred to as accured fees.

[hemz10]

Thank you @anton and @izyak !