An Upgrade to the BarnBridge DAO- Part II
BarnBridge DAO (BB DAO), in its first iteration, was built as a series of smart contracts on the Ethereum blockchain that allowed users to collectively steward the BarnBridge protocol forward by proposing, voting, and executing changes and upgrades to the existing smart contracts including the treasury.
Soon an all-new and improved version of the BarnBridge DAO is set to launch on Arbitrum. This will be our second swing at DAO First-styled governance, and is built on the ‘Default framework.’ This state-of-the-art framework will enable faster protocol development with increased transparency and flexibility. The move is also anticipated to boost governance participation, invite superior protocol improvement proposals, and lead to cutting-edge third-party integrations.
Before we explain the ‘Default framework’ to you, let’s find out why the DAO actually needs it.
The problem with the current DAO
When BarnBridge was first launched, Compound-styled governance was the ultimate DAO architecture in DeFi. As we have always strived to be the best, we built our own iteration of the Compound DAO with some modifications. For some time, it worked as intended. The governance was smooth and saw sincere participation from the BarnBridge community. Most DAO members understood what was going on with the protocol and enthusiastically shared their opinions and suggestions other than voting on proposals.
As every good thing comes to an end, with time, the BB DAO, too, started witnessing a downtrend in its user participation. For instance, the average vote (total votes across all proposals/total number of proposals to date) on a BarnBridge proposal equals 55.9, but the average vote on the last ten proposals is only 43.9, indicating a decline of 28.6% in the users’ votes. Furthermore, the average vote on the first ten proposals is 68.5, which is significantly higher than 43.9, the average vote on the last ten proposals. Lastly, it’s worth noting that the DAO witnessed its two least voting figures of all time, 23 and 27, among the last ten proposals. It doesn’t take much effort to conclude that the BB DAO is seeing a sharp downturn in user engagement. But what is causing this downturn?
BarnBridge, when initially launched, only had Smart Yield built into it. Over time, as more and more applications were built on top of BarnBridge, the protocol grew in complexity. With every new integration or smart contract deployment, BarnBridge became further convoluted. Soon, there came a time when the logic surrounding the protocol started to get blurry and the developments hard to follow for an average user. This not only turned away some serious DAO participants but also left the protocol cumbersome and crawling.
Another issue with the existing protocol lies with its upgradability. In the current setup, if we need to upgrade a smart contract’s logic, we will need to take upgradable proxies into use. Proxies are contracts that forward the logic to and from another contract. This is usually done because the existing proxy contract remains immutable while there is a change in the underlying logic. The problem here is that the proxy upgrade pattern is not fully transparent and is done mostly for the convenience of third parties who want to integrate with the protocol and already have the contract address but do not want to change it.
Furthermore, the multiple forwardings result in a web of instructions causing obscurity within the protocol and making it harder for non-tech users to understand even very basic things like what is going on with the protocol or what code is executing, and so on.
Example of a complex architecture of a protocol (MakerDAO)
The growing complexity and lack of transparency make it extremely difficult to spot possible bugs and vulnerabilities in the contract, even for an advanced programmer. In a recent exploit arising out of upgradable proxies, the Audius Project’s governance, staking, and delegation contracts on the Ethereum mainnet were compromised due to a bug in the contract initialization code that allowed repeated invocations of the initialize functions. The bug allowed an attacker to maliciously transfer 18MM $AUDIO tokens held by the Audius governance contract (referred to as the “community treasury”) to a wallet of their control and modify the dynamics of the voting system to change their staked $AUDIO amounts in the network illicitly. What’s shocking is the fact that this set of contracts was audited by the OpenZeppelin team on August 25, 2020, who are one of the best in business, prior to deployment, and the bug went unnoticed. That is how hard it is to spot vulnerabilities in a contract if the protocol is overly convoluted.
Enter Default
The core philosophy of Default is to shift the focus of writing contracts away from organizing contracts around processes and towards organizing contracts around data models. In particular, what data models exist as protocol dependencies, and how can they be modified?
The goal is to turn a protocol from looking something like this:
into something like this:
The Default framework will make BarnBridge’s smart contracts explicit and straightforward by categorizing them as modules which are essentially the “back-end” and policies, the “front-end” of the protocol.
In this framework, modules are internal-facing contracts that store a shared state across the protocol. We can think of them as microservices: each Module is responsible for managing a particular data model within the larger system. Modules can only be accessed through whitelisted Policy contracts and have no dependencies of their own. Modules can only modify their own internal state.
Policies are external-facing contracts that receive inbound calls to the protocol and route all the necessary updates to data models via Modules. Policies effectively act as intermediaries between external interactions and internal state changes, creating a buffer where all protocol business logic is composed.
While modules describe what data models exist within the protocol and how they can be modified, policy contracts contain the context for why those changes happen. This separation of what and why in the protocol allows for greater flexibility in design while retaining some properties of immutability, which dramatically simplifies protocol development.
Default views the entire contract set as a cohesive unit: rather than upgrading an individual contract’s code, it’s better to just upgrade the protocol’s contract set. In Default, there is a special contract registry that manages the contract set called the Kernel. This means that all changes to the protocol are made within a single contract, unifying the model of upgradability.
In this paradigm, each contract in the protocol remains immutable, but the set of contracts that make up a protocol can change. This makes Default incredibly easy to work with; developers only need to understand a single contract — the Kernel — before they can begin building a protocol using the framework.
BB DAO x Default = 🚀
The new governance system wraps around the Default framework and allows the DAO users to choose what data properties and pieces of logic are a part of the protocol. This makes governance transparent, explicit, and modifiable. For example, if we want to upgrade the tokens contract, say increase or decrease the total supply of tokens, we can do so while the logic around how the token behaves and is utilized stays as it is. Another example would be the DAO deciding to change the staking duration, but the tokens remain the same.
One of the biggest advantages of using this governance model is the sheer simplicity it adds to the protocol’s organization, making it easy even for a new user to see the nuts and bolts of the protocol. This way, the protocol can always stay relevant to future market situations by embracing new developments.
As voting and execution will happen on-chain, the DAO will be in complete control at all times and doesn’t need to trust the team and their multi-sigs to vote or execute the code. This will also save time as the proposed contract is already fed to the system and can be readily executed once the proposal is successful, making way for faster protocol development. Overall, this governance is a long-term move that is critical for the survival of our beloved protocol.
Shout Outs:
A special shout out to the Olympus team for spearheading the Default framework with us and working through audits.
A shoutout to Spearbit, Halborn and Code4rena as auditors.
A special shout out to Zach, Fully, Stu, & Indigo for working through this so diligently over the past couple of month.
Sources:
