eBTC Minimized Governance Framework

[saj]

eBTC Minimized Governance Framework

Just six months ago, the eBTC purple paper was shared with the world, introducing eBTC’s commitment to being the most trustless, transparent, and censorship-resistant synthetic BTC in DeFi. A significant aspect of a protocol’s ability to achieve decentralization lies in determining which parts of its smart contracts are actually governable, if any. Often, protocols promote decentralization, but beneath the surface, there may be significant human intervention in crucial components. This is why eBTC protocol contributors decided to introduce a minimized governance framework that allows the most critical properties of the protocol to remain unchangeable, while enabling other less impactful parameters to be adjustable through delegated authority from token holders. This decision was made to enhance stability, unlock avenues for scalability, and, most importantly, bolster security.

The following post describes the decision making process and technical execution of these decisions around the governable parameters of the eBTC Protocol.

eBTC’s Minimized Governance

To understand eBTC’s minimized governance we must start with grasping what parts of the system are governable and which aren’t.

Immutable Ungovernable Components

• Minimum Collateral Ratio
• Critical Collateral Ratio
• Minimum CDP Size
• Collateral Type
• Number of Different Collaterals
• Gas Stipend
• Liquidation Incentives Algorithm
• Recovery mode
• Fee Recipient Address

The parameters above define the rules and terms under which users interact with the system. Any alterations to these would impact active users’ positions and violate the core principles of trustlessness and self-custody.

Governable Parameters

• Recovery Mode Grace Period Duration
• Flash Loan Fee
• Redemption Fee Parameters
• Protocol Yield Share %
• Sweeping Stuck Tokens
• Primary Oracle
• Secondary Oracle
• Collateral Feed Source
• Extensible Minting (Governance Admin)
• Redemptions Pausing
• Flashloans Pausing

As mentioned before, after thorough analysis and consideration, it was decided to preserve the ability to alter the parameters and features above in order to strengthen the stability, security and scalability of the system.

Fee Recipient Address Immutability

The protocol’s Fee Recipient address will be hardcoded to the DAO’s Treasury. This is a strategic move designed to cement the principle of decentralized ownership and revenue distribution within the eBTC protocol. This design choice ensures that the protocol’s generated revenue is directly and transparently allocated to the Badger DAO’s Treasury, thereby eliminating any possibilities of diversion or misappropriation of funds. By doing so, it not only reinforces the trust of participants in the protocol’s economic model but also guarantees that the revenue is reinvested or utilized in ways that are aligned with the collective interests of the community.

Decision Making around Parameter Changes

Stability, Economic Risk Management and Scalability

In the rapidly evolving landscape of DeFi, the eBTC protocol has distinguished itself through its innovative approach to governance. Central to this approach is the delegation of specific decision-making responsibilities to BALCO, a proficient team of experts from BlockAnalitica and Steakhouse. This strategic choice supports the protocol’s commitment to maintaining its foundational principles while navigating the complexities inherent in DeFi ecosystems.

The rationale behind entrusting BALCO with critical decisions surrounding stability, economic risk management, and scalability is multifaceted. Firstly, the nuanced nature of these areas requires a deep understanding of financial markets, CDP protocols’ dynamics, and blockchain technology—a combination of expertise that BALCO brings to the table. Their role in assessing and implementing changes ensures that decisions are informed by comprehensive risk analyses and cutting-edge industry practices, thereby enhancing the protocol’s resilience and adaptability.

Specifically, this group will be responsible for evaluating and determining changes related to the redemption and flash loan fee parameters, the protocol yield share %, extensible minting and pausing and unpausing redemptions and flashloans for potential economic risk reasons.

Security Parameters

For security parameters, such as the ability to pause certain functions in response to threats, the responsibility lies with the core development and security team. This arrangement ensures that actions can be taken swiftly and effectively, minimizing potential disruptions and safeguarding user assets. The specialization of these developers in security matters and their highest understanding of the system’s intricacies allows for continuous monitoring and rapid response to emerging threats or vulnerabilities, a critical component in maintaining trust and integrity within the protocol.

Specifically, this group will be responsible for evaluating and determining changes related to the pausing and unpausing of redemptions and flashloans for technical security reasons, determining the duration of the Recovery Mode’s grace period, swapping the secondary and primary oracle and changing the collateral feed source for the primary oracle.

