# MerkleResistor: zero coinsPerSecond will brick tranche initialization and withdrawals

Integer division in MerkleResistor makes coinsPerSecond zero for small rewards or high upfront percentages, causing division-by-zero revert that bricks tranche init and withdrawals.

- Payout: Contest reward
- Severity: medium
- Program: FactoryDAO
- Credited: hickuphh3
- Disclosed: 2022-08-02
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2022-05-factorydao-findings/issues/107
- Library page: https://bugbountylibrary.com/r/c4%3A2022-05-factorydao%3AM-20
- Tags: domain:web3 impact:dos kind:contest platform:code4rena sev:medium tech:solidity technique:source-review vuln:accounting-error vuln:dos

**Target:** MerkleResistor.sol vesting/tranche contract
**Root cause:** coinsPerSecond is computed as (totalCoins*(100-pctUpFront))/(vestingTime*100) with integer division; small totalCoins or high pctUpFront truncates it to zero, and startTime = block.timestamp + vestingTime - (totalCoins/coinsPerSecond) then divides by zero.
**Steps:**
1. Set pctUpFront=0, totalCoins=100_000e2 (100k EURS), vestingTime=180 days
2. Compute coinsPerSecond = 100_000e2*100/(180*86400*100) = 0
3. Call initialization; startTime computation divides totalCoins by coinsPerSecond and reverts
4. Tranche never initializes, so vested-token withdrawals are permanently blocked
**How found:** Code reading of the coinsPerSecond and startTime formulas, noticing integer truncation to zero and the subsequent division by coinsPerSecond.
**Insight:** When a rate is derived by integer division and later used as a divisor, check small-numerator and high-percentage edge cases; scaling by a PRECISION constant mitigates truncation-to-zero.