InfiniteSn4ke | Forkbomb | Helianthus

For international corporations, many of these frameworks may be applicable. In the United States, NIST frameworks are the most popular, but ISO has more recognition internationally. While these frameworks aim to help organizations secure their information and establish trust with their customers and partners, the approaches of these frameworks can vary so much that little to no overlap exists for seemingly the same pursuit - security.

Why Current Frameworks are Insufficient

If you’re an international corporation, you likely have security teams spread across the globe with expertise in regional security frameworks. These teams work together to create a cohesive security strategy to report security compliance to customers, shareholders, and regulators. In addition to internal teams, the corporation engages third-party auditors and assessors to validate its security strategy and execution.

What if you’re not an international corporation with thousands of employees but a Web3 project bootstrapping NFT collections and grants to achieve your mission of decentralization? Do you need to know all of these frameworks? Is there one to rule them all?

Not surprisingly, most of these security frameworks have a similar target audience - large, publicly-traded corporations. These frameworks’ complexity mirrors the complexity of the organizations they serve. While it’s easy to burn it all down and start from scratch in Web3, Web 3 founders and developers can learn much from these frameworks. Compliance for audits may be irrelevant to a loosely-regulated decentralized application, but the battle-tested best practices often recommended by security frameworks are still relevant.

The 3 Keys to An Effective Security Framework

Before we create a Web3 Security Controls framework, let’s dive into the shortcomings of the current frameworks. In the “3” spirit, there are three key concepts to discuss: applicability, ambiguity, and measurability.

Applicability

Frameworks list NIST target the largest of organizations. NIST 800-53r5 has over 1000 controls spread across 20 control “families”. These families range from fundamentals like “access control” to ambiguous and complex families like “system and services acquisition”. Not all of these controls apply to their mission for even the most complex organizations. Yet, security experts have to analyze each control, determine its applicability, and justify whether or not it applies to the organization’s mission.

Other frameworks like HIPAA approach security specifically from the perspective of individual information protected by health regulations. While this information has a unique use case, this data is stored and accessed through the same technology infrastructure software engineers use to develop solutions. In some cases, the healthcare information might be part of the product being developed. Therefore, HIPAA controls might apply to the same systems which ordinarily, you might choose to comply with NIST 800-53r5 controls. But wait, it gets even more complicated. If your organization does business with governments in the United States, you might be bound by FedRAMP or FISMA, which requires compliance with NIST 800-53r5. And wait, if you also accept payments through credit cards, PCI compliance is also required.

Compliance requirements can quickly spiral out of control for large organizations. Even worse, these frameworks are written by different groups for different use-cases and different views on how to secure information. In short, these control sets often cause conflicted guidance for the same technology choices. In these cases of conflicted control overlap, what do you do? To be blunt: there is no correct answer to this question. Most organizations choose which controls they believe are most applicable and justify their reasoning. 3rd party auditors and assessors might disagree. Entire teams of people dedicate the bulk of their time to making these choices and writing justifications that are shockingly similar to how the legal process works.

Ambiguity

Complying with multiple frameworks is a horribly inefficient process requiring security compromises to satisfy different perspectives of different framework authors. None of these frameworks directly apply to Web 3, but that might not stop someone from trying to impose compliance upon a Web3 project. Are there controls describing wallet security and how to prevent rug pulls?

Subject matter experts didn’t write frameworks with over 1000 controls quickly. NIST 800-53r5 (the 5th revision) was in review for multiple years. That’s just IN REVIEW. Web3 radically changes daily, making it tempting to define broad security controls that require subjective interpretation. However, to be helpful as a tool to improve Web 3 security, a Web3 Security Controls Framework must be directly applicable to Web3 projects and reflect the current needs of investors, builders, and users.

Whether you’re an NFT project, an L1, an L2, or even an L0, a standard set of core security controls provides a starting point for approaching security. Despite the wide range of projects, many security threats share common vectors aimed at the individual members of a project.

