Navigating decision-making on the Internet poses a significant challenge in establishing a robust system where members cannot manipulate outcomes and only eligible parties can participate. On another side, it was important to prevent 'double-spending' problem, so users cannot reply the same action again and again in order to get a benefit. The solution to the problem was proposed by the adoption of the Bitcoin [1]. However, it did not allow creating a complex governance structures with custom rules that cannot be omitted.
The adaptation of Smart Contracts [2,3] on the Ethereum network has addressed this issue, operating under the principle of 'code is law' [4]. While this approach serves smaller communities and projects focusing on straightforward financial management effectively, it struggles with continuously evolving systems that need to adapt to real-world trends and changes.
Ethereum, inherently a perpetually evolving protocol, enables the development of a diverse ecosystem of commercial products, allowing community interaction and participation in decisionmaking processes. A prevalent instance is the creation of platforms, known as Decentralized Autonomous Organizations (DAOs), where community members or investors can influence the project's trajectory in the WEB3 sphere. Given the irreversible nature of user actions and Smart Contracts in Ethereum, significant modifications to the contract logic are challenging, and manual upgrades through a Proxy Upgrade pattern [5] can be risky. Contracts also face a size limitation, hindering scalability when the available space is exhausted. Additionally, the inability to adapt to new products and protocols in the Ethereum ecosystem can render older DAOs obsolete.
To address these limitations, a modular architecture incorporating a role-based access system is essential, allowing seamless integration with new protocols and functionalities without redeploying the entire system. This approach not only eliminates the need for system redeployment and reconfiguration but also empowers the community to modify the system's functionality through voting, ensuring security and sustainability as long as the majority actively cooperate.
This article introduces a Role-Based Access System (RBAS) serving as a pivotal connector between system components, establishing a set of rules that delineate access to system resources. These rules are designed to be transparent and comprehensible to community members, offering enhanced flexibility to the system.
Where each community member or the system itself can be considered an Entity that performs specific Actions on resources.
In the prevalent Ethereum ecosystem, most contracts depend on account addresses to determine resource access, a method that restricts the system to specific addresses. This limitation becomes problematic in systems with numerous contracts, confining them to precise implementations that cannot be easily and securely modified.
RBAS, in contrast, abstracts resource access to parties with specific permissions, granted through community voting, simplifying the management of system component relationships. It centralizes all access rules, unlike traditional approaches where access to protected functions requires extensive contract code analysis. Despite the additional gas usage, RBAS compensates by facilitating a more manageable and adaptable system.
By leveraging RBAS, which grants permissions through community voting, management of system components is simplified and adaptability is enhanced. For example, in Corporate Governance [6], implementing RBAS in DAOs illustrates how it can supplement traditional business structures, enabling dynamic, decentralized regulatory solutions and showcasing a compliant approach to managing corporate entities.
The core capability of the RBAS is its ability to assimilate external modules while maintaining tight control over them and ensuring that the integrated components conform to the control protocols established in the system. This integration is key to extending and diversifying the functionality of the system, allowing the inclusion of various components such as DAO bridges, Uniswap, Treasuries and other elements that require the influence of DAO management.
In practical terms, this means that any component, once integrated, automatically adapts to the rules and protocols of system management, inheriting established norms and operational frameworks. This integration is critical for consistency and uniformity across the system, ensuring that all components, regardless of their origin and nature, operate within a common governance structure, reducing the risks associated with inconsistencies and non-compliance.
In essence, integrating external modules using RBAS not only enriches the ecosystem with diverse functionality, but also strengthens the governance structure by ensuring uniformity and compliance across all components. This is an example of a balanced synergy between extension and governance, allowing the system to evolve and adapt while maintaining its underlying principles and integrity.
Our proposed solution initiates with the delineation of roles, resources, entities, actions, and permissions within the system, as illustrated in Figure 1. Role (Role): An amalgamation of one resource and one or more permissions, structuring relationships within the system in a simple yet effective manner.
To enhance efficiency and optimization, we used the concept of a group abstraction. Group (Grp): A compilation of members sharing identical roles.
Instead of granting roles directly to members (M), they are role assigned to groups.
Consequently, a member's inclusion in a group bestows upon them all the permissions allocated to that group. Essentially, a group operates as an array to which a specific role can be granted. Consequently, each member within this array inherits the permissions associated with the group, allowing for a streamlined allocation of roles and permissions, as illustrated in Figure 2. This structured approach sets the stage for defining the core properties and formal guarantees of the RBAS system.
The systematization above not only streamlines internal relationships but also ensures a structured approach to resource and permission allocation. This allows us to extract the following properties:
Role Assignment: Each entity e is assigned one or more roles, which collectively determine the actions they are authorized to perform on resources: Permission Enforcement (Perform): For an entity e to perform an action a on a resource r, the entity must possess a role that includes the corresponding permission:
Access Control Function (Access): An access control function Access verifies whether an entity e has the necessary permissions to perform an action on a resource r:
By combining the core properties and system primitives, we achieve the following formal guarantees:
The RBAS ensures that only authorized actions are performed, preventing unauthorized access and modifications, and ensuring that role assignments and permissions are uniformly enforced across all actions:
The RBAS, as formalized above, provides a robust framework for managing access and permissions within the decentralized network. It ensures that every action is authorized, maintaining the integrity and security of the system while allowing for scalability and adaptability. The subsequent sections will elucidate its application within the context of a DAO.
To construct a system capable of scaling indefinitely, a modular System Contract architecture is imperative, aligning with the standards proposed by Nick Mudge in ERC-2535 [7]. Given the restrictive 24KB [4] contract size limitation, this architecture organizes a collection of Smart Contracts under the ERC-2535 standard to accommodate extensive systems.
Each system component is a distinct module or contract, enabling the DAO to integrate with a myriad of protocols within the Ethereum ecosystem and incorporate new functionalities with static addresses. This modularity negates the need for users to navigate through multiple System Contracts to locate specific functionalities provided by individual Smart Contracts within the system.
The DAO is essentially defined as:
where the Storage represents the state of the DAO and modi, is a distinct component or contract within the system.
The adaptability inherent in Modular Smart Contracts Architecture allows DAOs to seamlessly integrate or modify modules, ensuring continuous compliance with evolving disclosure regulations and aligning with the transparency and consumer protection needs of the decentralized finance ecosystem [8].
As visualized in Figure 3, the actual data is housed in the main entity, which, in this instance, is a DAO. This main entity uses specific delegate calls to interact with and utilize the functionalities provided by separate entities, referred to as facets.
Traditional governance modules predominantly rely on the voting power of community members, represented through various means such as the quantity of ERC-20 [9], NFT [10], ERC-1155 [11] tokens or native currency locked within the system. For a proposal to gain acceptance, it must achieve a requisite quorum and a majority of votes.
However, as governance expands with increasing user participation, the likelihood of suboptimal decisions escalates. To mitigate this, we introduce an Expert Group, comprised of members with the authority to veto specific community-selected proposals and to initiate expert-specific proposals, necessitating an in-depth understanding of the system.
Formally, Expert Group (ExpGrp) is a set of entities with special permissions:
This additional protective layer aims to reduce the risk of system stagnation by ensuring that decisions are meticulously scrutinized and are reflective of informed and expert opinions, thereby enhancing the robustness and reliability of the governance structure.
At every level of the governance structure, from the creation to the execution of proposals, the community diligently works to uphold the security and stability of the system, as illustrated in Figure 4. This visualization depicts the community's commitment to preventing any disruptions and ensuring the continuous, smooth operation of the system. Employing a multi-layer strategy is a prudent governance practice adopted by various protocols within the Ethereum ecosystem to bolster system security [12,13].
The voting process (VP), in its most comprehensive configuration, is bifurcated into two pivotal phases: voting and vetoing. The uniqueness of this process is attributed to the concept of the 'voting situation,' a set of parameters defining the target module of the proposal and specifying the entities endowed with the authority to veto the proposal.
The veto process is integral to the governance of the DAO, acting as a protective mechanism to halt proposals that may diverge from the DAO's foundational principles and constitution. This process is reserved for Experts, appointed during the DAO governance process, and serves as a safeguard to ensure the alignment of all proposals with the DAO's values and objectives.
Experts during the voting phase, assess the proposals based on their adherence to the DAO. If a proposal is deemed detrimental or misaligned with the DAO's interests, they can exercise their veto power to prevent its implementation, thereby preserving the integrity and values of the organization. The veto right can be described as following:
Veto configurations are customizable for each contract within the DAO, allowing Experts to veto proposals targeting specific modules. The duration for exercising a veto is also adjustable, ensuring flexibility in alignment with the unique needs of each DAO.
In essence, the veto process is a crucial governance tool, ensuring the alignment of proposals with the DAO's principles and protecting the interests of its members by preventing the execution of potentially harmful proposals. The veto process is integral to maintaining the integrity and alignment of a DAO with its foundational principles. Expert Groups, designated during the DAO setup, are entrusted with the authority to veto proposals that may not align with the DAO's fundamentals. This mechanism is designed to act as a safeguard, ensuring that all decisions made within the DAO adhere to its core values and objectives.
The veto process provides a structured method for Experts to assess the merits and alignment of proposals. By scrutinizing proposals against the DAO's principles, they can halt the implementation of any proposal deemed potentially detrimental to the organization or its members. This protective measure is crucial for preventing the enactment of misaligned or harmful decisions, thereby upholding the DAO's integrity.
Moreover, the veto process is adaptable, allowing each DAO to configure veto settings according to its unique requirements. This includes the ability to customize the veto period, ensuring that the duration within which a veto can be exercised aligns with the specific governance needs of the DAO. By incorporating these customizable elements, the veto process enhances the flexibility and responsiveness of the DAO's governance structure.
The voting process within a DAO is a fundamental mechanism allowing Members or Experts to participate in decision-making by voting on various proposals. This process is highly configurable, allowing for modifications to proposal types and associated settings, such as quorum and majority, through the parameter voting.
Voting power (V p ) is determined by the number of locked tokens in the DAO.
Therefore,
To ensure a proposal's validity, it must meet a specified quorum (Q), which is the minimum number of votes required.
Additionally, it should not be vetoed by more than n experts in the ExpGrp. The veto is true if more than n experts decide to veto the proposal:
The system offers three types of voting: Partially Restricted, Restricted, and Non-Restricted Voting, each serving different purposes and allowing various levels of participation from experts and the community. When a proposal is submitted, entities cast their votes. The validation of a proposal depends on meeting the quorum and veto criteria. If the condition is satisfied, the proposal passes and is executed; otherwise, it fails.
The voting process is transparent, with users unable to retract or revote, and voting is not anonymous in its basic configuration. The process is subject to various statuses based on user activity and decisions, ranging from Pending to Executed, each representing a different stage in the proposal's lifecycle.
Voting parameters are outlined in the Parameter Storage module, allowing for customization of essential parameters that determine the structure and execution of voting within a DAO. These parameters include voting and veto periods, required quorum and majority, and voting type, among others, enabling flexibility and adaptability as the organization evolves.
Ultimately, due to its modular architecture, any default functionality can be expanded, exemplifying the system's scalability and adaptability. For instance, features such as the ability to retract a vote can be seamlessly integrated.
This article explores a governance system designed to adapt and scale within an ever-evolving environment, referred to as a DAO within the Ethereum community. For effective DAO operation, the integration of key components such as Permission Manager, Vault, Voting, Member Storage, and Parameters Storage is essential. The integration of these components, as outlined in Figure 5, forms the fundamental structure of the DAO, enabling optimal performance and efficient scalability while maintaining core functionality. Within the Ethereum community, such systems are encapsulated by the term Decentralized Autonomous Organization (DAO), which will henceforth be used to describe our system.
For the effective operation of a DAO, the definition and integration of the following components are essential:
Permission Manager: Administers and regulates access permissions within the system, ensuring structured and secure interactions.
Vault: Serves as a fortified repository for assets and valuables within the DAO, safeguarding against unauthorized access and manipulation.
Voting: Orchestrates the decision-making paradigm, enabling members to propose initiatives and cast votes, thereby driving collective consensus.
Member Storage: Acts as a comprehensive database, cataloging members along with their corresponding roles and permissions, facilitating efficient management and reference.
Parameters Storage: Houses the adjustable parameters and configurations of the DAO, allowing for tailored system settings. These components will be discussed in detail in the following subchapters. The integration of these components, as outlined in Figure 5, lays the basis for the fundamental structure. This approach allows the DAO to reach its optimal performance and scale efficiently, while maintaining the core functionality that was originally designed.
The Permission Manager Module is a foundational component of the DAO, grounded in RBAS theory. It serves as the nucleus of the DAO, recording and storing permissions, and groups, and defining the essential functionality to uphold the governance structure previously outlined.
This module is pivotal for integrations and upgrades, acting as the gateway for any interactions with the DAO. Every component or entity that interacts with the DAO does so through the Permission Manager Module, ensuring a structured and secure interface for all integrations and modifications.
Given that every segment of the system interacts with the Permission Manager Module, efficiency is crucial, as users incur additional costs for each extra action. The modular architecture and unified shared storage for each core module significantly reduce costs when the module is not engaging with an external resource but merely accessing this module's storage, subsequently lowering the gas usage for users.
In the current landscape, this module can assist in meeting regulation requirements, as it can be effectively used to pause some components without harming the whole project at once. In addition to the modular architecture, every module within the product can be assigned a separate role, and even more than one, allowing system maintainers to act quickly in case of emergency.
In contrast, when a company or other entity deploys their DApps or DAO, they could face significant opposition from the state in which their company is registered. By its nature, all of the contracts that are deployed to the Ethereum network are meant to be immutable. Therefore, only well-designed architecture can solve the problem of regulatory compliance.
The Vault component acts as the entry point to the DAO Governance System, serving as a platform where users deposit tokens to engage in DAO governance activities. It is pivotal in governance processes, securing tokens during voting periods and releasing them post-voting to maintain the integrity of the voting process and to thwart governance attacks such as 'doublevoting' or vote manipulation through token borrowing.
By delegating the locking mechanism to the Vault rather than embedding it within the token contract, the system accommodates a broad spectrum of existing tokens for DAO governance, enhancing versatility and inclusivity. This approach ensures a secure and reliable voting environment, reinforcing the robustness of the overall governance structure.
Given its modular architecture, this module can effortlessly accommodate new tokens, each representing a new functionality that can be integrated into the vault module. Thus, if new standards emerge post-deployment, or if integration with a previously overlooked standard, such as ERC-5484 [14], becomes commercially significant, it only requires a single proposal to incorporate it into the system.
The Voting component orchestrates the voting process, serving as the hub where community members can initiate proposals and cast their votes, and where Experts can exercise their veto power. Given the system's capability to incorporate new components or extend functionalities to existing ones, the voting mechanism is designed to be adaptable to such modifications.
This component is intricately linked to the Permission Manager contract to validate the eligibility of the proposer to initiate voting, to cast a vote, or to exercise a veto. A generic interface is established to outline the 'voting situation', allowing the configuration of key voting parameters such as quorum, majority, and voting duration.
Using the 'voting situation' interface, the Voting component can concurrently manage both community and expert proposals. It interacts with the Member Storage to facilitate the veto function and with the Parameter Storage to adjust voting parameters.
Managing permissions through RBAS allows the voting module to control functionalities in new modules or to confine new functionalities under existing rules. This method enables abstraction from technical specifics like addresses, allowing immediate implementation of high-level structures, focusing solely on overarching organizational frameworks. Further, these structures can be easily replicated in voting situations.
The Voting component is the cornerstone of governance within the system, ensuring that every governance activity is meticulously managed and executed.
The Member and Parameter Storage modules serve as instrumental tools for pivotal DAO components like the Voting and Permission Manager, optimizing organizational efficiency within the DAO.
The Member Storage component organizes Experts within the DAO, essentially acting as a whitelist for community members elected by their peers to assume Expert roles. It streamlines the identification and management of Experts, ensuring a structured approach to expert involvement in governance activities.
The Parameter Storage module facilitates convenient management of DAO parameters, offering diverse functionalities to interact with parameters essential for various DAO components. It simplifies the adjustment and monitoring of system parameters, enhancing the adaptability of the DAO to evolving governance needs.
The modular architecture enhances these two components by allowing the incorporation of specific functionalities post-deployment of the module, with such functionalities being seamlessly integrated into the governance structure through RBAS.
The synergistic integration of these modules reduces the complexity inherent in other DAO components and elevates the overall auditability and transparency of the system, contributing to a more coherent and manageable governance structure.
Combining the different modules results in a robust system that can be easily scaled up. Thus, including the Regulatory module requires one proposal from the community, as shown in Figure 6.
Due to the modular smart contract architecture, the new regulatory module can be easily integrated into the DAO core. This integration allows the DAO to ensure compliance with the rules required by the state in which it is registered, but it is only one use case. In addition, the RBAS ensures that this module is simultaneously integrated into the DAO governance system. This means that any configuration desired by the DAO can be achieved, such as a configuration where only experts manage the new module. However, the initial adoption of such rules is subject to community approval. The modular nature of the DAO system allows for the seamless integration of additional functionalities, extending beyond utility modules to encompass various protective and cross-chain capabilities. For instance, specific firewalls can be integrated to safeguard the DAO against malicious actors, enhancing security and stability. Furthermore, cross-chain functionality can be implemented, enabling the DAO to operate not only on its originating blockchain but also on other chains. This cross-chain integration can significantly reduce execution costs by delegating computational tasks, such as proposals or complex validation and verification processes, to different chains.
Additionally, the integration of new modules introduces functionalities that may not have been available at the DAO's inception. For example, modules that integrate with various KYC providers can be added to facilitate voting schemes like one-person-one-vote, ensuring equitable participation. This feature is particularly pertinent in the contemporary landscape, marked by the rise of Artificial Intelligence and Zero-Knowledge Proof-based systems. Such integration underscore the DAO's ability to adapt and scale in response to evolving technological advancements and community needs.
The architecture described in the article lays a solid foundation for the community to build upon and expand. The inherent flexibility and scalability of the modular approach ensure that the DAO can continually evolve, incorporating new technologies and governance models as they emerge. This adaptability is crucial for maintaining the relevance and efficacy of the DAO in a rapidly changing environment. The proposed architecture guarantees these properties, providing a resilient and scalable framework that can meet the diverse and dynamic requirements of modern projects.
Summarizing all the components described above, our system gains two important guarantees: Liveness: As soon as the system is updated with new modules, it remains actual and relevant. Formally, for any module mod i , if mod i is integrated at time t, then the system state S reflects the integration at t + є: Safety: With a guarantee from the voting process and the RBAS system, the system stays secure, ensuring that only authorized and secure actions are allowed. Formally, for any action a on resource r by entity e, if the action is performed, then e has the necessary permissions:
These properties ensure that the DAO remains functional and secure, adapting to changes while maintaining strict access controls.
This article has presented a scalable and adaptable governance system on the Ethereum network, designed to circumvent the inherent limitations of the Ethereum protocol. The foundation of this system is the RBAS, which orchestrates the interactions between various components within a DAO. However, RBAS alone is insufficient to overcome the constraints related to Smart Contract size and the immutable nature of contract logic post-deployment inherent in the Ethereum protocol.
To address these challenges, we introduced a modular system architecture, allowing the DAO to expand and integrate a diverse range of modules while maintaining coherent governance. This modular approach, coupled with the Expert governance structure, enhances the security and reliability of the system, ensuring robust protection against potential vulnerabilities.
We have also delineated a core set of components essential for initiating the functionality of the DAO, laying the groundwork for a system that is not only scalable and adaptable but also secure and governed with precision and transparency.