Interfaces Fixes

[jalextowle]

Resolved Issues

Fixes: #974.

Description

Updates IHyperdriveFactory to have all of the functions in the interface.

Review Checklists

Please check each item before approving the pull request. While going through the checklist, it is recommended to leave comments on items that are referenced in the checklist to make sure that they are reviewed. If there are multiple reviewers, copy the checklists into sections titled ## [Reviewer Name]. If the PR doesn't touch Solidity and/or Rust, the corresponding checklist can be removed.

@jrhea

Solidity

• [ ] Tokens
  • [ ] Do all approve calls use forceApprove?
  • [ ] Do all transfer calls use safeTransfer?
  • [ ] Do all transferFrom calls use msg.sender as the from address?
    • [ ] If not, is the function access restricted to prevent unauthorized token spend?
• [ ] Low-level calls (call, delegatecall, staticcall, transfer, send)
  • [ ] Is the returned success boolean checked to handle failed calls?
  • [ ] If using delegatecall, are there strict access controls on the addresses that can be called? It shouldn't be possible to delegatecall arbitrary addresses, so the list of possible targets should either be immutable or tightly controlled by an admin.
• [ ] Reentrancy
  • [ ] Are functions that make external calls or transfer ether marked as nonReentrant?
    • [ ] If not, is there documentation that explains why reentrancy is not a concern or how it's mitigated?
• [ ] Gas Optimizations
  • [ ] Is the logic as simple as possible?
  • [ ] Are the storage values that are used repeatedly cached in stack or memory variables?
  • [ ] If loops are used, are there guards in place to avoid out-of-gas issues?
• [ ] Visibility
  • [ ] Are all payable functions restricted to avoid stuck ether?
• [ ] Math
  • [ ] Is all of the arithmetic checked or guarded by if-statements that will catch underflows?
  • [ ] If Safe functions are altered, are potential underflows and overflows caught so that a failure flag can be thrown?
  • [ ] Are all of the rounding directions clearly documented?
• [ ] Testing
  • [ ] Are there new or updated unit or integration tests?
  • [ ] Do the tests cover the happy paths?
  • [ ] Do the tests cover the unhappy paths?
  • [ ] Are there an adequate number of fuzz tests to ensure that we are covering the full input space?

@jrhea

Solidity

• [ ] Tokens
  • [ ] Do all approve calls use forceApprove?
  • [ ] Do all transfer calls use safeTransfer?
  • [ ] Do all transferFrom calls use msg.sender as the from address?
    • [ ] If not, is the function access restricted to prevent unauthorized token spend?
• [ ] Low-level calls (call, delegatecall, staticcall, transfer, send)
  • [ ] Is the returned success boolean checked to handle failed calls?
  • [ ] If using delegatecall, are there strict access controls on the addresses that can be called? It shouldn't be possible to delegatecall arbitrary addresses, so the list of possible targets should either be immutable or tightly controlled by an admin.
• [ ] Reentrancy
  • [ ] Are functions that make external calls or transfer ether marked as nonReentrant?
    • [ ] If not, is there documentation that explains why reentrancy is not a concern or how it's mitigated?
• [ ] Gas Optimizations
  • [ ] Is the logic as simple as possible?
  • [ ] Are the storage values that are used repeatedly cached in stack or memory variables?
  • [ ] If loops are used, are there guards in place to avoid out-of-gas issues?
• [ ] Visibility
  • [ ] Are all payable functions restricted to avoid stuck ether?
• [ ] Math
  • [ ] Is all of the arithmetic checked or guarded by if-statements that will catch underflows?
  • [ ] If Safe functions are altered, are potential underflows and overflows caught so that a failure flag can be thrown?
  • [ ] Are all of the rounding directions clearly documented?
• [ ] Testing
  • [ ] Are there new or updated unit or integration tests?
  • [ ] Do the tests cover the happy paths?
  • [ ] Do the tests cover the unhappy paths?
  • [ ] Are there an adequate number of fuzz tests to ensure that we are covering the full input space?

@mcclurejt

Solidity