Because most control sets are aware of the broad range of applicable projects, the controls are written to accommodate many solutions. Depending on the project's scope, a 3rd party auditor might interpret the security solutions as inefficient to satisfy the control. This binary, yes or no, approach to compliance leads to a highly inefficient process that creates uncertainty for the project on how to approach security and tension from the auditor in how to make their judgment as fair as possible compared to other projects.

Measurability

Controls must provide mechanisms for measuring the security posture of a project to provide practical guidance. Much like the “Grand Unified Theory” in physics, a quantitative and measurable security controls set is the “Holy Grail” of security compliance. Yet, this pursuit might be more realistically a quest for a “white whale”.

Some argue the measurements should be in project USD loss associated with a cyber attack. While this argument has merit, the data behind monetary loss for cyber attacks is unclear and highly disputed - and that’s not even addressing the methodologies of how to arrive at these values.

The ASID framework, our Web 3 Security framework, introduces “attributes” for each control to help standardize compliance measurability. The attributes represent common methods for satisfying the control. In some cases, the attributes are additive, but in other cases, the attributes represent design implementation choices. These attributes could represent both qualities for complex projects. The attributes provide users, partners, and shareholders a method for understanding how the project has chosen to implement security.

The Privacy Tightrope

Many believe blockchain technologies were explicitly created to guarantee user privacy. Over time, others have realized total anonymity results in an ecosystem where criminals can exploit that anonymity to steal and easily launder assets. There are compelling arguments for and against anonymity. In addition, privacy laws and AML (Anti-Money Laundering) laws appear at odds.

Rather than ensuring privacy, blockchain technology can be utilized to support a system of radical-non privacy. Assuming that any information written to a blockchain is immutable, accessible, and distributed enables solutions architects to create applications that take this into account.

Nuance is the key to balancing the privacy tightrope. Arguing for total transparency seems an obvious solution to the problem of money laundering, but what happens in the case of dissenting opinions or whistleblowers? Many oppressive regimes use the control of information to exploit the power and suppress democratic discourse.

There is no single “right” answer on how to approach privacy. The project must choose its philosophy toward protecting anonymity and embracing transparency. Based on a project’s compliance with the privacy controls, users, partners, and shareholders can decide if its privacy values align with their goals.

The ASID Core Controls Families

A wide range of Web 3 project and application types; the core controls families represent security concerns applicable to most projects. The ten core controls families borrow concepts from existing controls frameworks and introduce families specific to the needs of Web3. The ten core controls families are:

1. Personnel (P)

2. Development Environment (D)

3. System Design (S)

4. Frontend (F)

5. Backend (B)

6. Wallets and Treasuries (W)

7. Risk Management (R)

8. Incident Response (I)

9. Notifications (N)

10. Privacy (V)

Personnel (P)

Trust is essential when investing, partnering, or using a platform. Such personnel may include developers, project owners, node operators, dependency maintainers and other stakeholders. While Web3 strives to create a boundary layer between PII and Web3 identifiers (DIDs), it is imperative to establish relationships with key organizational personnel that give confidence that a DID matches a unique individual working towards the best interests of all stakeholders.

Development Environment (D)

The first step to securing a Web3 environment is securing the source, development, build, IDEs, and deployment pipeline. Securing the pipeline helps prevent vulnerabilities, including code tampering, dependency poisoning, and other attacks resulting from poor oversight of the early stages of the decentralized SDLC.

System Design (S)

Architecting solutions that are secure and well-planned is key to implementing secure dApps. Secure architecture doesn’t happen by accident: careful planning and consideration go into building secure, reliable solutions, and the work is never done. Risks must be continuously monitored and re-assessed as dependencies are introduced and features are added.

Frontend (F)

The front ends of decentralized applications face similar risks to their counterparts, especially if these Web 3.0 applications utilize Web 2.0 components. Secure development practices for React, Typescript, Swift, Kotlin, and any other utilized front-end languages should be considered, and developers should take care to avoid leaving any hard-coded secrets from testing in the code.

