You have a dynamic fee retrieval such as uint256 switchFee = getConsolidationFee(). There is then a check to make sure the user has enough funds to cover that fee multiplied by the batch size: require(msg.value >= batchSize * switchFee, InsufficientFeePerValidator());
If I were to call the switch function with 200 validators to change from 0x01-0x02, each validator call would have the same fee. Assuming the queue is empty, it would be 1 wei initially. Calling the consolidation contract will do three things:
- Make sure there is enough ETH to cover the fee
- Increase request count by 1
- Add the request to the queue
Once the request has been added to the queue the transaction will be considered a success and Pectra.sol will then iterate to the next public key.
The question: Given Pectra.sol only makes a check for the queue fee once, wouldn't the queue size of the consolidation contract always increase to a point where the fee sent from Pectra.sol not be sufficient to cover the queue fee assuming a large enough batch size?
You have a dynamic fee retrieval such as
uint256 switchFee = getConsolidationFee(). There is then a check to make sure the user has enough funds to cover that fee multiplied by the batch size:require(msg.value >= batchSize * switchFee, InsufficientFeePerValidator());If I were to call the switch function with 200 validators to change from 0x01-0x02, each validator call would have the same fee. Assuming the queue is empty, it would be 1 wei initially. Calling the consolidation contract will do three things:
Once the request has been added to the queue the transaction will be considered a success and Pectra.sol will then iterate to the next public key.
The question: Given Pectra.sol only makes a check for the queue fee once, wouldn't the queue size of the consolidation contract always increase to a point where the fee sent from Pectra.sol not be sufficient to cover the queue fee assuming a large enough batch size?