@@ -115,7 +115,7 @@ contract ATokenVaultRevenueSplitterOwner is Ownable {
115115 }
116116
117117 /**
118- * @dev Splits the revenue from the given assets among the configured recipients. Assets must follow the ERC-20.
118+ * @dev Splits the revenue from the given assets among the configured recipients. Assets must follow the ERC-20
119119 * standard and be held by this contract.
120120 * @param assets The assets to split the revenue from.
121121 */
@@ -131,12 +131,11 @@ contract ATokenVaultRevenueSplitterOwner is Ownable {
131131 uint256 undistributedAmount = assetBalance;
132132 for (uint256 j = 0 ; j < recipients.length ; j++ ) {
133133 /**
134- * Due to floor-rounding in integer division, the sum of the amounts transferred may be less than the
135- * total amount to split. For a standard ERC-20 implementation this can leave up to `N - 1` units of
136- * each asset undistributed in this contract's balance, where `N` is the number of recipients.
137- * For aTokens this increases to `N` units. And considering the `assetBalance` adjustment previously
138- * done by decrementing a unit, the final potential undistributed amount goes up to `N + 1` units.
139- * These units may be distributed in the next `splitRevenue` call.
134+ * The `assetBalance` adjustment previously done by decrementing one unit will leave that unit of the
135+ * asset undistributed in this contract's balance.
136+ * However, due to floor-rounding in integer division, the sum of the amounts transferred may be less
137+ * than the intended total amount to split, leaving a few more units of the asset undistributed.
138+ * These units (also known as 'dust') may be distributed in the next `splitRevenue` call.
140139 */
141140 uint256 amountForRecipient = accumulatedAssetBalance * recipients[j].shareInBps / TOTAL_SHARE_IN_BPS
142141 - _amountAlreadyTransferred[assets[i]][recipients[j].addr];
0 commit comments