Backend (B)

While the backend architectures of Web3 projects can look very different to past infrastructures, the security principles for protecting these architectures remain largely unchanged. The key word is “resilience” where architectures should provide the ability to maintain maximum service uptime and be able to recover information. Decentralization does not guarantee information or service availability with many blockchains having suffered from total stoppages. Organizations should also consider scalability.

Wallets and Treasuries (W)

Digital asset wallets and treasuries represent a new technical implementation unique to Web3 projects. Not surprisingly, many cyber attacks have already successfully targeted wallets and treasuries resulting in billions of dollars of stolen assets. Securing wallets and treasuries leverages many “old” security techniques involving hardware solutions, airgapping, and physical redundancies. Securing wallets and treasuries is critical as compromises of these digital leads to non-recoverable losses.

Risk Management (R)

The most effective tool for improving a project’s security posture is implementing an effective risk management program. The ability to assess risks and determine the impact of those risk scenarios to the project provides evidence and justification for security tradeoffs and investments. During growth phases, projects must make wise resource allocation decisions. Risk management improves the efficacy of those decisions, but it also provides users, partners, and shareholders insight into the logic behind those decisions.

Incident Response (I)

A project must accept that incidents will occur. In fact, the most successful a project becomes, the more likely an attacker will want to target it. Being prepared for an incident can mean the difference between preventing a non-recoverable event or losing your entire treasury with no recourse. Often a swift and effective response to an attack bolsters user, partner, and shareholder confidence that the project will be able to continue to respond to future attacks effectively.

Notifications (N)

Users, partners, and shareholders depend on communications from the project to build a trusting relationship. Frequent and transparent transmissions provide confidence that the project will quickly notify all affected with concise instructions on what to do next in the case of a cyber-attack. Silence during and after attacks can lead to fear, uncertainty, and doubt that a project will survive or that the project was even legitimate.

Privacy (V)

The balance between transparency and anonymity is a philosophical choice for the project. Based on a project’s compliance with privacy controls, users, partners, and shareholders will have to decide if the project’s privacy philosophy matches their values. A project should be transparent regarding its personnel, goals, and communications but can choose to protect user data. On the other hand, the project might value total transparency to align with their values.

ASID Project Specific Families

1. Smart Contracts (SC)

2. NFTs (NFT)

3. Payments (PAY)

4. DAO Governance (DAO)

Smart Contracts (SC)

Most blockchain ecosystems have approached smart contracts with different tech stacks. Different languages, deployment processes, and execution environments make specific smart contract controls tricky. However, smart-contract developers can apply the fundamental security guidance across the various technical implementations inherent in each ecosystem’s smart contracts.

NFTs (NFT)

While some NFT security issues are covered by the smart contracts that deploy them, NFTs have unique ownership and intellectual property rights issues. NFT projects should disclose how rights are assigned to NFTs and how those rights transfer with new NFT custodians. In addition, what mechanics does the project provide in the case of theft or forging of NFTs.

Payments (PAY)

Some blockchain projects focus solely on being a payment mechanism. These projects transact tokens between users, convert between tokens, and possibly even convert the token to fiat currency. Depending on the jurisdiction, converting to fiat currency can require compliance with banking regulations that require collecting PII from users to satisfy KYC requirements. These projects must balance protecting this PII and complying with various jurisdictions' privacy laws.

DAO Governance (DAO)

Corporate rules and regulations exist to prevent manipulation of an organization’s ownership or asset distribution by exploiting the organization’s governance model. These governance models have many layers of oversight and checks and balances to prevent manipulation by large corporations. On the other hand, DAO governance is administered autonomously with smart contracts. If this governance model has flaws, a malicious actor may be able to manipulate a DAO by using its governance model against itself.

Framework Usage and Growth

The framework's design, namely atomic representations of controls and attributes, is deliberate. Creating a concise data model representing control compliance enables projects and auditors to embrace tools that can capture compliance visually, completely, and continuously. Hypothetically, projects could even mint utility NFTs that transparently show their self-assessment of their security posture with auditors. Such a representation of the security assessment would enable incredible transparency in showing the deltas between the project’s review and the auditor’s review.

