Overview

The core contract at the heart of Verifi is the Space contract. This contract serves as the central hub where proposals are created, votes are cast, and the entire proposal state is stored. However, it's important to note that a significant portion of the protocol's functionality has been abstracted out of the Space contract.

These abstractions encompass:

• Who can create a proposal.

• Who can vote.

• How the voting power of each user is determined.

• The execution procedure that will occur when a proposal passes.

This approach provides a significantly higher level of modularity and customizability compared to handling all this logic directly within the Space contract itself.

Creating a space on Verifi is akin to equipping a Swiss Army Knife. The Space contract serves as the main tool, and the Authenticators, Proposal Validation Strategies, Voting Strategies, and Execution Strategies act as versatile attachments, much like the various tools you can unfold based on specific needs. Together, we collectively refer to these components as Verifi Modules.

Let's briefly explore these aspects:

Authentication Mechanisms These govern the means by which participants are verified to initiate a proposal or participate in voting. Typically, this involves employing a form of signature or verifying the transaction caller.

Proposal Validation Approaches These determine how an author is validated to propose an idea. A common method involves verifying that the author surpasses a specified threshold of proposition power, computed through a set of strategies.

Voting Mechanisms These dictate how voting power is calculated. Contracts known as voting strategies provide the flexibility to define how the voting power of each participant is determined. This allows for the implementation of diverse and intricate governance mechanisms. While the prevalent approach involves token-based voting (1 token = 1 voting power, so 100 tokens yield a total voting power of 100), alternative strategies could be devised. For instance, granting voting power exclusively to owners of a specific NFT or adopting a quadratic model where users receive the square root of their token balance (mitigating the influence of significant token holders).

Execution strategies Serve two primary roles:

1) Determine the status of a proposal at any time during its lifetime.

2) Determine what should happen once a proposal passes.

The latter role typically involves executing a set of transactions linked to the proposal. The strategy has control over which contracts are authorized to execute the transactions or may execute them directly.

This modular design enables customization to meet specific requirements. While we offer a range of pre-built and audited modules, we encourage you to create your own!

What does the flow look like?

The complete usage flow is as follows:

1. An org deploys a Space contract, defining space settings alongside authenticators, voting strategies, and a proposal validation strategy.

2. A user can create a proposal in the Space via a whitelisted authenticator. The proposal validation strategy checks the user's eligibility to create the proposal. To create a proposal, the user must specify an execution strategy contract along with an execution payload containing the encoded set of transactions within the proposal.

3. Users can vote on the proposal by authenticating through one of the whitelisted authenticator contracts.

4. Once the voting period concludes, anyone can permissionlessly execute the proposal. This forwards the execution payload to the execution strategy and executes the included transactions.

The diagram below illustrates how the contracts comprising Verifi fit together, along with various user actions for creating proposals, voting, executing proposals, and updating settings.