Replies: 4 comments 5 replies
-
@jorisvial Yes, this looks good idea. Can you check this case too: There is another issue with current BTP that make it easy to spam. It nows return the full user's fund in case the failed transfer |
Beta Was this translation helpful? Give feedback.
-
@jorisvial As you proposed we should implement fee_min variable. Instead of having it in BSH would it be feasible to have it in BMC and let BSH fetch fee_min from BMC? To add more to the context, Workflow would be
*Needs a little more brainstorming |
Beta Was this translation helpful? Give feedback.
-
As @MuhammedIrfan pointed out, Fee paid = This is easy to implement, but makes the UX less intuitive, which I believe can be abstracted with BTP Dashboard. |
Beta Was this translation helpful? Give feedback.
-
Hi Team, My suggestion is to have the fixed fee in the BMC/Separate Contract registered in BMC and let the BSHs fetch the fixed fee from the BMC. ICON network would be managing it through BTP message. Initially, it can be done as a manual process and in the future, we can use ICON governance to set the fees in terms of USD and get the help of an oracle to set the fees with regards to native network currency. We will need to decide what goes into BTP 1.0. Also, we need to design the fixed fee considering the scenario Thanks |
Beta Was this translation helpful? Give feedback.
-
Hi.
I would like to start a discussion regarding the fee design in BTP, regarding the fee charged for making a BTP request.
Current situation
Right now BTP native coin and token transfers charges a fee based on a ratio. For example:
10 ICX
from ICON to the destination chain10 wrapped ICX * (1.0 - fee_ratio)
on the destination chainThe
fee_ratio
is set when uploading BSH contracts, but can also be changed throughsetFeeRatio
smart contract function.The problem
The main issue with this design is that it makes it very easy to spam different networks with BTP messages. On ICON, transactions fee are very cheap. Most of the time they are under
0.01 ICX
(which is around0.015 USD
at the time of writing this).If someone wanted to run a DDos attack, it would require minimal amount of money and effort.
Proposed solution to explore
We need to add a
fee_min
variable in BSH contracts. It is not very clear how thisfee_min
variable would be managed but I believe a good first approach would be to set thisfee_min
manually at first.For example, the day we launch BTP, we could simply decide to charge a minimum of
0.50 USD
per BTP message. Using the current exchange rate of each network native coin, we would set thefee_min
appropriately.Long term solution
Later on, maybe for BTP 2.0, we could have this
fee_min
set dynamically. Relays could be responsible for fetching the price of their respective networks and update thefee_min
value. Another less centralized approach would be to use Band Protocol to computefee_min
directly in the BSH contract.I hope this summary was clear. Please let me know what you think about this, and don't hesitate to point out flaws in that thinking. Also please share any other suggestion for protecting BTP network against spam.
Thank you.
Beta Was this translation helpful? Give feedback.
All reactions