As Web 3 changes, this framework will also change. A DAO is an ideal structure for managing a controls framework. Standards bodies and industry consortiums are notoriously slow to react to emerging technologies. A DAO can democratize and expedite the decision-making processes so that the framework can respond to Web 3 needs and maintain a fair framework that doesn’t favor any particular project or group of projects.

The Future of ASID

ASID is not just an aspirational framework. The controls have already been written. Today we introduce you to ASID, and coming soon, you’re going to get to meet ASID much more. The full framework, controls, and data structures are right around the corner. Follow us, engage with us, and join us bringing ASID to the world and securing Web3 for everyone!

InfiniteSn4ke | Forkbomb | Helianthus

Except, what does that actually mean? Or more importantly, what is it supposed to mean? What DAOs are today and what DAOs aspire to be couldn’t be more different. At the moment, the majority of DAOs operate in Discord servers with the only differentiator between any other Discord community being that members vote on proposals generated by the organization through a tool like Snapshot where you must hold the organization’s governance token to be able to vote. That’s about as sophisticated as most DAOs are today.

By definition, a DAO should implement a Mode 3 governance model. Great, sounds easy enough, let’s do it! Except, for one problem: Mode 3 governance is very complex. Mode 3 governance is not new either - you may have even been a member of one before in the form of a co-op, or cooperative. According to the ICA (International Cooperative Alliance), co-ops are:

“Cooperatives are people-centered enterprises owned, controlled and run by and for their members to realize their common economic, social, and cultural needs and aspirations.

Cooperatives bring people together in a democratic and equal way. Whether the members are the customers, employees, users or residents, cooperatives are democratically managed by the 'one member, one vote' rule. Members share equal voting rights regardless of the amount of capital they put into the enterprise.”

The first statement sounds very much like how DAOs are often described. The second part? Not so much. “Equal voting rights regardless of capital…”? That’s certainly NOT how DAOs are structured today. Governance tokens derive their value from their voting utility. If you care about the mission of the DAO, you would want to amass more governance token to be able to cast more voting power. Is this right? Wrong? Neither? Let’s back up to the modes of governance before we tackle that thorny question.

Mode 1 Governance

If there’s an “old way” of governance, it’s Mode 1. Mode 1 assigns decision-making authority to individuals. Have you ever worked in an organization where all your work had to be reviewed and approved by one individual? Boom! Mode 1. The larger the organization, the bigger the hierarchy of decision-making individuals becomes. The individual that can make the “final” decision has the authority to accept responsibility for that decision-making process. The quality and speed of decisions, not surprisingly, depends totally on the individual making those decisions. Have you ever worked for a large corporation that had a seemingly infinite number of employee policies? Perhaps the vacation policies were especially complicated. Your manager very strictly enforced those policies. Boo. But your friend in a different department was always on vacation even when they didn’t have PTO! How? Mode 1 governance. The individual managers had the appropriate authority to enforce and interpret the company policies. Different individuals, different interpretations, and different enforcement.

Mode 2 Governance

If Mode 1 is the “old way”, Mode 2 is the “new way”. Where authority in Mode 1 structures is assigned to individuals, in Mode 2 that authority is signed to roles. Instead of a single individual having the decision-making authority, the authority is assigned to a role which can be assigned to a group of individuals. A great example are military ranks. Have you ever seen two military officers of different ranks walk by each other? What happens? The lower ranked officer salutes the higher ranked officer. But they’re not saluting the individual - they’re saluting the rank. Authority increases with increasing ranks. For instance, the commander of a military base might be a colonel. While a particular colonel is assigned to that role, another colonel could also be assigned to be that base commander. The rank of colonel unlocks the ability to serve that role.

