Components & Parameters

NQG is modeled after neural networks and leverages layered voting neurons that dynamically adjust voting weights based on a participant’s expertise, trust earned from peers, and historical contributions to SCF (Neural Governance). Additionally, NQG has a flexible delegation model inspired by the Stellar Consensus Protocol (Quorum Delegation), enabling users to delegate votes to a group rather than a single individual.

• Neural Governance

• Quorum Delegation

1. Neural Governance

Neural Governance is a modular framework used in the Stellar Community Fund for assigning voting power to community members based on their reputation, expertise, and historical contributions. It is inspired by the structure of neural networks, where simple components (neurons) are connected and layered to create complex and adaptable systems.

1.1. How Neural Governance Works

Neural Governance uses 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, which encodes the core logic.

• A Weighting Function, which 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.

Neural Governance at 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.

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:

• Plug-and-Play Neurons: New neurons can be added to the system to capture additional dimensions of user behavior or community goals.

• Weight Adjustment: The influence of each neuron can be adjusted over time through governance processes, allowing the system to evolve based on community needs.

• Transparency: Each neuron's contribution to a user's voting power is transparent and explainable, ensuring trust in the system.

1.2. Voting Neurons used in SCF

Neural Governance uses Voting Neurons to compute a user's voting power. Each neuron represents a specific aspect of a user's contribution or reputation within the community. These neurons are layered and aggregated to produce a final voting power score.

The key neurons in the initial implementation are:

• Tier

• Voting History

• Voting Quality

• Trust Graph

Out of the above, the Trust Graph Neuron is currently the main attributor of voting power. With Quorum Delegation, this makes SCF’s governance mechanism primarily trust-based. This has been a deliberate choice from the beginning, as SCF’s existing community prior to implementing NQG had been based on trust informally, and because ‘human trust’ has the capability to bridge multiple forms of reputation (e.g. quality of contributions, engagement within a community, and general sense), and can thus manage complexity of the system. Managing complexity is important in NQG, because the more neurons (data inputs) you add, the more parameters and weighting attribution methods you need to adjust, the more chance of unclarity and confusion on how the system calculates the final vote.

Weight attribution methods of each Neuron in SCF’s implementation are designed to mimic natural reputation attribution and learning curves so there’s a clear path for new users to gain voting power, prevent indefinite voting power attribution and power centralization), as well as allowing the community to collectively decrease voting weight of bad actors.

1.2.1. Verified Tier & Discord Roles Neuron

Purpose: Rewards users for demonstrating expertise and active participation in the Stellar Community Fund, specifically Discord.

Mechanism: Users earn verified tiers (Pathfinder, Navigator, Pilot) based on their contributions to the Stellar Community Fund, associated with their Discord account. Learn more about how verified tiers are earned here. Users get additional points for having specific discord roles. Weight is added in a linear fashion:

Discord Role	Weight Bonus
SCF Verified	0.0
SCF Pathfinder	1.0
SCF Navigator	2.0
SCF Pilot	3.0
Ambassador President	1.0
SCF Project	1.0
Public Good Contributor	1.0
Moderator	1.0
SDF	1.0
Tier 1 Validator	1.0
[Region] Ambassador	0.5

Example: A user with the "Pilot" rank receives a higher bonus than a user with the "Pathfinder" rank.

A user with “Navigator” rank and “SCF Project” role receives 2.0 + 1.0 = 3.0 bonus.

1.2.2. Voting History Neuron

Purpose: Encourages consistent voting participation.

Mechanism: Uses a logistic function to calculate a bonus based on a user's voting history. Recent active participation is weighted more heavily, and the bonus saturates over time to prevent long-term members from having an indefinite advantage

To calculate the Voting History Neuron Bonus:

1

Round Weight Assignment as input to bonus calculation

Each round a voter participated in gets assigned a weight through a logistic curve.

$$a+( k - a )(c + q * e(-b*(x - o)) )(1/n)$$

