Author: Nabil Abdellaoui, Data Science Lead (@randombishop)

Concrete was designed by a team with a deep blend of expertise in crypto, TradFi, credit risk management, quantitative analysis, data science and machine learning. With this powerful DNA, we approach the safety of our products through multiple lenses:

• TradFi and DeFi Business expertise.

• Classic models and math.

• Data and simulations.

In this article, we will focus on Data and Simulations, and showcase how we implemented our Simulation Engine.

Overview

The Simulation Engine is a Python library that replicates the logic and business rules of Concrete.

Given a price trajectory, and a set of assumptions and parameters, the Simulation Engine is able to predict the horizon outcomes.

By simulating thousands of scenarios, we can achieve multiple objectives:

• Test and validate the business logic of the protocol.

• Measure and manage our portfolio metrics.

• Design or fine-tune decisioning and pricing strategies.

• Produce data insights and serve as a business intelligence tool.

To use a famous movie metaphor, the Simulation Engine works like the Matrix: we, the architect, set up the rules of the system, then we plug a few thousands agents and let them live there for one year, which only takes 15 minutes in our time.

Then we collect information and learn from that Matrix to inform our decisions.

What are the inputs that we feed into the simulation?

The parameters that have an economic impact on our products can be classified into 3 categories:

• Market trajectories: token prices, market liquidity conditions, and lending protocols interest rates.

• User behaviors: their lending positions; when do they subscribe to protections? How likely are they to repay their loans?

• Liquidation Protection parameters: loan sizes, decision strategy, and pricing.

To better understand how the simulation engine works, let’s zoom in on some of these aspects.

Market Trajectories

In a typical Monte Carlo simulation, random trajectories are generated using a mathematical model (like geometric Brownian motion).

The challenge there is that for our purposes, not only do we need a price line for one token, but we need prices for multiple ones, plus the variable interest rates applied by lending protocols as well as information about liquidity conditions. Regarding the latter specifically, we need to know the slippage rates that will impact on-chain swaps at different points in time.

In the context of the simulation engine, we adopted an empirical data-driven approach to solve this challenge:

• We pull historical price data, Uniswap slippage rates, and Aave/Compound supply and borrow interest rates.

• We shuffle little chunks of this real reference trajectory to create a new random trajectory.

This method allows us to create trajectories that conserve the stylized facts of the original reference timeframe, but with completely random up/down/sideways profiles.

For example, as you can see in the correlation charts below, the real vs random trajectories conserve correlation patterns between different features.

User Behaviors

Now, remember we have thousands of bots that “live” in the Matrix for the duration of a random trajectory, then peacefully disappear without ever thinking about taking the red pill. But how do they behave during their lifetime? This is a challenging question that we tackled by decomposing it into smaller components, then solving each one separately, with as much data as possible, and also covering our blind spots with common sense assumptions.

Technically, the simulation engine is built in a modular way, so that each model can be easily refactored and improved as we learn more.

For example, what kind of lending positions do the simulation agents open? To address this question, we simply pulled the data from Aave/Compound and assumed that the users will continue to open and close positions for the same tokens at similar frequencies, sizes, and LTVs.

How likely are users to default on their loans? We also used Aave here to extract the average liquidation rates. We classify the users into a 4 by 4 grid. On one dimension we separate users by size (Small, Medium, Large, Whale); and on the other by risk level (from the riskiest degens to the diamond hands). Then we assign a default rate to each bucket based on historical liquidation rates.

The assumption here is that we will observe similar default rates from lending protocols to Concrete, which is not 100% true.

We might attract a riskier population because they have more incentive to protect their positions; or to the contrary we might bring in more conservative users, because you have to be somehow more thoughtful to purchase a protection.

This is an example of a blind spot where we simply won’t know until launch and update our assumptions with actual protocol data. In the meantime, the model is a good starting approximation, and we also added a stress factor to be able to tune the default rates up or down and simulate different variations.

Another important question: when will users buy protection policies? When their LTV is close to liquidation, but at a higher price? Or when LTV is still very healthy, to lock protection at lower cost? Again, we don’t have data yet to come up with strong assumptions, so we made this component very flexible and implemented a variety of rule-based models. This allows us to visualize the impact of different assumptions and the range of outcomes.

