IPOR protocol (Inter Protocol Over-block Rate) consists of two parts: the IPOR index and the automated market maker.
The index acts as an interest rate benchmark, aggregating lending and borrowing rates across multiple DeFi lending platforms to provide an objective view of current market conditions. The logic is off-chain. To access the index, users must call the IPOR Oracle contract.
The second part is the IPOR automated market maker. Unlike standard AMMs, IPOR AMMs allow users to open and close swaps and speculate on interest rates. A swap can be opened in two directions:
- Paying a fixed interest rate and receiving a variable interest rate
- To pay a variable interest rate and receive a fixed interest rate
An important role is that of liquidity providers. Liquidity providers provide liquidity to AMMs and receive a portion of the swap fee. The liquidity of the pool is automatically rebalanced between the protocol treasury and asset management to earn interest by depositing assets into Aave or Compound.
Revisions 1.0 and 1.1
IPOR partnered with Ackee Blockchain to conduct a security review of the IPOR protocol from June 1 to July 28, 2023, with a total of 59 engineering days. Revisions 1.0 and 1.1 were performed during one review.
Revision 1.2
IPOR provided an updated codebase containing fixes for several reported issues on August 22, 2023. However, not all problems have been resolved. With modifications, new contract Staked ETH pools have been introduced.
Revisions 1.3 and 1.4
IPOR delivered an updated codebase with fixes and several code changes on September 18, 2023, and the review was completed with time donations from 3MD. For revision 1.4, IPOR provided an updated codebase with fixes to the commit. 3d99b22. Other than updating the diffusion gradient value, no new changes were introduced.
Revision 2.0
IPOR contacted Ackee Blockchain to conduct an incremental security review of the updated codebase version. A total of 7 days of engineering time were donated during the period from December 4 to December 11, 2023.
Revision 2.1
IPOR has provided an updated codebase with fixes for reported issues. The codebase also includes changes to the stETH demand diffusion model and additional code refactoring.
methodology
Revisions 1.0 and 1.1
We began our review using static analysis tools. wake up. We then dug deeper into the logic of the contract and performed a manual code review. We then dug deeper into the logic of the contract and performed a manual code review. In parallel with the manual review, we created comprehensive fuzz tests of the most important parts of the system, such as opening/closing swaps and providing liquidity. For testing and fuzzing we use wake up Test framework. This test simulates real-world behavior, focusing on the full deployment of the protocol and unexpected call sequences and edge case values.
During our Fuzz testing, we discovered several issues reported by our customers and fixed them immediately. Collaboration with the team and the ability to respond quickly were critical to fuzz testing. This is where you’ll find more problems and edge cases, so you’ll need a protocol that works correctly. The final stage of Fuzz testing was run on newer commits (including bug fixes) than the initial commit. This commit will be referenced in revision 1.1.
During the review process, we paid particular attention to the following:
- Verify that the system’s calculations are correct
- Detection of possible financial attacks such as flash loans
- Ensures that the behavior of the protocol remains consistent across extreme case scenarios
- Check access control mechanism
- Detect possible reentrancy in your code
- Ensure proper storage handling
- Compare code logic to documentation
- I’m looking for common problems like data validation.
Revision 1.2
The first part of the review involved reviewing all modifications and ensuring they were consistent with our recommendations.
The second part of the review involved a manual review of the new codebase, which included four new contracts and changes to several previous contracts. Our new codebase allows us to provide liquidity for Ether, Wrapped Ether, and Staked Ether.
Revision 1.3
We began our review with a focus on fixing previously discovered issues. We then focused on new changes to the code base. After manual review, we updated the fuzz tests to be relevant to the new codebase.
Revision 2.0
Our review began with updating the fuzz tests to be relevant to the new, refactored codebase.
After the original fuzz test was updated, we started writing new fuzz tests for the latest part of the protocol that governs staked ETH. Through new fuzz testing, we discovered the two most serious issues reported in this revision.
Perform manual review in parallel with fuzz testing; wake up Static analysis was performed and all detections were discussed.
During the review we were focused. For the following code changes:
- A new risk indicator approach where parameters are signed and passed directly into the contract
- New stETH features — open and close swap
- Different diffusion logic models for stETH
- Administrator-only setter for time-weighted nominal data
- Period during which the swap does not close after initiation
- Code refactoring and new architecture compatibility.
range
Revision 1.0: The audit was initially performed on commits. 680c80f.
Revision 1.1: Review of the last delivered commit continued. 87c4d345.
Revision 1.2: A review of the commit has been performed. 1847f3e6.
Revision 1.3: A review of the commit has been performed. 553e1c7.
Revision 1.4: The review was performed on an updated codebase containing commit fixes. 3d99b22.
Revision 2.0: An audit has been performed on commits. 2c633063
Revision 2.1: An audit was performed on the updated codebase, which included fixes for issues reported for the commit. 125b3f3.
result
Here we have our result.
critical severity
C1: P&L calculated twice when liquidated
Severity High
H1: Solve formula
H2: Reentrant lock is broken.
H3: Clearing fee was calculated twice. liquidity pool balance
medium severity
M1: INTEREST_FROM_STRATEGY_BELO W_ZERO get back M2: Incorrect hypothetical interest formula
M3: Pool contributions are not updated when liquidity is repaid.
M4: Invalid event data
M5: Normalization of clearing fees
M6: IPOR_508 Return during deposit
M7: Clearing deposit reflected in LP balance
low severity
L1: Invalid decimal value
L2: Clearing deposit was counted twice in rebalancing logic.
L3: Aave incorrect APY formula
L4: Terminate the swap and reimburse the transaction cancellation.
L5: There is no data validation during setup. Redemption fee Eth
L6: Close Swap Insufficient Balance Revert
L7: Ipor Protocol Router Return and revert deleted data
warning severity
W1: How to use Salk optimizer
W2: Soap indicator rebalancing logic underflow
W3: Insufficient data validation in constructor.
W4: Missing array length check in initialization function.
W5: _calculateRedeemedCollatera lRatio underflow
W6: Rely on continuous block production
W7: Github secrets leaked
W8: Infinite authorization
W9: Swap direction verification is missing.
W10: Set array maximum index in constructor
W11: Ipor Protocol Router Memory constraint violation
Information Severity
I1: Unreachable code
I2: Use type(uint256).max instead of integer literal.
I3: Duplicate code
I4: Duplicate request
I5: Using the magic number
I6: Use forceApprove instead of safeApprove
I7: Misuse of the protocol can result in users losing their funds.
I8: Mixing _msgSender() and msg.sender throughout the codebase
I9: Duplicate logging of block.timestamp
I10: Unused code
conclusion
Here are the results of our review: 39 findings across revisions 1.0 – 2.0up to information to critical Seriousness.
Starting with revision 2.0, The new codebase is more readable than the old codebase. However, there are still some areas that can be improved. The NatSpec document is part of the interface contract and does not cover all features and libraries used (Risk IndicatorValidatorLib, for example). The code includes: Unused featuresTests are not written based on expected behavior, but instead based on the known output of the code under test.
We recommend IPOR as follows:
- Don’t write tests based on the output of the code under test.
- Static analysis tools, e.g. wake up) to keep the code base clean
- Please update the documentation to reflect the current state of the protocol (especially with regard to the new stETH part).
Ackee blockchain is full IPOR You can find the audit report with a more detailed description of all findings and recommendations. here.
We were happy to give our thanks. IPOR We look forward to working with them again.
final notes
After donations were made over a given period of time and all reported issues were resolved, the audit team found no issues that could have resulted in loss of funds or other catastrophic results. The audit team’s confidence is based on manual reviews and fuzzy testing models.
The IPOR team adheres to best practices. The code quality is high, the code includes NatSpec documentation, and general documentation is comprehensive. The IPOR team also provided many diagrams and mathematical equations to make the audit process more effective.
We cannot rule out the possibility that DoS of the protocol may occur due to some extreme circumstances. However, this is not directly related to security, but to the mathematical and structural complexity of the protocol.
The next step to increase trust in the protocol is to extend the fuzz testing and model all parts of the protocol that are not currently included in the fuzz testing (liquidity mining, governance).