> For the complete documentation index, see [llms.txt](https://stellar.gitbook.io/module-library/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://stellar.gitbook.io/module-library/power-attribution/neural-governance.md). # Neural Governance *Authors: BlockScience and SDF, July 2023* ## Summary Neural Governance is a framework for defining a User's Voting Power for a given project by using the abstractions of Voting Neurons, which are arranged and aggregated together in layers. Each Voting Neuron represents an independent piece of logic on how a User's Voting Power should be defined and consists of an Oracle Function and a Weighting Function, whereas the first encodes the core logic and the second encodes how it should be weighted. The outputs from all Voting Neurons are aggregated together in layers, and then passed as an input to the next layer, until a final value is reached. The rationale for this design is the fact that Voting Neurons allow for encoding a comprehensive set of power determinants, which enables a divide-and-conquer approach towards setting-up incentives without requiring an overly complex monolithic function. The name for this mechanism is inspired by its similiarity with the general architecture of Neural Networks, which also have the property of being able to encode complex behavior while being simple in its individual constituents.

Neural Governance in a glance. In this stylized implementation, User Vote Power starts with a default voting power (such as zero), which gets replaced by the voting power that is computed by aggregating the Reputation and Past Voting Neurons weighted outputs. This is then fed to the Trust Neuron, which will then provide the Final User Vote Power.

### Use Cases * Public Goods funds allocation: * Neural Governance allows administrators to enable purpose-specific Neurons, adapting the governance of funds allocation to a specific set of restrictions. For Public Goods funds allocation, this allows enabling Neurons that incorporate specific relevant signals, such as prior network participation, prior voting history, experience with Public Goods and more. Additionally, NG allows a community to easily and legibly adjust weights on those signals, which can enable a community to more effectively steer funds towards projects that might have fared worse under conditions engineered for For-Profit investments. * Domain-specific expertise representation: * Similar to above, NG also allows a community to set Neurons for a particular governance action to be higher weighted towards individuals with a particular set of expertise - such as technical engineering work, social impact work or academic background. The NG framework is flexible enough to adapt individual Neurons to accept and weight inputs according to community requirements. * Adaptive governance: * As NG accepts inputs at each layer, transforming them into weighted outputs for the next layer, it also allows for cross-round adaptations. As a starting point, we consider prior voting actions to be an important signal for future voting power allocations. Similarly, one might consider the results of those voting actions - project success and other outcomes - as inputs to future voting rounds. This ongoing feedback, with governance setting weights in between rounds, can enable a community to build experience and adapt voting power for various scenarios over long time periods. ## User Journey 1. Administrator User activates / de-activates neurons 2. NG is activated to provide a preview 3. Voting Users set their expected action to "Vote" or to "Delegate" 4. Delegating Users set their Quorum to at least 5 other users. 5. NG is activated during vote tallying 6. A Voting User casts a "Yes" or "No" vote for each project they want to vote on. 7. A Delegating User auto-votes for the same decision as the 5 highest ranked users in their Quorum who voted. A Delegating User abstains if either not enough Quorum Members actively voted or if they did not reach "internal agreement" (such as 4 active voters, 2 Yes and 2 No). 8. NG calculates the Voting Power for each vote, by aggregating outputs across layers. 9. Voting Power of users is provided to the Decision Algorithm 10. The Decision Algorithm calculates the aggregated Voting Power for "Yes" and for "No" per project. 11. Users can see and verify the overall decision. ## Module-specific Adjustments #### Parametric Adjustments * Neuron Re-Weighting * Adjusting the weights per Neuron, to reflect new information. * Neuron Re-Layering * Adjusting the layer of a Neuron, to change how aggregation works. * "Yes" / "No" Re-Weighting (e.g. overweighting of "No" votes) * By default a Yes and a No vote are seen as equally powerful (set to 1.0). This can be adjusted to reflect different requirements. * Adjustment of Decision Algorithm (e.g. 30% more "Yes" Voting Power than "No" needed to render an overall funding decision) * The Decision Algorithm decides whether a final result (weighed Yes vs. No votes) results in (in-)action. For highly sensitive decisions, the treshold for acceptance might be set higher. #### Logical Adjustments * Implementing new Neurons * Implementing new Aggregators * Implementing new Layers #### Functional Adjustments * Allowing for parallel layering * Allowing for optionality of Neurons ## --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://stellar.gitbook.io/module-library/power-attribution/neural-governance.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.