Notes on Decision Making

The decision to allocate these responsibilities to groups of experts, is rooted in the recognition of the specialized knowledge and rapid decision-making capabilities required in these domains. While broader community involvement is crucial for fostering a sense of ownership and alignment with the protocol’s direction, the technical and strategic complexities associated with stability, risk management, and scalability necessitate a level of expertise and agility that is best found within dedicated contributors. This approach not only ensures that the protocol can adapt to the dynamic DeFi landscape but also maintains the core principles of trustlessness and security that are fundamental to its success.

These groups will continuously monitor the system and convene regularly to assess any necessary changes to the system over time. Once a decision has been reached by one of these bodies, it will be promptly announced to the public and communicated to the technical execution contributors for implementation, following the framework described in the subsequent section.

Technical Execution of Parameter Changes

The technical execution of parameter changes within the eBTC protocol is meticulously designed to balance agility with security, ensuring that any modifications are made transparently and without compromising the system’s integrity. This process is facilitated through two distinct timelock contracts: one High Security and one Low Security, with durations of 7 days and 2 days respectively. The High Security Timelock is overseen by a High Security Tech Ops multisig (4/6), requiring a higher signing threshold due to its critical nature, while the Low Security Timelock is controlled by a lower threshold Tech Ops multisig (3/6). Both timelocks are managed by the same core technical development experts, ensuring consistency and the highest standard in handling the protocol’s sensitive operations.

The initial team of eBTC TechOps contributors will comprise individuals who played a crucial role in developing the core protocol and who have a profound technical grasp of the system. In addition, a member from BALCO will be integrated into the team as a backup, with the possibility of adding another backup from the same group currently under consideration:

• Dapp-Whisperer
• Jwei
• MrBasado
• Abdullah
• Saj
• BALCO Member TBD

Once a decision regarding parameter changes is ratified and communicated to the community, the TechOps contributors proceed to queue the change in the appropriate timelock contract. The execution of the change occurs after the predetermined lock period has elapsed, ensuring a window for community feedback and oversight. During this waiting period, a comprehensive invariant test is conducted against the current state of the live system to assert that the implementation of the parameter change will not result in any security vulnerabilities.

Scope of Timelocks

The parameters governed by each timelock are carefully chosen based on their impact level and the degree of agility that they may require.

Low Sec Timelock Scope (2 days)

• Redemption Fee parameters
• Protocol Yield Share %
• Grace Period duration
• Pause redemptions and flash loans
• Flash Loans Fee
• Sweep Stuck tokens
• Claim fees for fee recipient
• Secondary Oracle
• Collateral Feed Source

High Sec Timelock Scope (7 days)

• All of the Low Sec Timelock
• Extensible Minting (Governance Admin)
• Primary Oracle

Non-timelocked parameters

Notably, the capability to pause redemptions and flashloans is directly controlled by the TechOps multisigs, bypassing the timelock mechanism. This design choice is based on the need for quick action in the event of detected vulnerabilities, emphasizing the protocol’s commitment to security and user protection.

Looking forward, there are plans to automate certain parameter changes in collaboration with BALCO, aiming to streamline processes such as the adjustment of redemption fee parameters based on market conditions. This transition towards automation will be pursued cautiously, ensuring that manual oversight is maintained until the viability of such automation is unequivocally proven.

A new multisig, called the Fee Recipient multisig and made up of Badger Treasury signers, will be the only one, besides the Timelocks, allowed to call the fee collection function. This is only a precautionary measure and may change since the transfer of fees uses a hardcoded path to the fee recipient so, in theory, calling this function could be safely made permissionless in the future.

Figure 1. Initial Permissions within eBTC’s Minimized Governance.

Timelock Contract

The timelock contract to be used is, the battle tested, OpenZeppelin’s TimelockController.

Management

Each Timelock will be “owned” by itself. This means that any changes to its permissions and delay time must go through a time-locked transaction, ensuring a layer of built-in security and transparency.

Vetoing

