Embedded Control on the Blockchain — RAI is hiring a Simulations Lead
Reflexer Labs is building the RAI “reflex bond”, a volatility-dampened synthetic instrument backed by ETH. We are decentralized money fanatics on a mission to create a stable and secure foundation for the DeFi ecosystem on Ethereum and the world. Our objective is for RAI to be a widely used collateral type for other DeFi projects, including crypto-dollars. By imbuing RAI with autonomy and minimizing governance, we aspire to build a financial system that outlives us — a money god.
This post explains the RAI simulation challenge and is intended for prospective hires. To get up to speed, please read our whitepaper and Reflex Bond explainer. If you know someone who might be interested, we’re offering a $500 referral bonus to whoever helps us find the right candidate.
On the journey to launching RAI as an autonomous system, a major part of our plan is to delegate responsibility of setting the interest rate to an algorithmic controller (PID) which targets system stability by automatically updating interest rates based on oracle price inputs. The proper parameterization of the controller is thus one of the most critical engineering challenges for RAI, especially given that we aim to minimize the ability of governance to update the parameters, likely freezing the parameter values entirely after some period of time. Given the difficulty and financial risk of tweaking the RAI controller parameters in production (and with real money), we are using computer simulations to build as much confidence in our initial parameters as possible.
RAI Design Objectives
One of the most interesting things about RAI is that the controller parameterization is largely what determines the behavior of the RAI asset. We know we want RAI to be “volatility dampened” with respect to ETH, but it’s the controller parameterization that determines how “dampened” RAI is relative to ETH in practice. Part of the design process for RAI thus involves getting feedback from traders and prospective RAI holders on their preferences for the extent of volatility dampening, and then using our RAI simulations to determine the controller parameters that result in the desired asset behavior.
Fortunately, we know the upper and lower bounds on the behavior of RAI. If RAI is more volatile than ETH, we will have failed. And if RAI is completely uncorrelated with ETH, we will have failed. Our ideal RAI is somewhere in between, correlated with ETH but less volatile.
We also want the behavior of RAI to be predictable. We want the traders and RAI holders making decisions about whether to include RAI in their portfolio or use it in their dapp to be able to easily reason about the behavior of RAI in various scenarios. This also means that communicating the simulation setup itself is also critical — for end-users to understand the expected behavior of RAI, they need to also understand the context in which its behavior was modeled.
The above is especially important given the dependence of RAI stability on the behavior of the market participants. RAI achieves stability by updating interest rates, but those interest rates don’t impact the market price of RAI directly, instead they are designed to incentivize RAI holders and borrowers to take certain actions (buy RAI, sell RAI, borrow RAI, repay RAI debt) that drive the market price of RAI to the desired equilibrium. Therefore, in order to properly model RAI, we must also do our best to model the agents involved in the RAI market ecosystem and their behaviors, especially their sensitivity to interest rate updates.
RAI Design Phases
The RAI system will run in a complex environment — the public Ethereum blockchain. To accurately model the environment, we would need to consider a host of factors, including:
- Ethereum (blocktime, gas price fluctuations)
- Oracles (price feed update delays)
- Market Liquidity (RAI/ETH)
- ETH Outlook (bullish vs. bearish)
Beyond the environment, there are several types of agents that participate in the system:
- CDP holder
- Liquidity Provider (RAI/ETH)
- Hodler (RAI & ETH)
- Trader (actively manages position between ETH/RAI)
- Keeper / Arbitrageur
The agents also have their own behavioral traits:
- interest rate sensitivity → how quickly they take action in response to changing interest rates
- degeneracy → how much risk/leverage they are willing to take on
- laziness → how often they update their positions in general
Instead of building immediately towards a maximally complex model, we aim to build our simulation suite iteratively in phases, such that each phase has its own objective and contributes meaningful value to our research.
Phase 1 — Feasibility
Our first objective is to prove the feasibility of using the parameters from the RAI simulation in the production RAI system. In this phase, we are less interested in the correctness of the controller parameters and more interested in confirming that the behavior of a RAI testnet deployment launched with certain parameters will match the predicted behavior of a simulated deployment with the same parameters. The simulation can be quite simple for this phase, abstracting over market forces and agent behavior and focusing only on the interest rate control loop.
Phase 2 — Agents
Having established the feasibility of a basic version of our model, we’ll expand it by modeling the agents and market dynamics more concretely. In this phase, the goal of our simulation is to develop a robust agent based model of the RAI system, prepare a variety of scenarios to evaluate the behavior of our model, and narrow down the parameter range.
Phase 3 — Adversaries
As we start to narrow down our parameter search space, we will begin to include adverse conditions and agent-led adversarial efforts in our model. For example, simulating RAI if gas prices spike while ETH crashes (e.g. Black Thursday), and doing the same if agents collude to deprive the market of RAI liquidity. This phase is intended to battle-test our parameterization decisions so we can build confidence as we prepare for production deployment.
Phase 4 — Tuning
With our controller parameters battle tested in simulations, we’ll launch the RAI smart contracts on mainnet and collect data from the production deployment to tune our parameters further. In this phase we’ll want to update our model to correct for any inconsistencies with the live system, and model out any proposed parameterization updates. The ultimate objective of this phase is to have built enough confidence in our production controller that we feel comfortable revoking the power of governance to update it, and have the system operate with full autonomy.
RAI Simulations Lead
As you can see there’s a lot of engineering and simulations work to do to prepare RAI for launch, and with the Reflexer Labs seed round tantalizingly close to completion we’re itching to get started. If you’re a #DeFi nerd ready to summon a money god and think you’re the right person for the job, contact us or apply here. If you have a smart friend that might be interested, we’re offering a $500 referral bonus to whoever connects us with the candidate we decide to hire, so please pass this message along!
Here’s a summary of the responsibilities and expectations.
Responsibilities
- Design & implement a cadCAD model of the RAI PID control system
- Simulate the RAI system in a variety of market scenarios
- Propose control system parameterization based on simulation results
- Design & execute a plan for production tuning of the RAI control system
- Publish monthly progress reports on the simulations research
- Rally an open source academic community effort around applying control theory in the blockchain space
Expectations
- 1+ years professional crypto modeling experience
- 2+ years professional modeling experience
- MS in control theory, data science, or adjacent engineering discipline
- Expert level Matlab/python/cadCAD
- Clear technical writing ability