^{_{This formula was proposed by BlockScience (learn more about requirements and parameters here and the parameter effects of logistical curves on Wikipedia). a = the left horizontal asymptote, k = the right horizontal asymptote, c = 1, q = is related to the value Y(0), b = the growth rate, n = affects near which asymptote maximum growth occurs, o = X axis offset (current round # - 10), x = current round #}}

In the graph below, we chose arbitrary values (a = 0, k = 1, c = 1, q = 1, b = 1, n = 4, o = 22, and x = 33) to add mild effects influenced by round importance over the number of rounds. Weights for each round user voted in, are multiplied by a percentage of active votes of this user. Although it is set to always be at least 30%, because not all Tiers are allowed to actively vote.

Example: User A voted in round 30, from the graph above we can see weight for this round is 1.0. In this round user A submitted 68 Yes/No votes, and 32 Delegate votes, so 68%. The final weight of round 30 for this user will be 1.0 x 68% = 0.68.

User B voted in round 30, from the graph above we can see weight for this round is 1.0. In this round user B submitted 0 Yes/No votes, and 100 Delegate votes, so 0%. The final weight of round 30 for this user will be 1.0 x 30% = 0.3.

2

Calculation of Voting History Bonus

Weights are then multiplied by % of active votes in a given round, but no less than 30%.

$$a+( k - a )(c + q * e(-b*(x - o)) )(1/n)$$

_{a = the left horizontal asymptote, k = the right horizontal asymptote, c = 1, q = is related to the value Y(0), b = the growth rate, n = affects near which asymptote maximum growth occurs, o = X axis offset, x = Sum of Rounds Weights.}

In the graph below, we chose arbitrary values (a = 0, k = 1, c = 1, q = 1, b = 1, n = 1, o = 5) to add mild effects to the Voting History bonus influenced by the number of rounds.

Example: Alice has voted in 5 rounds: SCF#19, 20, 27, 28, 29. We look at the first graph, take the corresponding weight for each round, and apply the active voting bonus for each round. Assume Alice always votes 100% actively, so we get values 0.5, 0.6, 1.0, 1.0, 1.0. We sum the weights and get a value of 4.1. Then we look at the second graph for the value of 4.1 at the X axis, and see that on the Y axis the corresponding bonus will be 0.25 - this is Alice’s Voting History Neuron bonus. Now let's look at Bob who has also voted in 5 rounds, but more recently in SCF#26, 27, 28, 29, 30. For each of those rounds weight is almost 1.0, approximately summing up to 5.0. Looking at the second graph, Bob’s Voting History Neuron’s bonus will be 0.5. Even though both Alice and Bob voted in 5 rounds, recent rounds get almost twice the Voting History bonus.

3

The sum of the weights of all rounds participated is passed as an input for a logistic curve.

1.2.3. Vote Quality Neuron

Purpose: Validates the quality of previous votes.

Mechanism: Creates a retroactive performance bonus based on the completion rate of previously voted on and awarded projects.

For every project that a voter has actively voted for and has been selected to be awarded since SCF #30,

For any given user since SCF #30, we go over all votes of given user, since round #30, and check what is the current status of awarded projects he voted for. Depending on it, points are added or subtracted. If a project is:

• Live on Stellar within 6 months: 0.3

• Live on Stellar after 6 months: 0.1

• Not live on Stellar within 6 months, Awarded -0.3

• Not live on Stellar within 6 months, MVP -0.2

• Not live on Stellar within 6 months, Testnet -0.1

Example: In previous rounds, a user voted for one project that went live on stellar within 6 months, and one that is on testnet after 6 months, so his bonus will be 0.3 - 0.1 = 0.2 points.

1.2.4. Trust Graph Neuron

(Github | Module Brief)

Purpose: Encourage users to actively participate in the community, to become more trusted.

Mechanism: Each user defines a list of users they trust. Based on those lists we perform some calculations explained below:

• Normalized PageRank - calculates initial trust score based on how many users trust given user

• Highly Trusted Bonus - additional bonus if given user is trusted by a highly trusted user

• Trust History - used to determine if a user recently lost a lot of trust

1.2.4.1 Normalized PageRank

Min-max normalized PageRank algorithm is used to analyze the trust graph formed by community members. Initially each user gets assigned a trust value of 1n (n being number of users)

Then we iterate over all users a 1000 times using the formula below, to get an accurate page rank value.

$$PR(A) = \frac{1-d}{n} + d \sum_{B \in M(A)} \frac{PR(B)}{L(B)}$$

^{_{PR(A) - page rank value for user A, d - damping factor, in our case 0.85 (typical, commonly used value), n - number of users, BM(A) - some other user B that belongs to the set of all users trusting user A, PR(B) - page rank value for user B, L(B) - number of users trusted by user B}}

So for user A, we take 1-dn, add our damping factor multiplied by the sum of all trust scores of users trusting our user A, divided by how many users they trust. This means that trust from someone trusting less users is worth more.

After that we perform a min-max normalization to ensure that scores of all users are distributed between 0.0 and 1.0.

1.2.4.2 Highly Trusted Bonus

After calculating PageRank scores, we take users with top 10% scores, those are considered highly trusted individuals. Then for each highly trusted user, we take the list of users they trust, and give everyone an additional bonus of 15% of their own score. If someone is trusted by multiple highly trusted users, he will get this bonus multiple times.

Note: Keep in mind that even though we perform normalization after the PageRank, adding this HTB can result in the trust score of some users being higher than 1.0. This is an important change from the original implementation of the system, which was designed in a way so all 3 neurons should output values in range 0.0 - 1.0. We believe this isn't a flaw, because it makes the trust have a bigger impact on the overall NQG score, which is desired.

1.2.4.3 Trust History

Trust History safeguard is used to decrease a user’s voting power when significant loss of trust is detected in a short amount of time. We assume this event happens only when a member has violated SCF’s Code of Conduct, as it requires multiple users to actively remove someone from their trusted list of verified members. It works like this:

1. Instead of calculating PageRank and Highly Trusted Bonus only for the current round, we run it for current and previous rounds.

2. Then for each user calculate the % difference between the two results. Take those 3 examples:

   1. In round #32 user “A” has trust score of 1.0 and in #33 it grew to 1.2 because more people trusted him. This means his current trust is equal to 120% of previous trust.

   2. In round #32 user “B” has trust score of 1.0 and in #33 it fell to 0.8 because a few less people trusted him. This means his current trust is equal to 80% of previous trust.

   3. In round #32 user “C” has trust score of 1.0 and in #33 it fell to 0.6 because a lot less people trusted him. This means his current trust is equal to 60% of previous trust.

3. After we have those % diffs we run them through the logistic curve, which you can see on the graph below.

   
4. To calculate the final trust score we take the user's PageRank (with HTB if applicable) score from the current round, and multiply it by the trust multiplier (also %) that came out of the logistic curve. Let’s come back to our 3 examples:

   1. User “A” had a Page Rank score for the current round at 1.2, and it was 120% of his trust score from the previous round. So looking at the graph, 120% equals the trust multiplier being 100% - that means user “A” will have his final trust score equal to the page rank from the current round - in other words, his score is unaffected.

   2. User “B” had a Page Rank score for the current round at 0.8, and it was 80% of his trust score from the previous round. Looking at the graph, 80% equals 97% trust multiplier - this means, his score will also remain mostly unchanged.

   3. User “C” had a Page Rank score for the current round at 0.6, and it was 60% of his trust score from the previous round. Looking at the graph, 60% equals 64% trust multiplier - this means his final score will be 0.6 * 0.64 = 0,384.

A general formula for this:

$$D = \frac{T_c}{T_p} \cdot 100$$

$$M = 30 + \frac{(100 - 30)}{\left(1 + 1 \cdot e^{-0.2 \cdot (D - 70)}\right)^{1/3}}$$

$$T_f = \frac{M \cdot T_c}{100}$$

_{Where: D = what % of previous trust is current trust, Tc = current trust (page rank + HTB from current round), Tp = previous trust (page rank + HTB from previous round), M = outcome of Generalized Logistic Function with D as an input, and some arbitrary parameters, Tf = final trust score}

This algorithm doesn’t affect users whose trust score grows, or stays around the same level. Only if you lose a lot of trust between rounds, you will be affected by an even bigger trust score loss.

1.3. Calculating Final Neural Governance Score

After all 3 neurons are calculated, the results are aggregated together to give a final voting power. First we aggregate results of neurons in each Layer:

Layer #	Neurons	Aggregator Type	Explanation
Layer 1	Trust Graph Assigned Reputation Vote Quality	Sum	Adds results of all neurons
Layer 2	Prior Voting History	Product	Multiplies results of all neurons

_{Note: Layer 2 is designed to return the product (multiply all values) of the neurons, so if there were 2 neurons, Layer 2 would return neuron1 x neuron2 but currently it has only one neuron, hence Layer 2 output is equal to this single neuron output.}

Then results of both Layers are summed together to give final voting power.

---

2. Quorum Delegation

Quorum Delegation is a novel delegation mechanism that allows users to delegate their voting power to a group of trusted individuals (a quorum) rather than a single delegate. This approach reduces user attention costs and the risk of centralization and collusion while allowing high flexibility in delegation.

2.1. How Quorum Delegation Works

Quorum Delegation (QD) allows users to passively vote by delegating their choice to a group of users. Unlike traditional delegation (1:1), QD allows distributed delegation across multiple users.

1. Delegating members choose and rank a set of delegates.

2. If enough ranked delegates actively vote, their decision forms a Quorum Vote automatically for the user. If not enough ranked delegates actively vote,

3. The outcome of the Quorum Vote is weighted by the delegating member’s voting weight, and sent as input for the final vote tally.

In the example above, the quorum consists of 10 anonymous users of which 6 vote "Yes", 2 vote "No", 1 abstains, and 1 does not participate. The quorum participation threshold is 3/5 (6 users). Since "Yes" exceeds a simple majority (4 votes), the user automatically votes "Yes".

SCF’s implementation of NQG does not allow redelegation of delegating members who don’t actively vote themselves to keep accountability of active voting members and ensure a sufficient number of active voters on each funding decision. Should the number of voting members grow, we may eventually allow redelegation up to a certain amount of hops.

2.1 Definitions of Quorum Delegation in SCF

• Delegating Member: User with Pathfinder, Navigator, or Pilot tier that has selected to delegate a particular vote instead of actively voting for or against a proposal (Pathfinders can only delegate, not vote actively).

• Quorums: Delegating members create four delegate lists or quorums, one for each Project Category: Applications, Financial Protocols, Infrastructure & Services, and Developer Tooling

• Delegate: User with Pilot tier that has nominated themselves to be a delegate of one or more Project Categories. Learn more about the SCF Build Project Categories and nomination process with Category-Specific Delegate Panels.

2.2. Current Parameters of Quorum Delegation in SCF

The current implementation of QD in SCF has fixed parameters with relatively light thresholds to optimize for vote throughput. Some context: in rounds with SCF v5.0 and earlier, we saw a high amount of Abstain votes due to delegating members not actively voting. Lower parameter thresholds in combination with the Category-Specific Delegate nomination process have significantly improved delegate vote throughput.

Parameter	Description	#
Min Quorum Candidates	Minimum size of potential candidates a user must select for their Quorum	6
Max Quorum Candidates	Maximum size of potential candidates a user can select for their Quorum	15
Quorum Participation Threshold	Minimum % of quorum participants needed for a valid vote	5
Quorum Size	Max number of candidates considered in a Quorum Vote	15
Relative Agreement Threshold	Minimum % of agreement required among active votes	51%-67%*

_{*has changed in past few rounds depending on Abstain rate.}

Example Scenario

Example Scenario:

1. Alice (who is a Navigator) chooses to delegate her vote on ‘Applications’ to a quorum of 7 delegates.

2. During a voting round, 5 delegates of the quorum vote "Yes," and 2 delegates vote "No."

3. Since the quorum meets the consensus threshold (51%), Alice's vote (with her own voting power assigned through Neural Governance) is counted as "Yes."

2.2.1. Understanding the difference between the purpose of Trust Graph Neuron and Quorum Delegation

The relationships within the Trust Graph Neuron show correlations with Quorum Delegation as both are focused on trust, but each have a distinct purpose–while it might be assumed that a user would add their delegates to their trusted list of users, they would not necessarily select everyone in their trusted list as delegates (and not everyone would be available, as delegate selection happens quarterly based on nomination).

Trust in the Trust Graph Neuron is expected to be assigned more liberally—a user can assign trust for any reason to help gain reputation for that user— as there is no direct effect on their own choices and voting power. Similarly, a user can assign trust to a high number of other users, while Quorum Delegation is limited.