A key feature of this timelock is its built-in veto capability, allowing specific transactions to be canceled before their execution is enabled. Initially, eBTC will not designate any veto power. However, the plan is to gradually identify and incorporate a group of esteemed figures from the industry and security community to serve as guardians, leveraging this vetoing function to maintain the integrity and safety of the platform.

eBTC Governance Tooling

In an effort to enhance transparency and community engagement, a timelock transparency dashboard is under development. This platform will provide real-time insights into transactions queued in the timelocks, detailing their scope, properties, progress, and current state. Additionally, the timelocks and multisigs controlling them are subject to continuous monitoring, with live alerts being reported to the public Discord channel, ensuring that the community is kept up to date with all developments.

Supporting this intricate system is the ebtc-multisig repository, which houses all scripts and libraries essential for posting and managing transactions. This repository also serves as a platform for tracking and discussing parameter changes, fostering an environment of openness and collaborative problem-solving. The repository can be accessed here, offering a comprehensive overview of the technical foundation of parameter management within the eBTC protocol.

Adhering to the same transparency standards as those observed in Badger Multisig operations, all parameter changes and treasury operations related to eBTC will be documented in their respective issues using the following public board. Similarly, once deployed, all multisigs relevant to the eBTC Ecosystem and their signers will be disclosed in the multisig repository’s README.

Conclusion

eBTC’s governance framework is an example of its foundational commitment to decentralization and trustlessness. From the outset, eBTC has been designed with a core structure that is both immutable and highly resistant to censorship, ensuring that its essential contracts and parameters remain immutable. This level of immutability not only underlines the protocol’s dedication to trustlessness but also significantly reduces the risks associated with human error and intervention.

The decision to entrust the management of the remaining critical parameters to teams of experts from BlockAnalitica and Steakhouse, under the BALCO umbrella, further underscores the protocol’s nuanced approach to governance. By combining the immutable nature of its core components with the expertise of leading figures in finance, crypto risk management and security, eBTC ensures that any adjustments to its system are made with the highest level of consideration and competence. This blend of rigid foundational security with flexible, expert-driven governance strikes a delicate balance, enabling the protocol to adapt to the evolving DeFi landscape while maintaining its core principles of decentralization and trustlessness.

Moreover, the implementation of sophisticated technical mechanisms, such as the dual timelock contracts, the Timelock Transparency Dashboard, public alerting, the eBTC-Multisig repo and the Fee Recipient multisig, reflects eBTC’s commitment to transparent and secure operational practices. These mechanisms not only facilitate a structured and accountable approach to parameter changes but also provide the community with clear insights into the governance process, enhancing trust and participation.

Ultimately, eBTC’s governance design is a pioneering model that merges the benefits of immutable contract security with the dynamic adaptability provided by expert oversight. This innovative framework ensures that eBTC remains at the forefront of the DeFi sector, offering a synthetic BTC that is not only secure and transparent but also capable of navigating the complexities of the digital asset world with agility and authority. The emphasis on expert-driven decision-making for critical parameters, against a backdrop of foundational immutability, positions eBTC as a leading example of how decentralized finance can achieve robustness, trustlessness, and adaptability in equal measure.

[Bill.bull]

Thanks!
Maybe there is a potential issue that should be considered in advance? The distribution, buyback and cancellation mechanisms of Token $Badger ?

[saj]

Thank you for your reply.

Please note that the scope of this framework is strictly limited to the eBTC protocol. Operations like the ones you described pertain more to the Badger Treasury. You’re welcome to start a new post on the forum or join the Badger Discord to discuss these topics further with the community!

[sberj]

this seems a very well drafted Gov Framework to me, I wish we had the same for Digg and the mess we did by removing the rebase mechanism

[gosuto]

@saj

this group will be responsible for evaluating and determining changes

how can the balco fullfill its responsibility of implementing critical changes if it isnt organised as a multisig, and is only represented as one of the six signers?

in your proposed setup, their decisions can easily be ignored/counteracted by any of the other signers. why is the (technical) core team so over represented? were members of the badger and or treasury council, these councils as a whole, or any other candidates also considered for these signing positions?

@saj

A new multisig, called the Fee Recipient multisig and made up of Badger Treasury signers

why not just use the existing treasury vault multisig for this? that would vastly reduce the overhead of deploying a contract, maintaining list of signers, etc. what is the advantage of making this a separate multisig?

