A Comprehensive Framework for Assigning Voting Power and Managing Voter Attention for the Stellar Community Fund
Introduction
Neural Quorum Governance (or NQG) is a novel voting-power attribution and delegation mechanism that was ideated, specified, and implemented in a joint effort between BlockScience and the Stellar Development Foundation (SDF). The name is a juxtaposition of its two key constituents: Neural Governance, which enables modular, plug-and-play development and exploration of mechanisms for voting-power attribution, and Quorum Delegation, a new delegation scheme which allows users to delegate their votes without having to trust a single delegate.
The first implementation of NQG will be used to signal award allocation of the Stellar Community Fund (SCF), an open-application awards program managed by the SDF that draws on community input to support projects building on Stellar and smart contract platform Soroban.
Common issues across voting mechanisms include inaccurate sentiment of the larger community, voter fatigue, and apathy, as well as a lack of growth in the core group of voters. NQG aims to solve these issues in SCF by:
- Distributing voting weight across community members in a fair, transparent, and decentralized way in alignment with the SCF’s objectives;
- Fostering higher engagement by empowering members to grow their reputation within the community;
- Providing greater flexibility on voting responsibilities when a voter has limited availability or expertise.
- Making it more accessible for newcomers to join, which is necessary for the success of Stellar and Soroban.
In this post, we'll describe what Neural Quorum Governance is and how we expect it to be used by the Stellar community. In our next post in this series, we will outline the requirements and desired properties that led to the development of NQG, and explain more about the story of ideation, design, and implementation that brought it to life. In a final post in the series, we will discuss the forthcoming Governance Modules Library (GML) for Soroban, which is a curation of both new and classic modules for governance in dApps and DAOs. Its stated goal is to spread best practices and innovation as well as to accelerate adoption of Soroban as an ecosystem.
Describing Neural Governance
Neural Governance (NG) is a modular, transparent and flexible architecture for defining a member's Voting Power towards projects in the ecosystem. Neural Governance utilizes the notion of Voting Neurons (composed of an Oracle and Weighting functions) that are layered and aggregated together to form a user’s Voting Power. A full specification, along with a user journey description and simulations for it, can be found in the Governance Modules Library, while a stylized explanation of how power is attributed can be found in fig. [NG].
The "neural" terminology arises because when zoomed out, the information flow has analogies to a prototypical neural network. The core insight that led us to this architecture is the desire to have explainable mechanisms and the ability to express complexity through composition (e.g. by wiring together many simple pieces) rather than functionally (e.g. by having a single and complicated mechanism).
By having a large number of individually simple "voting neurons", we are able to produce complex outcomes without losing mechanistic simplicity. For instance, it is expected that voting neurons will be able to represent aspects like reputation, past voting success, or many other variables (fig. [NG-box]).
Some of the key benefits of using voting neurons include:
- A plug-and-play experience for voting neurons development and configuration;
- Expressing complexity through many simple integrated pieces rather than a single isolated complicated piece;
- Enabling and directing development over modules that can be composed together; and
- Enabling piecewise transparency.
Specifically, for the initial implementation of Neural Governance in the SCF, we'll be using three distinct Neurons:
- A Trust Bonus Neuron;
- A Reputation Badge Neuron; and
- A Voting History Neuron.
The first one computes a bonus based on a page-rank calculation that is applied on the Trust Network created by the SCF verified members, while the second and third ones use oracle functions to retrieve badges and participation attestations for manually assigning voting power bonuses.
Our expectation with this architecture is to enable an evolutionary and iterative approach towards the voting mechanism’s maintenance and development. Weights across neurons can be changed from round to round based on diagnostics and intended outcomes through a governance process. Unforeseen needs can be funneled through the ideation and implementation of new neurons that capture important dimensions of projects and users to be prioritized. Neural Governance provides a stable framework on which continuous innovation and adaptation can occur as to how voting power should be allocated.
Describing Quorum Delegation
Quorum Delegation (QD) allows users to delegate their votes to private groups (called Quorums) of users that they trust and to place conditions on how much agreement among a Quorum is needed for vote delegation to occur. Users can use Quorum Delegation to manage their involvement in a vote and to protect themselves from rogue delegates by requiring a high level of agreement within their Quorums. It is inspired by Quorums in the Stellar Consensus Protocol and it stands as an innovation when compared to traditional methods of delegation, which tend to rely on individual delegates. A full specification can be found in the Governance Modules Library.
Key benefits for adopting Quorum Delegation include:
- QD allows for managing community members' attention in a way that reinforces trust and group cohesion; and
- QD avoids collusion issues that are common on delegation-based systems. A stylized example is showcased at Fig. [QD].
Depending on the Quorum Participation (how many of the Quorum members are active) and its relative agreement (how much the active Quorum members agree among themselves), the Delegating Member vote will either follow its Quorum Consensus (which is any decision above a simple majority of the active Quorum members) or Abstain. More specifically, the delegated voting power only counts when a certain threshold of active voting is reached by the Quorum members (for the Proof of Concept (PoC), that threshold is set to 3 out of 5; but this is potentially customizable i.e. 2 out of 3, or 4 out of 5).
Quorums are privately formed, meaning an individual does not know which Quorum they are a part of. An individual can delegate their voting power to one or several other participants (5 in the initial PoC), who then make up the individual's Quorum. To reduce the risk of Quorums falling under the voting threshold, a user can designate and rank more Quorum Candidates, who when voting can become a part of the actual Quorum. This allows distribution of delegation over a group rather than one specific individual prone to bribery. A Quorum’s additional voting power (delegated by the user) is only applied to the individuals voting if the Quorum is in agreement. If 3 out of 5 Quorum members vote for the same choice, the additional voting power delegated will “agree and vote with them”. If the Quorum does not agree, the delegated voting power will not be applied.
Community Involvement in Neural Quorum Governance
Neural Quorum Governance offers a way to cleanly separate the multiple concerns that must be considered when designing a fair and transparent governance mechanism based on community voting.
Each Neuron encapsulates a concern, such as the degree to which a community trusts an individual voter, the degree to which an individual voter trusts themselves, or the degree to which a given voter has effectively participated in the community. This separation of concerns across neurons makes each neuron simpler to design and optimize, which in turn makes the design of each neuron more legible to the community.
Additionally, the concern of how to aggregate the effects of individual neurons is encapsulated in the design of the network structure, i.e. layering and connecting to an output neuron, separating this concern from the design of individual neurons. Weights enable governance participants to control the relative importance of each Neuron without requiring re-implementation.
This separation of concerns paves the way for the community to take ownership of NQG. While coding proficiency will still be required to implement neurons, simpler and more legible neurons enables more of the community to make design recommendations. Additionally, the modularity inherent in NQG’s architecture simplifies the development of simulations to help predict the effectiveness of design recommendations and the development of dashboards that track operational effectiveness of design decisions.
Over time, we expect the community to take several roles in NQG. Some of them are:
- Feeding a backlog of behaviors / concerns / desired properties that should be incentivized / disincentivized through novel Neurons.
- Implementing new Neurons. This could be incentivized through development bounties.
- Discussing & tuning the weights over the active Neurons. Do they sufficiently express the ecosystem's intended goals as a whole?
Lastly, there's the challenge of making sure that the community feels empowered to take on those roles. As part of this, BlockScience will be releasing an open-source repository containing a cadCAD model for NQG that allows the public at large to perform backtesting and extrapolation simulations using a Design Digital Twin of NQG. The repository will contain educational Jupyter notebooks that will enable members to gain intuition on the current inner workings of NQG, as well as to simulate "what-if" scenarios in which new Neurons or new combinations of weights are implemented.
The Requirements Behind Neural Quorum Governance
Brainstorming and deciding on Neural Quorum Governance was the outcome of a collective ideation exercise by BlockScience and SDF where requirements, desired properties and constraints were discussed and mapped in light of prior experiences and practical / theoretical considerations as per BlockScience's Models-Based System Engineering process. (Fig. [V])
The discussions involved both mapping a wishlist (as per Fig. [Wish]) based on expectations, while also discussing opportunities and limitations that arise from different design choices. Section A1 of the Appendix describes some of the prior voting mechanisms that were studied and discussed.
The collected requirements can be described as follows:
- Any community fund disbursement voting mechanism must reasonably align with the community’s expectations of what these funds should accomplish and when to consider disbursement fair (see e.g. this article). In other words, what is valuable to a community can be constrained by clarifying the purpose of a pool of funds. This can partly be streamlined in advance by only allowing proposals to move to a community vote if they comply with the designated purpose of the funding. This can be verified in a number of ways, including by a permissioned member of the community, by assigning additional voting power to domain experts, by allowing for non-binary vote possibilities (such as “conditional yes”), or by including community-aligned trust scores. Additionally, disbursement of funds can be aligned after a vote in a number of ways, such as releasing funds gradually based on milestone-based progress, retroactive funding, or other forms of ex-post verifications, as well as reputation-based voting weights based on realized outcomes of past voting decisions.
- Additionally, a suitable voting mechanism must align with the cost of the attention and time dimension. While voting can be structured in discrete windows to encourage focused attention and streamline operations, dynamic voting windows can increase access and continuous funding opportunities. Delegation of voting power reduces individual attention cost in the short-term but can increase collusion and centralization risks over medium to long-term. Additionally, a suitable voting mechanism should not introduce complexities that negate legibility through high barriers of access.
- Finally, a key point was the need for alignment on and contextually fitting expressions of abstract ideas. As an example, a simplification for a voting mechanism would be to assume that a user deciding not to actively vote “Yes” on a project proposal means that they are against it. However, the expression of “No” is contextually quite different from not voting. Also, one might imagine that delegating voting power is quite similar to assigning trust to an individual. However, we determined that assigning trust (and potentially increasing that individual's voting power) has contextually different implications than assigning one’s own voting power to someone else.
Additionally, desirable properties were mapped out, such as the need for being 1) modular 2) scalable 3) being compatible with DAOs 4) flexibility for funding styles 5) embedding trust 6) privacy and 7) highlighting Soroban / SCP's capabilities.
Conclusion
Neural Quorum Governance proposes an exciting new mechanism to vote on funds disbursement in the Stellar Community Fund. Together, the Stellar Development Foundation and BlockScience have ideated, specified, and implemented a Proof-of-Concept of NQG over the past months that we are eager to share with the Stellar community.
NQG consists of a common framework to implement Governance Neurons, which decide on voting power for individual voters. Initially, three Neurons exist and they are:
- Trust Bonus Neuron: Users can assign each other trust, forming a trust graph. Via page rank calculations, users receive additional voting power if they are trusted by others in the network.
- Reputation Badge Neuron: Users can earn badges through showing expertise and participation. Users receive additional voting power through earned badges.
- Voting History Neuron: Participating in governance consistently results in a stronger community. Users receive additional voting power through past participation in prior rounds of voting.
Additionally, Quorum Delegation allows users to delegate their voting power to a group of other users. Reducing the need for users to vote on decisions they do not feel comfortable voting on, QD allows a potentially customizable delegation experience and can reduce the risk of delegating to individuals. SCF will use these mechanisms for funds disbursement via the SDF, to showcase Soroban capabilities and to further community engagement by open-sourcing these mechanisms in a governance module library.
This first blog describes the mechanisms and functionality of Neural Quorum Governance. The second blog in this series will describe the BlockScience process of ideating and specifying these mechanisms in collaboration with SCF, and a third piece will describe the Governance Module Library and the vision for the community to develop these further. Additionally, Karol Bisztyga, who was one of the main engineers involved in implementing the specified mechanisms, has published his own article on the journey to an MVP.
We invite the Stellar community to try these mechanisms themselves and to play around with the provided simulations and reference implementations. SDF and BlockScience are happy to respond to questions and to provide help on further iterations. Our vision includes many modules and Neurons being developed by the community, to represent the requirements and desirables that only the participants of a community themselves can surface. For more information, as well as blogs and updates check out the SCF Handbook, and stay tuned for the next articles in this series!
Article written by Danilo Bernardineli and Jakob Hackel, with contributions and reviews provided by Kelsie Nabben, Jessica Zartler, Jeff Emmett, Daniel Furfari, Anke Liu, Alejo Mendoza, Giuliano Losa, and SCF verified members.
About Stellar Community Fund
The Stellar Community Fund (SCF) is an open-application awards program managed by the Stellar Development Foundation to support developers and startups building on Stellar and Soroban. SCF relies on input from verified members in the Stellar community for award allocation, governance and project support to keep the fund running and developing. Review rounds run monthly and projects can request up to $100K worth of XLM at a time.
About Stellar and Soroban
Stellar is a public and open-source blockchain network for payments, on- and off-ramps, and tokenization. It is powered by the Stellar Consensus Protocol (SCP), which is a federated proof-of-agreement consensus mechanism. Soroban is a Rust / WASM / JSON-RPC based smart contract platform which is designed to be sensible, built-to-scale, batteries-included, and developer-friendly. It is meant to have seamless integration with the Stellar network and is currently live on Testnet.
About Stellar Development Foundation
The Stellar Development Foundation (SDF) is a non-profit organization that supports the development and growth of Stellar, an open-source network that connects the world’s financial infrastructure. Founded in 2014, the Foundation helps maintain Stellar’s codebase, supports the technical and business communities building on the network, and serves as a voice to regulators and institutions. The Foundation seeks to create equitable access to the global financial system, using the Stellar network to unlock the world’s economic potential through blockchain technology. For more information, visit stellar.org/foundation.
About BlockScience
BlockScience® is a complex systems engineering, R&D, and analytics firm. By integrating ethnography, applied mathematics, and computational science, we analyze and design safe and resilient socio-technical systems. With deep expertise in Market Design, Distributed Systems, and AI, we provide engineering, design, and analytics services to a wide range of clients including for-profit, non-profit, academic, and government organizations.