While military ranks are hierarchical, agile software development (please stand down with your kanban vs sprints arguments immediately, we are not going there) also implements elements of Mode 2 governance. When software development tasks are generated they are distributed (or taken) by any dev on the team. If you’re a dev on the team, you have the authority to work on any of the tasks. A dev has the authority to implement a task and submit their code. Usually (but not always) a different group of devs or managers would have the authority to deploy the new code to the project. Since the authority is assigned to a group of individuals, when an individual becomes free they can process code deployment in a more efficient manner as opposed to having to wait for a single individual to become available.

Mode 3 Governance

If Mode 1 is the “old way” and Mode 2 is the “new way” then Mode 3 is simply - “the way”. I have spoken. Before we get to what Mode 3 really is, let’s talk about two structures that come very close: matrixed organizations and co-ops.

Are you still there? Did I lose you? For anyone that’s worked at a company with matrix structures, you probably have some hot takes on this topic. Don’t worry, I’m probably about to agree with you on most of what you’re about to say. Large international corporations recognize that decision-making based solely on individuals leads to very slow decisions. In order to improve decision efficiency, individuals often report to multiple teams, departments, or individuals. You don’t have a single manager, but report to different individuals depending on the workflow or project. Remember Peter from Office Space? He had 8 managers. 8 people wanting to know where his TPS reports were. In these matrix organizations, you wear many hats - everyone wears many hats. There are still hierarchical layers of authority, but the number of layers can vary from project, department, team, etc.

Co-ops, on the other hand, don’t have hierarchies. The members have equal say in decisions. Members fulfill different tasks depending on their expertise and experience, but these assignments are decided collectively by all the members. A co-op is a flat structure, with all members having equal input into the decision-making process. While this description of co-ops harkens utopian dreams of equality, reality is often far different. Members contribute depending on their skills and over time, some members will contribute more than others. The members that contribute more might become frustrated that their vote is equal to members that contribute far less - or even not at all. As the co-op grows larger, requiring input from all members can lead to decision-making becoming painfully slow. Some members might suggest that members that contribute the most have authority to make decisions. But at that point, is it a co-op anymore?

Neither matrix organizations nor co-ops represent Mode 3 governance. Mode 3 governance exists at the collision of those two models. Mode 3 is BOTH hierarchical AND flat. Mode 3 uses democratized roles and individual authority. But how?

What a DAO SHOULD Be

Matrix organizations and co-ops take almost diametrically opposed approaches to governance structure. Matrix structures create complex org charts with criss-crossing arrows with some people being assigned more roles than they can even remember. Co-ops have a binary org chart - are you a member? Yes or no? The primary weakness of both matrix organizations and co-ops is the amount of human management required to operate the governance model. Matrix organizations quickly become so complex that people can be confused on which tasks to prioritize when being pulled in so many different directions. When you have 8 bosses, whose requests do you fulfill first? A co-op has the opposite problem. Since everyone shares the burden of governance, every member must dedicate time to making tasking decisions on who is the best suited to perform various duties. But what if management isn’t a strong skill - or something that even interests you? As a member of a co-op, everyone must govern for the co-op to function. A matrix organization attempts to compartmentalize workflows so that people with common skills and experience work together while a co-op spreads all workflows across every member. A matrix organization introduces unmanageable organizational complexity while a co-op’s organizational simplicity introduces inefficiency.

A DAO solves both of those problems - well, it SHOULD solve those problems. With a DAO, you get both of these structures combined: members are assigned roles, responsibilities, and authorities like a matrix organization -  but there is no hierarchy and no criss-crossing arrows with a flat structure like a co-op. Everyone has governance input that matches their roles, responsibilities, and authority. But doesn’t this structure introduce the most complexity of all? Yes, yes it does. This structure is totally unmanageable through human governance - but not for smart contract governance.