then, i see the value of splitting economic decisions and security decisions, although im a bit fuzzy on which functionalities now exactly fall under the responsibility of the balco and which fall under the “core development and security team”. can you maybe denote this on figure 1?

lastly, im not sure if i agree with (or understand correctly) the fact that neither $badger token holders nor the treasury or badger council have any say in these decisions. for example, it would make a lot of sense to me if the treasury multisig would also be able to adjust the protocol yield share. but most importantly, will the ebtc techops fall under the authority of $badger governance? because without such an authority in place, the handful of developers on the techops multisig would be able to do anything they like to the system without token holders being able to do anything about it.

[saj]

Hi Gosuto, thanks for reviewing and providing your feedback! Responding below.

@gosuto

how can the balco fullfill its responsibility of implementing critical changes if it isnt organised as a multisig, and is only represented as one of the six signers?

As described in the post, the reasons for the TechOps multisig to be comprised by the core developers are a few:

• Once a decision is made, the execution of this may not always be trivial, technically speaking; scripting, translating values into the units used by the contracts, posting and reviewing Timelock transactions with encoded data, test and simulate its implications from a security perspective. This process will only be as agile and secure as the people involve in it have the highest understanding of the technical intricacies of the system.
• BALCO is engaged in an advisory capacity but not full time. The core developers have the bandwith and availability to manage the process with the efficiency that the system requires.
• The same two apply for why not other groups were involved. Comes down to expertise and efficiency.

A couple of extra notes here:

• Block Analitica recently agreed to have one of their team members added as an additional backup to these multisigs. Therefore, there will be 5 core technical members and 2 BALCO signers on both multisigs with the thresholds kept the same.
• This design was conceived through our learnings operating other multisigs on the org and our observations from the Industry. There is a case to be made for separating decision making from decision execution in order to achieve a higher degree of security and operational dilligence.

@gosuto

why not just use the existing treasury vault multisig for this? that would vastly reduce the overhead of deploying a contract, maintaining list of signers, etc. what is the advantage of making this a separate multisig?

Multiple:

• There is a potential for automating a lot of the operations of the fee recipient through modules. It was advised by the security team to, therefore, use an new multisig for this in order to reduce the amount of automations per mutltisig and prevent potential vulnerabilities that may emerge from composing too many of them.
• Cleanliness and ease of accounting.
• Future proofing - There is a potential of Badger growing and developing multiple protocols. Having different multisigs will allow the treasury to introduce focus groups per protocol if ever desired.

@gosuto

then, i see the value of splitting economic decisions and security decisions, although im a bit fuzzy on which functionalities now exactly fall under the responsibility of the balco and which fall under the “core development and security team”. can you maybe denote this on figure 1?

This is addressed in the post:

• BALCO:
  “Specifically, this group will be responsible for evaluating and determining changes related to the redemption and flash loan fee parameters, the protocol yield share %, extensible minting and pausing and unpausing redemptions and flashloans for potential economic risk reasons.”
• Security Team:
  “Specifically, this group will be responsible for evaluating and determining changes related to the pausing and unpausing of redemptions and flashloans for technical security reasons, determining the duration of the Recovery Mode’s grace period, swapping the secondary and primary oracle and changing the collateral feed source for the primary oracle.”

Finally, to your last point, the governance model we’ve adopted begins with a foundation of high immutability, with very limited scope for intervention, focusing strictly on the protocol’s security, stability, and scalability. This necessitates expertise in each decision made, hence the delegation to specialized groups, ensuring actions taken are in the best interest of the ecosystem, with transparency at the forefront of these processes.

[Petrovska]

the readers will benefit from understanding how some of the governed moving pieces will be updated and under which circumstances, specifically: oracles, collateral feed source and extensible minting.

could you expand which framework the signers will follow to decide modifications on the primary and secondary oracles? since it has major implications in the system as whole, will be great to a deeper understanding

also, which are the implications of extensible minting? what are the use cases foreseen? and how it may affect the TCR?

[Bam]

We need a wise man to run the badger。
We don’t need people doing nothing.
We need a wise man to push the price of badger above $100, $200, $300 each… Even $1,000.

[saj]

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.

[Dino]

Thank you for posting! Fascinating read