Open hats-bug-reporter[bot] opened 5 months ago
It is a way too specific of an edge-case and I see no reason for an Orchestrator with a 19 decimal issuance token to set the virtual supply to 1. But good catch on the edge-case.
@0xmahdirostami
I took the initial supply numbers from the existing E2E tests and it is actually perfectly fine to set the initial supply to 1 if the token decimals are the same. As mentioned in my recommendation the initial supply needs to be at least the difference in token decimals. And used 19 decimals in the example just to show that even one decimal place out causes the issue.
@PlamenTSV
Github username: -- Twitter username: rnemes4 Submission hash (on-chain): 0xc4e1d972c648049ac67f27cf0ab33d445e5b01968a8160c3b54ba91721fb017e Severity: medium
Description: Description\ In the
FM_BC_Bancor_Redeeming_VirtualSupply_v1.init()
function it is possible to initialise with a combination of Issuance token decimals and initial issuance supply that will leave the contract in a state where it is impossible to call thebuy
function without it reverting.Attack Scenario\
init()
is called with an issuance token having 19 decimals and the virtualIssuanceSupply is set to 1 (in this scenraio it should have been set to at least 10) Bob tries to make abuy
with any deposit value, but the function will revert due to the code at line 400 returning zero:being called with: virtualIssuanceSupply = 1 issuanceTokenDecimals = 19 eighteenDecimals = 18
This will return 0 as proven by the following unit test
This Zero value is then passed as the first argument to the call to
formula.calculatePurchaseReturn
in the following function.calculatePurchaseReturn
will then revert due to the fact_supply
has been rounded down to ZeroAttachments
init()
function to ensure that thevirtualIssuanceSupply
is initialised to a minimum amount compatibale with the relative token decimals. i.e if Issuance token has 19 Decimals the thevirtualIssuanceSupply
should be at least1e1 or 10 (1e(issuance token decimals - 18))