Protocol Parameters

Now, the fun part, this is how we design the economics of our products.

We developed a strategy to accept or decline new protection policies that guarantees solvency while maximizing capital efficiency. It relies on a model that forecasts future cash flows, verifies that we have enough liquidity to service protections, and offsets the decisions to the safe side using defensive parameters. It also calculates the optimal loan sizes to maximize value for the users while reducing risk under worst-case events. The simulation engine will raise an exception if a strategy fails to protect all users who bought a protection; thus we can filter and fine-tune only safe and viable strategies.

Note that we also developed an on-chain prototype of the decision model above, which is part of our roadmap to decentralization, more about this in a future article by our resident solidity and math guru.

For pricing, it’s simply an experimental and business-driven process to converge toward the optimal rates. The challenge here is how to predict the second-order effects. For example, higher prices will skew the population of users and potentially invalidate other assumptions.

To summarize our approach, the simulation engine allows us to validate and forecast the outcomes under some known set of assumptions, we apply the learnings to our protocol, we get real feedback, we adjust assumptions and parameters, rinse and repeat. It’s an iterative process in which the simulation engine plays an important role.

Results

The following results are shared to illustrate the discoveries achieved using the simulation engine, and are subject to change as we run more experiments. Please note that these have been purely internal simulation figures, albeit on real data and performance.

For example, the liquidation protection products are expected to generate top-end market APY when protecting ETH positions.

In addition to that revenue, the funds will be programmatically distributed across strategies to generate additional yield when not being used to service Concrete policies.

Key drivers of the rate of returns include variance in the underlying money market lending APYs. When the lending rate increases, gross revenues augment, and when the cost of borrowing increases, liquidation rates increase, augmenting Concrete protection revenues.

In broader terms, greater market volatility and robust flows in money markets have positive impacts on the protocol’s gross income.

A protection policy should cost an individual 0.50% to 0.75% of the calculated credit funding available in the user’s specific policy. A protection policy most commonly nets out in sizing to be between 10% to 20% of the deposited collateral value. For example, a $10,000 protection policy may cost a user $50 to $75 to open in a fixed fee and may be used to protect a collateral value of $65,000.

When claims are made on the protection policy line, Concrete issues them in 3 tranches. Each time a claim is made, the user owes a fixed fee - the Concrete Claim cost. Each claim is typically priced between 0.75% and 1% of the value deposited to protect the position.

In foreclosure, when a borrower has had all credit extended and then approaches the liquidation threshold of the lender Concrete repays the owed debt to the lender and recoups all deposited value + fees from the underlying collateral. Finally the protocol charges a 2% to 3% fee marked against the current value of the underlying collateral before returning all remaining assets to the borrower.

Also, we have demonstrated a 1.5 to 2 value for money factor in using Concrete’s protection policy compared to traditional liquidation costs and methodologies. ($1 spent on Concrete fees yields $1.5 to $2 accrual in expected position’s value.)

Conclusion

In summary, we built a robust framework to run simulations, enabling thorough testing, validation, and refinement of business logic, portfolio metrics management, and decision-making strategies. By delving into the intricate details of market trajectories, user behaviors, and protocol parameters, we achieve a comprehensive understanding of Concrete’s outcomes, paving the way for robust financial products.

So far, our results indicate competitive returns and mitigated risks.

We are also aware of the blind spots of the simulation approach, its inability to capture second order effects, and biases in the reference data.

A wise Chief Risk Officer once said: “Risk management is not playing a video game.”

This is why we don’t solely rely on the simulation engine, but also work with battle-tested classical models and quantitative frameworks. Stay tuned for more on this in future articles.

If you are interested in chatting about protocol deisgn, working together, or integrating within the Concrete ecosystem, please reach out to hello@concrete.xyz

Follow along on Twitter and join the community

Concrete Protocol: https://twitter.com/ConcreteXYZ

Blueprint Finance: https://twitter.com/Blueprint_DeFi