Aragon Conviction Voting Model - Version 1¶

Model Overview¶

Conviction Voting is a novel decision making process where votes express their preference for which proposals they would like to see approved in a continuous rather than discrete way. The longer the community keeps a preference on an individual proposal, the “stronger” the proposal conviction becomes. In the conviction voting model, a graph structure is used to record the introduction and removal of participants, candidates, proposals, and their outcomes.

cadCAD Overview¶

In the cadCAD simulation methodology, we operate on four layers: Policies, Mechanisms, States, and Metrics. Information flows do not have explicit feedback loop unless noted. Policies determine the inputs into the system dynamics, and can come from user input, observations from the exogenous environment, or algorithms. Mechanisms are functions that take the policy decisions and update the States to reflect the policy level changes. States are variables that represent the system quantities at the given point in time, and Metrics are computed from state variables to assess the health of the system. Metrics can often be thought of as KPIs, or Key Performance Indicators.

At a more granular level, to setup a model, there are system conventions and configurations that must be followed.

The way to think of cadCAD modeling is analogous to machine learning pipelines which normally consist of multiple steps when training and running a deployed model. There is preprocessing, which includes segregating features between continuous and categorical, transforming or imputing data, and then instantiating, training, and running a machine learning model with specified hyperparameters. cadCAD modeling can be thought of in the same way as states, roughly translating into features, are fed into pipelines that have built-in logic to direct traffic between different mechanisms, such as scaling and imputation. Accuracy scores, ROC, etc. are analogous to the metrics that can be configured on a cadCAD model, specifying how well a given model is doing in meeting its objectives. The parameter sweeping capability of cadCAD can be thought of as a grid search, or way to find the optimal hyperparameters for a system by running through alternative scenarios. A/B style testing that cadCAD enables is used in the same way machine learning models are A/B tested, except out of the box, in providing a side by side comparison of muliple different models to compare and contrast performance. Utilizing the field of Systems Identification, dynamical systems models can be used to "online learn" by providing a feedback loop to generative system mechanisms.

Differential Specification¶

Schema of the states¶

The model consists of a temporal in memory graph database called network containing nodes of type Participant and type Proposal. Participants will have holdings and Proposals will have funds_required, status(candidate or active), conviction. Edges in the network go from nodes of type Participant to nodes of type Proposal with the edges having the key type, of which all will be set to support. Edges from participant $i$ to proposal $j$ will have the following additional characteristics:

• Each pairing (i,j) will have affinity, which determines how much $i$ likes or dislikes proposal $j$.
• Each participant $i$, assigns its $tokens$ over the edges (i,j) for all $j$ such that the summation of all $j$ such that Sum_j = network.edges[(i,j)]['tokens'] = network.nodes[i]['holdings']
• Each pairing (i,j) will have conviction local to that edge whose update at each timestep is computed using the value of tokens at that edge.
• Each proposal j will have a conviction which is equal to the sum of the conviction on its inbound edges: network.nodes[j]['conviction'] = Sum_i network.edges[(i,j)]['conviction']
• The "trigger function" will check whether each proposal $j$ has met the criteria for passing; if a proposal passes its status changes from candidate to active, and an amount of funds equal to its funds_required will be decremented from funds.

The other state variable in the model is funds, which is a numpy floating point.

The system consists of 100 time steps without a parameter sweep or monte carlo.

Partial State Update Blocks¶

Each partial state update block is kind of a like a phase in a phased based board game. Everyone decides what to do and it reconciles all decisions. One timestep is a full turn, with each block being a phase of a timestep or turn. We will walk through the individaul Partial State update blocks one by one below.