Without going into deep-dive on smart contracts, smart contracts are software programs that are deployed to a blockchain, stored on that blockchain, and execute on that blockchain. Once these contracts are deployed, they operate autonomously based on the design of the smart contracts and user interactions. Member roles, responsibilities, and authority can be programmed into the smart contracts. Voting rights based on those attributes are coded into those contracts. Decision-making workflows are coded into the contracts. The governance model is a smart contract. Once the governance model is coded into a smart contract and deployed, the workload to manage these governance interactions greatly decreases. There is no question of which boss do I answer to today? Who should vote on a decision? Is a vote even necessary? The answers to these questions are built into the smart contracts.

Even with smart contracts, there are network effects that must be overcome to maintain operational efficiency and scale the DAO. The visual representation of Mode 3 governance is a mesh network of members where the smart contracts can connect members to create workflows based on matching roles, responsibility, and authority. The solution? Clustering. The overall structure is still flat, but members with common workflows can be grouped in clusters where cluster inputs and outputs flow to other clusters. Yes, clustering introduces an additional layer of complexity that once again can be managed autonomously through smart contracts.

There’s only one more problem with what a DAO should be - the name. Decentralized AUTONOMOUS Organizations. Yes, the smart contracts, once deployed, execute autonomously. This attribute is the key enabler to Mode 3 governance. But what are DAOs at their most fundamental level? Organizations of PEOPLE. While the governance model can be coded in smart contracts with decision-making processes managed autonomously through smart contracts, the actual decisions are still made by people. A true autonomous organization would have no people - but would be nothing more than software bots and smart contracts. Governance models must be designed to account for the most error-prone component of the DAO - the PEOPLE. Governance models must be designed with human oversight - checks and balances. Not only are humans imperfect in their decision-making, but humans also write imperfect smart contracts. Will a smart contract ever be perfect? A DAO CAN implement true Mode 3 governance and create a more efficient and democratized organization - BUT a DAO is still an organization of PEOPLE, and must have robust protections against the imperfections of its human members.

InfiniteSn4ke | Mode3DAO

Many people, especially those in Web3, have grown disenfranchised with the concepts of corporate structures, and perhaps rightly so. In recent decades, founders, early investors, and Wall Street have exploited SEC regulations to hoard corporate governance power in a very small number of hands. Companies issue stock in multiple classes with the class available to the public having zero voting rights. To pump the IPO price, companies sell large blocks of shares to institutional investors (Wall Street firms, funds, etc.) that block the public from ever being able to amass a substantial share in the company. Yes, the company may be “publicly traded” but the corporate governance has been manipulated to favor the founders, early investors, and institutions that control the most money.

But it doesn’t have to be that way. If a company floated all of their shares on a public market, and all of those shares held equal voting rights, you’d arrive at a highly decentralized governance structure. Yes, I know, this assumes we don’t live in a world with billionaires who can buy whole companies on whims, but we can dream can’t we? The SEC would be effective at limiting manipulation, as large shareholders have to disclose their identities. Shareholders could choose to proxy their votes or exercise their voting rights themselves. Yes, this model can be slow, requiring large groups to participate in governance to make critical decisions, but it prevents organizations from making decisions without a system of checks and balances.

For all you go-go Reagan-auts that staged a hostile takeover of the one company that could cure your terminal boneitis and ended up in the year 3000 (and if you get that reference, we’re already friends), I can see you with your arms folded, scoffing at my quaint governance models and decentralized share structures, while you admire your Gordon Gekko posters and expertly embossed business cards. I can hear you already, “put all your shares on the market and I’ll take enough to take over the company!” While barging into a corporate boardroom with a briefcase and a small army of lawyers makes for a sexy representation of a hostile takeovers, real “hostile” takeovers are less Gordon Gekko and much more Carl Icahn.

