IPOR v2: Architecture For Growth

A description of the most notable IPOR v2 architectural changes and the reasoning behind their implementation.

IPOR Labs Team

6 min readOct 9, 2023

IPOR v2 introduces the following changes:

Diamond proxy — one router that needs approval; all functions are done via a delegate call. It makes everything easier, more composable, and gas-efficient.
Many functions can be executed “onBehalfOf” another user. It allows for 3rd party tools to build integrations, zaps, or batch transactions easily.
Pausing can be done selectively per function by a guardian angel instantaneously. Predefined sets of functions can be paused when required. Unpausing requires a timelock.
A new risk oracle has been added. It improves managing risk, market efficiency, and gas efficiency.
Demand-driven spread is introduced along with the traditional quant-modelled spread.
Continuously compounding interest is used across all the components of the app.
v2 is an iterative update of v1. All storage remains the same. No user action is necessary to migrate.

Why Upgrade?

The answer is simple.

The goal for v2 is to introduce a new architecture for future growth.

The solutions described below allow for more modularity, fewer manual actions for users, fewer approvals, and more gas efficiency and extensibility.

Diamond Proxy — Flexibility and Scalability

The most significant architectural change in IPOR v2 is the introduction of the Diamond Proxy pattern.

Previously, the IPOR Protocol was divided into components that could technically be used independently.

The downside of this solution was that all interactions required their respective approvals and had to be executed separately. v2 addresses that by changing the way the contracts speak to one another. Instead of individual independent components, a universal router delegates all the function calls to respective sub-modules. In this way, the state is kept in one place (therefore optimizing the gas cost), the number of transactions can be limited to 1, and approval for ERC20 transfers has to be granted only to the router. New sub-modules can be easily added and instantly tap into the unified storage that other sub-modules can also use.

Running “onBehalfOf” Functions

Another limiting factor in IPOR v1 was that users could only run each function on their own behalf. Msg.sender matched users with data stored in the memory. This led to the issue that the popular multi-call contracts could not use the full potential of IPOR Protocol contracts since the original user would be overridden with the multi-call’s address. Batching transactions, in this case, was much more complicated and more expensive.

The new, updated architecture allows the execution of many transactions “onBehalfOf” appointed address. This opens the door to many potential solutions with a middleman between the user and the Protocol, such as multi-call contracts or asset managers. Zapping, batching, etc., are feasible and gas efficient. This mechanism was actually required for the router, but as we see, it has many other benefits.

Updated Pausing Mechanism

Yet another architectural change can be found in the mechanism of pausing. Pausing is an emergency feature that all protocols wish not to use. However, when money is on the line, especially large amounts, you want to be extra diligent and prepared for the unexpected.

IPOR Protocol’s pausing strategy initially used a standard function call and was globally set per contract. Pausing was more like a 100mm cannon (or a shotgun) that would, in one go, disable large, pre-defined sections of the application.

v2 brings several improvements to that process. The pause function in v2 now accepts a list of method signatures that should be paused and executed only on the router. With this function, any combination of methods can be paused in one swift, instantaneous call.

This greatly benefits the protocol’s security since the pause scope can be limited to essential areas (rifle) should pausing be necessary in the first place.

Pausing can be executed instantly by an appointed guardian angel; reverse action — unpausing — requires using a timelock.

The Risk Oracle

The IPOR Protocol relies on several externally modeled constants to remain gas and capital-efficient. v1 had those hardcoded for gas efficiency. Unfortunately, managing the configuration parameters requires frequent contract upgrades, which are hard to manage and much slower than storing all that information in memory. On the other side, storing in memory is more costly and harder to change since you have to deal with data structures that are challenging to modify.

In v2, the goal was to improve the flexibility without sacrificing efficiency. This was challenging because on top of existing params, new ones were added:

leverage cap
collateral factor
a dynamic offered rate cap

With some wizardry on bits, the IPOR engineering team squeezed all the risk parameters per asset in a single memory block (256 bits). Those are then loaded in one call and committed to memory.

This is very gas efficient. Updating the risk parameters takes only 5k gas, and reading the whole set is only 800 gas.

v2 allows simple function calls in place of contract upgrades. The DAO can now gas-efficiently update the most appropriate Protocol configuration and quickly respond to market conditions, benefiting Protocol users.

Spread Model Updates

IPOR v2 introduces changes to the spread model. Since the release of v1, the Protocol has experienced several tweaks to the spread model, but this new iteration goes deeper.

v1 relied on quant models, and as much as this allowed for excellent capital efficiency, we have observed spreads become unreasonably high in times of significant volatility.

This is due to the limitations of modeling, where during certain conditions of normal volatility, a model may do an excellent job of pricing risk; however, during times of high volatility, this model may be overly cautious depending on the level of deviation from past levels.

v2 is meant to introduce the following improvements:

Price for demand,
Fix the lagging spread after a period of high volatility,
Allow for more speculative plays on the interest rates.

More details about the spread model will be described in a dedicated article.

Continuously Compounding Interest. Everywhere.

A notable change is the introduction of a continuously compounding interest rate model across all the elements of the IPOR ecosystem:

IPOR Oracle — when calculating IBT,
IPOR Swaps — when calculating both fixed and floating legs.

User Action Required?

The short answer is no.

The update is done on existing and running production contracts. From the user perspective, migrating liquidity is unnecessary; even already opened swaps remain valid.

Thanks for reading!

Leave a comment below if you have any questions. Be sure to join our Discord community to receive the most relevant updates on the IPOR Protocol and Interest Rates in DeFi. Meaningful product discussions are highly valued, and spam is strongly discouraged. Be cautious, and don’t fall for impersonators.

Follow IPOR Labs on social media so you never miss a beat!