Hello Petro, thank you very much for taking the time to review the framework and for providing your feedback. I’m happy to provide further clarity on the circumstances under which the parameters you mention may be altered, as well as some additional context into the rationale for their inclusion and the security processes that changes will follow.
1. Primary and Secondary Oracles
The decision to introduce governance around the oracles is primarily for security reasons. Oracles are an unavoidable external dependency of CDP systems. We are launching with Chainlink as our primary price source, which has been highly reliable and secure over the years. Although an oracle failure or misreporting is highly unlikely, the possibility exists. Hence, we decided that the responsible way to ensure eBTC’s resilience, as advised by the security experts who oversaw the project’s development, was to allow for the possibility of changing it if necessary.
The same rationale applies to the Secondary oracle (fallback) and with a more straightforward justification; there simply weren’t other lindy enough options during the design stage. Therefore, we decided to launch without one. However, as the market has evolved, great candidates for a fallback oracles have emerged, boasting strong technology and a decentralization ethos. The evaluation of these options is ongoing, and it is likely that one will be introduced in the months after launch.
As for the evaluation and implementation process, a decision to swap one of the oracles will be made public, along with a thorough justification. In addition, robust security due diligence will be performed on the different potential candidates, analyzing their protocol security profile and historical performance. Finally, a simulation will be conducted against the system’s state and risk scenarios to ensure proper integration. The results will be made public before any swap is executed, giving the community and users confidence in the change.
Changing the Primary Oracle must undergo a 7-day timelock period. This means that, by design, this operation can’t be performed reactively and rushed. In this scenario, the system will rely on the existence of a fallback Oracle to carry the system forward while a solution for the Primary is devised and implemented following the aforementioned process.
2. Collateral Feed Source
As explained in the eBTC Builder Update - January, within the “Oracles & Price Feeds” section, the imminent deprecation of the ETH/BTC (0.5%) Chainlink feed led to a pivot in oracle design to use a combination of BTC/USD + ETH/USD + stETH/ETH feeds, each with a deviation threshold of 0.5%. However, this approach could result in a maximum theoretical deviation threshold of 1.5% for the aggregated oracle, which is not ideal. This value determines the redemption fee’s base rate.
After thorough analysis, it was concluded that the likelihood of a significant depeg in the stETH/ETH pair, especially after The Merge, is lower than the chances of an oracle malfunction. For this reason, and to achieve higher efficiency within the system, it was decided to consider stETH/ETH as 1:1 by default, with the possibility of introducing their true rate if deemed necessary. This led to the introduction of the Collateral Feed Source parameter, a boolean parameter that signals the system to consider the stETH/ETH price feed in the event of a meaningful depeg.
The Minimized Governance framework will launch with this parameter protected by a 2-day timelock. Conversations have started with security monitoring partners to develop security automation, allowing a bot to trigger the change whenever a depeg threshold is met. The parameter change and its implications have been thoroughly tested and audited, with no impact on user experience (outside, perhaps, of reducing the likelihood of redemptions when active, due to an increase in the redemption fee, but this is speculative).
3. Extensible Minting
eBTC was designed to be the most censorship resistant synthetic bitcoin in DeFi. This is the reason why, after careful consideration, the Liquity’s immutable model was originally chosen as a starting point for its architecture. However, after extensive research and simulation, the team encountered the same dilemma (or should I say Trilemma) faced by others in the decentralized stablecoin space: With current industry and technology limitations, it is virtually impossible to optimize scalability, stability, and decentralization equally in stablecoin design. This realization led to hard decisions, like pivoting from using naked ETH to stETH and introducing the Minimized Governance framework. Data and market trends have shown that the current design is better suited to achieve high levels of scalability and stability than a fully trustless system. Nonetheless, considerable effort has been and continues to be made to minimize trust vectors in the system and ensure a high degree of transparency and security.
This reasoning also inspired the introduction of the Extensible Minting functionality. Observing other protocols’ experiences, especially regarding stability, the team, advised by security and risk researchers, deemed it crucial to maintain the option to extend minting abilities to other systems. These could be stability modules similar to those introduced by projects like MakerDAO’s PSM or Frax’s AMOs (not that these would be pursued but to give you an idea). Extensible minting allows the system to adapt to new market trends, remain competitive and strengthen eBTC’s peg and security.
At this point, the criticality of this feature should be clear but perhaps also its risks. I will take this chance to address in here the concerns that you shared with me in private around the process and technical implications as I feel the additional education will be beneficial to the broader community.
In practice, the High Security TechOps multisig, through the 7 day timelock, will be the only permissioned actor to grant minting rights to any other entity. Minting rights will only be granted to special limiter contracts with hardcoded or Timelock protected minting rates. Any additional module added to the system will only be able to mint through one of these limiters, hence the other modules on the system, specially the CDP module will be protected from the abuse of any of the others. Nevertheless, any new modules will be designed with the same principles of censorship resistance, immutability and trustless that characterize the CDP system, minimizing new trust vectors.
In the same way as with the Oracles, the introduction of a new module will be a thorough processes with high levels of transparency, security dilligence and community involvement. Ultimately, it will be primarily BALCO who will inform of the need of the introducion of one of these modules from a stability and scalability perspective. Once the need is clearly justified through an exercise of community and experts feedback and research, the design and development of the parallel system will be conducted by the core development team under the advice of BALCO and other relevant experts. These same groups will perform the adequate risk assesment to define the best rate limits for the module, in the same way, they could advice on their modification at a later point if justified by data and after getting community feedback.
Why not limiting the minting rates at the core level?
Limiting minting rates at the core was thoroughly considered but ultimately dismissed due to its lack of benefits and introduction of disadvantages. A singular limit does not safeguard the system from abuse—a malevolent actor could simply employ multiple minter modules. Moreover, predicting the system’s growth size is challenging; overly restrictive limits could hinder modules’ effectiveness at larger scales. External rate limiters offer the flexibility to adapt to market trends and demands while enhancing accounting and transparency.
Protecting against malicious actions
The Minimized Governance framework is crafted to balance system adaptability and security, striving to maintain trustlessness. The 7-day timelock ensures that changes to critical features are deliberate and transparent. The forthcoming Transparency Dashboard, coupled with public Discord alerts, will keep the community apprised of timelock activities. As eBTC evolves, identifying and incorporating reputable industry guardians to veto any malicious Timelock actions will be paramount, enhancing the system’s integrity.
Final thoughts
Considerable effort has been invested in ensuring the eBTC system maximizes trustlessness, yet the introduction of features like Extensible Minting is a strategic measure to navigate the unpredictability of the DeFi landscape. These features are not concessions but preparations for thriving amid “unknown unknowns,” setting eBTC up for enduring success. A commitment to transparency, security, and community engagement remains paramount as the project advances, fostering confidence that these decisions will steer eBTC towards achieving its ambition as a leading synthetic bitcoin in DeFi.