Hostile takeovers, just like Carl Icahn, aren’t nearly as sexy as they sound. Film depictions make takeovers appear to be something that happens in secret, and the “corporate raider” barges into a boardroom, slams some paperwork on table and declares, “I own this company now and you’re all fired!” Remember all those governance structures and SEC rules I alluded to earlier? Yeah, they actually work. An actual “hostile takeover” occurs when a company or individual acquires a substantial stake in a company and then persuades other shareholders and board members to back their proposal to fire the current management in favor of their management plan. And most importantly, this process is very public. And it very much doesn’t happen with the slamming of paperwork on a table to an audience of shocked management. There will be many votes. Both sides will push the edge cases of the governance model to its limits to give themselves a governance advantage. In the case of Twitter, they launched a common tactic - the poison pill - to try and ward off Elon’s takeover attempt. Nevertheless, Elon was able to make an offer and sway enough voting power within Twitter to accept his bid. It was a very public process that began in January of 2022 resulting in a successful takeover at the end of April 2022. What makes a takeover hostile? Not everyone agrees, and not everyone has to agree for the vote to pass - just enough as declared in their governance structure.

The takeover of Beanstalk, on the other hand, was swift. Months? Weeks? Days? Try one block. Confirmed within 30 seconds. The damage? Approximately $76M worth of digital assets drained from the Beanstalk treasury. How is this even possible?

Beanstalk operates a decentralized and non-colleratilized stablecoin. If you’re already lost, no shame there, we could talk for days on the economics of stablecoins and only scratch the surface. The TLDR is that stablecoins attempt to peg to the value of another asset - often the USD. In order to control supply and demand to keep pegged to the USD, Beanstalk created a novel mechanism by which you can buy their token, Beans, and stake those Beans in order to yield a return. While the value of a Bean remains stable at 1 Bean = 1 USD, the staking process benefits the holders of Beans while being the mechanism that keeps the value of Beans stable. Yes, the mechanics behind this process are far from simple, but the performance of Bean provides substantial evidence the mechanics are sound.

So far so good? So what went wrong? Like so many Web3 projects, Beanstalk is a DAO (Decentralized Autonomous Organization). Remember my idealized description of a company that issues a single share class with equal voting rights? In the case of Beanstalk, if you held Beans, you could deposit those Beans into the Silo (yes, Beanstalk uses farming metaphors to gamify the complicated economics behind their stablecoin). Depositing your Beans into the Silo gives you Stalk, the governance token of the Beanstalk DAO. This Stalk token gives you voting rights in the DAO. With voting rights, you can vote on proposals and even submit proposals as long as you possess more than 0.1% stake in Beanstalk.

For the most part, Beanstalk’s governance was relatively simple as defined in Section 6.5 of their whitepaper. Important proposals were submitted as BIPs, Beanstalk Improvement Proposals. Nothing looks out of the ordinary except for one use case - the supermajority. By design, 24 hours after the submission of a BIP, a supermajority - more than two thirds vote - triggers the BIP to pass and can be committed to the Ethereum mainnet with no oversight. While the governance structure of Beanstalk was relatively simple, these BIPs could be very complex. The BIPs follow the EIP-2535 standard which uses a diamond analogy to describe a methodology for modifying smart contracts over time after initial deployment. That summary is a gross oversimplification as EIP-2535 is, by no means, simple.

What happened next? This article goes into great technical detail, and I highly recommend a read. The attack is very complex - and yet elegant - from an understanding of both EIP-2535 and Beanstalk’s governance model. Since the above article covered the technical details so well, I’ll stick to a brief summary of events:

• The “exploiter” submits BIP-18 and BIP-19

• 24 hours later, the “exploiter” takes out a $1B flash loan through Aave to amass Beans

• Liquidity Pool Beans generated more voting power enabling the “exploiter” to amass a supermajority of voting power by targeting Uniswap and Curve LP tokens

• The “exploiter” now having a supermajority of votes can execute BIP-18 and BIP-19

• BIP-18 leverages the CREATE2 function within the EIP-2535 framework to execute a smart contract that was not a part of either BIP-18 nor BIP-19

• The “exploiter” smart contract transfers 24,830 WETH to a wallet under their control worth ~$76M USD and returns assets to Aave to close out the flash loan

