Payments storage packing #942
Conversation
| uint128 previousPricePerSymbol, | ||
| uint128 newPricePerSymbol, |
There was a problem hiding this comment.
How much gas savings are we talking here? I assume we're going to price this in mwei, but I wonder if we should just keep this in wei if the cost savings are trivial. This allows us to express any pricing better granularity
(If we do need to use mwei, can we document that?)
| function getOnDemandAmounts(address[] memory _accounts) external view returns (uint256[] memory _payments) { | ||
| _payments = new uint256[](_accounts.length); | ||
| function getOnDemandAmounts(address[] memory _accounts) external view returns (uint128[] memory _payments) { | ||
| _payments = new uint128[](_accounts.length); | ||
| for(uint256 i; i < _accounts.length; ++i){ | ||
| _payments[i] = onDemandPayments[_accounts[i]]; |
There was a problem hiding this comment.
should we validate if _accounts[i] exists in onDemandPayments?
There was a problem hiding this comment.
DASM link looks good.
For storage packing, I think we can revert back to using uint256 for onDemandPayments and in the future we will need to add the collected amount to the same slot (like _onDemandPaymentsCollected_ || _onDemandPaymentsDeposited_. The current deposit function will only take a uint128 to update the lower slot, and a new collect function only callable by operators who supply a payment verification over the claimed collection.
Sorry that this is going back and forth a little bit
updates config params from uint256 -> uint128