{
# system.py: 
'policies': { 
    'random': driving_process
},
'variables': {
    'network': update_network,
    'funds':increment_funds,
}

To simulate the arrival of participants and proposal into the system, we have a driving process to represent the arrival of individual agents. For simplification, we are using hyperparameters for supply and sentiment, 1,231,286.81 and 0.6 respectively. We use a random uniform distribution generator, over [0, 1), to calculate the number of new participants. We then use an expoential distribution to calculate the particpant's tokens by using a loc of 0.0 and a scale of expected holdings, which is calcutulaed by .1*supply/number of existing participants. We calcualte the number of new proposals by

proposal_rate = 1/median_affinity * (1+total_funds_requested/funds)
rv2 = np.random.rand()
new_proposal = bool(rv2<1/proposal_rate)

The network state variable is updated to include the new participants and proposals, while the funds state variable is updated for the increase in system funds. To see the partial state update code, click here

{
  # participants.py   
  'policies': {
      'completion': check_progress 
    },
    'variables': { 
        'network': complete_proposal
    }
},

In the next phase of the turn, to see the logic code, click here, the check_progress behavior checks for the completion of previously funded proposals. The code calculates the completion and failure rates as follows:

likelihood = 1.0/(base_completion_rate+np.log(grant_size))

failure_rate = 1.0/(base_failure_rate+np.log(grant_size))
if np.random.rand() < likelihood:
    completed.append(j)
elif np.random.rand() < failure_rate:
    failed.append(j)

With the base_completion_rate being 100 and the base_failure_rate as 200.

The mechanism then updates the respective network nodes.

{
 # proposals.py
  'policies': {
      'release': trigger_function 
    },
    'variables': { 
        'funds': decrement_funds, 
        'network': update_proposals 
    }
},

The trigger release function checks to see if each proposal passes or not. If a proposal passes, funds are decremented by the amount of the proposal, while the proposal's status is changed in the network object.

{ 
    # participants.py
    'policies': { 
        'participants_act': participants_decisions
    },
    'variables': {
        'network': update_tokens 
    }
}

The Participants decide based on their affinity if which proposals they would like to support,to see the logic code, click here. Proposals that participants have high affinity for receive more support and pledged tokens than proposals with lower affinity and sentiment. We then update everyone's holdings and their conviction for each proposal.

Model next steps¶

The the model described above is a minimalist model, first iteration model that covers the core mechanisms of the Aragon Conviction Voting model. Below are next additional dynamics we can attend to enrich the model, and provide workstreams for subsequent iterations of this lab notebook.

• Sentiment
• Mixing of token holdings among participants
• Departure of participants
• Participants influencing each others opinions
• Proposals which are good or no good together
• Multiple proposal stages such as killed, failed and completed
• Affects of outcomes on sentiment

Simulation¶

Configuration¶

let's factor out into its own notebook where we review the config object and its partial state update blocks, with a slightly deeper dive on the trigger function.

Explore the network object¶

Exploring the State Data Structure¶

A graph is a type of temporal data structure that evolves over time. A graph $\mathcal{G}(\mathcal{V},\mathcal{E})$ consists of vertices or nodes, $\mathcal{V} = \{1...\mathcal{V}\}$ and is connected by edges $\mathcal{E} \subseteq \mathcal{V} \times \mathcal{V}$.

See Schema of the states above for more details

Let's explore!

Proposals initially start without any conviction, and with the status of a candidate. If the proposal's amount of conviction is greater than it's trigger, then the proposal moves to active and it's funds requested are granted.

All initial proposal start with 0 conviction and state 'candidate'we can simply examine the amounts of funds requested

Conviction is a concept that arises in the edges between participants and proposals in the initial conditions there are no votes yet so we can look at that later however, the voting choices are driven by underlying affinities which we can see now.

Run simulation¶

Now we will create the final system configuration, append the genesis states we created, and run our simulation.

After the simulation has run successfully, we perform some postprocessing to extract node and edge values from the network object and add as columns to the pandas dataframe. For the rdf, we take only the values at the last substep of each timestep in the simulation.

Conclusion¶

We have created a simplified conviction voting model that illustrates the state objects, and provides descriptions of how the model fits together. In subsequent notebooks, we will expand the model to introduce additional complexity to more fit real world implementations.