I’m sure you’re thinking, “how could they not see this coming? Didn’t someone look into their security?” Funny you should mention that - they did. Omniscia performed a security audit for Beanstalk. Did Omniscia flag this potential governance weakness? NO. Is that Omniscia’s fault? Well, maybe not. It’s clear from Beanstalk’s whitepaper that the priority for Beanstalk governance was speed - being able to react quickly and deploy proposals with as little delay as possible. The “emergency commit” function enabled by a supermajority vote, in itself, was not enough to enable this “governance hack”. The exploiter still had to be able to accrue more than 67% of votes. Remember our earlier discussion about hostile takeovers? No one, not even Elon can simply buy all the shares of a company. Why? For the simple reason that someone has to want to sell their shares. How many people are actively submitting sell orders at any one time? In the case of Beanstalk, their governance analytics indicates an increase in Bean acquisition through liquidity pools in mid March with a much larger increase in this acquisition in early April. What does this mean? Was this a warning sign? Was the “exploiter” already strengthening their Beanstalk governance position in preparation for submitting BIP-18 and BIP-19? In the case of a corporate hostile takeovers, accumulating large stakes would require disclosure to the SEC - just as Elon had to do when acquiring his initial stake in Twitter. But in Web3, who’s acquiring these stakes? An individual? A group? All the above?

While it’s easy to criticize Beanstalk, they did so many of the right things. They published a very thoughtful and detailed white paper. They published their security audit on their site (which has now been removed but is still available through Omniscia). And someone used it all against them. Beanstalk is currently in the midst of rebuilding their treasury as they deeply believe in their stablecoin model. As for governance, there is much to be learned. By design, Beanstalk’s governance model enabled a supermajority to act unilaterally with no oversight - except I’m sure they never expected a supermajority to represent a single exploiter. Yet, these are the perils of DAOs and the current state of decentralization. A wallet is not a single address, but a set of addresses. You can also install a different wallet in different browsers. Or what happens when you start running VMs on your machine to install even more wallets. Just how many wallet addresses can you create? How many do you need? There’s nothing stopping someone from cornering the voting rights of a DAO by joining with a large enough set of wallet addresses - and there would be no way to trace all those addresses to a single individual. Corporate governance was - emphasis on was - created to prevent these exploits. No one can anonymously, not even Elon, buy enough voting rights of a public company to simply vote to drain the treasury into their pocket. I believe strongly in DAOs and their ability to provide merit-based organizations where everyone has a voice in the direction of the organization. But I also believe in rules and regulations. Let’s learn from both worlds - what does corporate governance get right and how can we apply that to make DAOs even better?

In a word? Oversight. The Beanstalk governance model allowed a single entity to submit proposals, accrue a supermajority of votes, and then deploy the proposals unilaterally. In this system, if the proposer can sway a vote in their favor, they have unilateral authority to deploy the proposal. What if they proposer had simply approached DAO members with large votings stakes promising a share of the profits if they voted yes? Beanstalk is still a relatively small organization, where a majority of votes can be reached rather quickly. If the required amount of votes is secured, the proposer has the authority to commit the proposal. The only mechanism to stop the commit would be another BIP to “pause” Beanstalk. But then, someone could submit another BIP to “unpause” Beanstalk. What would happen in this race? Who would win?

On September 26, 1983, Soviet early-warning detection systems triggered alerts that the United States had launched nuclear ICMBs directed at the Soviet Union. By protocol, the response to launch detection was an immediate and compulsory counterattack. But that didn’t happen. Did systems fail? No. The reason was Stanislav Petrov. Petrov, based on his interpretation of the detection and his training on nuclear warfare believed the supposed launch that had been detected made no sense. In addition, the detection system had been prone to errors in the past. Thus he made a decision - he NEGLECTED his duty to notify superiors to automatically trigger the counterattack. The result? The detection system WAS IN ERROR. There was NO launch. His decision to block the protocol saved the world from nuclear war. What would have happened had this scenario been controlled with a smart contract with no one to question its execution? Should a DAO execute decisions truly autonomously? Was is the cost of “speed to commit” decisions? Perhaps this is more speed than we can afford.