Arcadia Collateral Risk Simulation: Progress Report 2
The second in a series of updates on the joint project by Llama Risk and Pragma Labs for the Arcadia v2 protocol.
In last week's progress report, we outlined the methodology we aim to use to define the risk parameters of Arcadia Lending. This week we will dive deeper into the simulation architecture and how we have implemented the methodology.
The report is structured into four parts:
Simulation Architecture: A breakdown of the various modules and classes within the simulation, along with their relationships.
Progress: Summary of the current state of the project, including implemented components and ongoing developments.
Next Week's Goals: Planned tasks and objectives for the upcoming week, focusing on integration, optimization, and testing.
Next Week’s Post: Preview of the content to be covered in the next update, including Simulation Verification and Validation measures.
Simulation Architecture
The Arcadia simulation architecture, as depicted in the UML (Unified Modeling Language) diagram, consists of various modules and classes that interact to simulate asset liquidation processes within the Arcadia v2 Lending Protocol.
Below we outline a description of the architecture displayed in Figure 1 between different modules:
Asset: This is the fundamental unit, representing various financial instruments. It includes details like its blockchain association, unique identifiers, and other relevant information such as its name and how its price is determined.
Chain: This term refers to a specific blockchain, providing necessary details for interaction like its unique ID and URLs for exploration and communication.
Asset Metadata: This component stores detailed information about an asset for simulation purposes, including its quantity, ownership share, and risk factors.
Asset Value And Risk Factors: This outlines the criteria used to assess an asset's risk, including how it affects borrowing and liquidation processes.
Assets In Margin Account: This links assets with margin accounts, indicating the assets held and their details.
Auction Information: This includes information on auction processes for assets, such as ownership details, starting conditions, and current status.
Liquidation Process:
Lending Pool Liquidation Config & Liquidation Config: These configuration settings outline the rules and parameters for how liquidations are conducted, including fees, the duration of processes, and how prices are adjusted.
Liquidation Engine: The core system responsible for managing liquidations, which includes functionalities for updating auction details, placing bids, and carrying out liquidations where required.
Liquidator: These are the agents or entities tasked with identifying accounts that can be liquidated and executing the auction processes.
Margin Account: Represents the accounts of participants, showing what assets they hold, their debts, and the base currency for their valuations.
Simulation Execution:
Pipeline: The framework that coordinates the simulation, setting its timeline, and managing interactions between accounts, liquidators, and the liquidation process.
Simulation Time: Manages the timing aspects of the simulation, such as tracking the current block and timestamp, and updating asset prices as needed.
Supporting Components:
Slippage Calculator: This tool estimates how a trade's size might affect its price, important for understanding the potential profitability of liquidation actions.
Gas Estimator: Calculates the estimated Gas cost for different steps in the liquidation process.
Pricing Metadata & Price Strategy Methods: These define how asset prices are calculated, including various methods for price determination, such as using external data sources.
Simulation Metrics: Monitors various performance indicators and the simulation's overall health, including tracking the number of accounts in financial distress.
Exception Handling:
The system incorporates a variety of exception classes to address particular errors encountered during the simulation, such as issues with account liquidation eligibility, auction status, missing price data, liquidity shortages, and unpopulated price fields. These exceptions help maintain the simulation's integrity and reliability by providing clear error-handling pathways.
Progress
During week 5, we completed the implementation of Orchestrator.py and introduced three different Borrower Models based on Arcadia v1 Borrow data.
Orchestrator
An attentive reader may have noticed that the above simulation architecture displayed in Figure 1 allows a user to execute one simulation run with one set of parameters, yet to find meaningful answers to parameter settings for Arcadia v2, we need hundreds to thousands of runs of different parameter settings.
This is where the need for the orchestrator class arises. The Orchestrator is responsible for setting up various risk scenarios in which collateral assets and numeraire pairs are exposed to different market conditions and allows the execution of simulations in parallel.
class Orchestrator(Base):
"""
Brute force implementation of orchestrator, has no optimization
"""
start_timestamp: int
end_timestamp: int
simulation_time: SimulationTime
liquidation_engine: LiquidationEngine
liquidators: List[Liquidator]
no_of_margin_accounts: int
debt_init_model: Any
asset_ranges: Dict[Asset, Ranges]
exposure_range: range | list
numeraire: Asset
def prepare_simulation(self):
...
return parameter_sets
@staticmethod
def worker(params):
...
pipeline.event_loop()
def execute(self):
...
Attributes:
The Orchestrator manages the simulation's timeframe, environment, liquidation mechanics, and the agents executing liquidations. Additionally, it configures the simulation's scope, including the number of margin accounts, the value and risk exposure ranges of assets, and the base currency (numeraire) used for valuation.
Methods:
To be able to run the simulation in parallel, the Orchestrator has three key methods:
prepare_simulation(): Sets up the simulation by creating all combinations of asset risk factors and exposures for margin accounts, using combinations ofcollateral_factorandliquidation_factorandexposure.worker(): A static method that organizes and carries out the simulation for specific parameters, designed for parallel execution through multiprocessing.execute(): Initiates the simulation in parallel with Python's multiprocessing capabilities, spreading out parameter sets to various processes that each run a simulation instance.
Overall, the Orchestor is responsible for setting up the different risk scenarios by combining market scenarios with key asset parameters. This allows us to efficiently run different scenarios in parallel.
Borrower
We retrieved borrower data from v1 data and created borrow distributions. By assuming fixed strategies, we can arrive at the collateral distribution of a potential collateral portfolio at the initiation of the borrower accounts. We then can sample from the borrow amount and assume the maximum borrow based on the available collateral factor for a simulation run.
We are currently in the process of retrieving additional borrow data on Base and ETH for more alternative borrow models as suggested in last week’s methodology.
Goals for Week 6
The team's goal for the current week 6 can be broadly categorized into three buckets:
Refinement of the Simulation: This entails integrating additional components (i.e. Slippage and Gas in the Liquidator Profit Calculation) and testing additional optimization algorithms during the liquidation.
More Borrower Data: We aim to gather more borrower data
Verification & Validation Testing: We plan to test more verification and validation scenarios on real-world test cases.
Next Week’s Post:
In the next post, we will dive deeper into simulation verification and simulation validation measures, and update the reader on progress made within the week.
Disclaimer: Any Materials presented here might change with the uncovering of new insights during simulation validation and verification.