Omniscia Alliance Block Audit
SplitPayment Code Style Findings
SplitPayment Code Style Findings
SPT-01C: Potential Conditional Optimization
| Type | Severity | Location |
|---|---|---|
| Gas Optimization | ![]() | SplitPayment.sol:L66, L74-L82 |
Description:
The current execution of splitTransfer will evaluate the fromThis_ boolean on each iteration of the shareholders inefficiently.
Example:
contracts/payment/SplitPayment.sol
59function splitTransfer(60 address token_,61 address from_,62 uint256 totalAmount_,63 Share[] memory shares_64) internal {65 unchecked {66 bool fromThis_ = from_ == address(this);67 for (uint256 i_ = 0; i_ < shares_.length; i_++) {68 // FixedPointMath uses checked math so disallows overflow.69 // Integrity checks disallow `0` shares.70 // If there is any dust due to rounding error in the71 // calculations it will favour the sender by simply never72 // sending the rounding error to any recipient.73 uint256 amount_ = totalAmount_.fixedPointMul(shares_[i_].share);74 if (fromThis_) {75 IERC20(token_).safeTransfer(shares_[i_].recipient, amount_);76 } else {77 IERC20(token_).safeTransferFrom(78 from_,79 shares_[i_].recipient,80 amount_81 );82 }83 }84 }85}Recommendation:
We advise the code to instead evaluate the fromThis_ boolean clause directly in a single if statement that splits the execution to two separate for loops. While this will increase the one-time deployment cost of the contract due to an increase in bytecode size, it will significantly optimize the gas cost of its execution and will additionally render the fromThis_ variable declaration redundant.
Alleviation:
The code was split as advised, ensuring that the if conditional is evaluated at the upper level and that each branch of the if structure contains a for loop within that is optimal and executes a single statement.