• [ ] Tokens
  • [ ] Do all approve calls use forceApprove?
  • [ ] Do all transfer calls use safeTransfer?
  • [ ] Do all transferFrom calls use msg.sender as the from address?
    • [ ] If not, is the function access restricted to prevent unauthorized token spend?
• [ ] Low-level calls (call, delegatecall, staticcall, transfer, send)
  • [ ] Is the returned success boolean checked to handle failed calls?
  • [ ] If using delegatecall, are there strict access controls on the addresses that can be called? It shouldn't be possible to delegatecall arbitrary addresses, so the list of possible targets should either be immutable or tightly controlled by an admin.
• [ ] Reentrancy
  • [ ] Are functions that make external calls or transfer ether marked as nonReentrant?
    • [ ] If not, is there documentation that explains why reentrancy is not a concern or how it's mitigated?
• [ ] Gas Optimizations
  • [ ] Is the logic as simple as possible?
  • [ ] Are the storage values that are used repeatedly cached in stack or memory variables?
  • [ ] If loops are used, are there guards in place to avoid out-of-gas issues?
• [ ] Visibility
  • [ ] Are all payable functions restricted to avoid stuck ether?
• [ ] Math
  • [ ] Is all of the arithmetic checked or guarded by if-statements that will catch underflows?
  • [ ] If Safe functions are altered, are potential underflows and overflows caught so that a failure flag can be thrown?
  • [ ] Are all of the rounding directions clearly documented?
• [ ] Testing
  • [ ] Are there new or updated unit or integration tests?
  • [ ] Do the tests cover the happy paths?
  • [ ] Do the tests cover the unhappy paths?
  • [ ] Are there an adequate number of fuzz tests to ensure that we are covering the full input space?

[coveralls]

coverage: 93.375%. remained the same when pulling 42526f5538842a510d647a09d7342e029539f791 on jalextowle/interfaces/cleanup into c2f8f0be9afe939e8162250c3619b23b07c59f1c on main.

[github-actions[bot]]

Hyperdrive Gas Benchmark

Benchmark suite	Current: 42526f5538842a510d647a09d7342e029539f791	Previous: 78a1b5959270a1ea5d10fbee8be2019bde04e919	Deviation	Status
addLiquidity: min	33893 gas	33893 gas	0%	🟰
addLiquidity: avg	144381 gas	144492 gas	-0.0768%	✅
addLiquidity: max	428319 gas	428319 gas	0%	🟰
checkpoint: min	40220 gas	40220 gas	0%	🟰
checkpoint: avg	104075 gas	104036 gas	0.0375%	🚨
checkpoint: max	212154 gas	212154 gas	0%	🟰
closeLong: min	31517 gas	31517 gas	0%	🟰
closeLong: avg	138589 gas	138644 gas	-0.0397%	✅
closeLong: max	2640435 gas	2640435 gas	0%	🟰
closeShort: min	31394 gas	31394 gas	0%	🟰
closeShort: avg	132800 gas	132896 gas	-0.0722%	✅
closeShort: max	227565 gas	227553 gas	0.0053%	🚨
initialize: min	31305 gas	31305 gas	0%	🟰
initialize: avg	253637 gas	253636 gas	0.0004%	🚨
initialize: max	322898 gas	322760 gas	0.0428%	🚨
openLong: min	33437 gas	33437 gas	0%	🟰
openLong: avg	167179 gas	166991 gas	0.1126%	🚨
openLong: max	253057 gas	253057 gas	0%	🟰
openShort: min	33959 gas	33959 gas	0%	🟰
openShort: avg	170244 gas	170515 gas	-0.1589%	✅
openShort: max	385545 gas	385545 gas	0%	🟰
redeemWithdrawalShares: min	31227 gas	31227 gas	0%	🟰
redeemWithdrawalShares: avg	62264 gas	62052 gas	0.3416%	🚨
redeemWithdrawalShares: max	167572 gas	167572 gas	0%	🟰
removeLiquidity: min	31191 gas	31191 gas	0%	🟰
removeLiquidity: avg	223034 gas	223882 gas	-0.3788%	✅
removeLiquidity: max	399303 gas	398863 gas	0.1103%	🚨

This comment was automatically generated by workflow using github-action-benchmark.