Interfold Governance

This page is the reference for how voting power, proposals, voting, and execution currently work in the Interfold DAO. It is for FOLD holders, delegates, and ciphernode operators who take part in governance. At the end, you know where voting power comes from, how a proposal moves to execution, and which parameters apply.

Interfold governance is the decision-making system for the Interfold DAO. The DAO is built on Aragon OSx (opens in a new tab). Governance uses FOLD voting power, and it is centered on encrypted secret-ballot voting through CRISP.

Governance at a glance

The standard Interfold governance proposal is an IPP (Interfold Protocol Proposal). An IPP uses CRISP for encrypted secret-ballot voting.

A FIPP (Fallback Interfold Protocol Proposal) gives a transparent voting path if CRISP cannot be used. FIPPs are strictly a fallback mechanism, not an alternative default voting mode.

The current proposal lifecycle is:

Proposal → Community vote → Foundation approval → Execution

The sections below describe each part of this process.

Voting power

Voting power comes from committed FOLD, not simply FOLD held in a wallet. Each committed FOLD counts 1:1 toward voting power.

FOLD can contribute voting power in three ways:

A transferable FOLD balance held in a wallet does not provide voting power unless it is committed through one of these mechanisms.

Locked, bonded, and vesting FOLD have the same governance weight once active: 1 FOLD = 1 vote.

Locked FOLD

FOLD can be locked through the Interfold governance interface (opens in a new tab) to create a voting position. Locked FOLD contributes voting power only when it has been delegated. The lock remains under the control of the wallet that created it.

Delegation. Locked FOLD can be delegated to the holder's own address or to another address. The delegate can be changed later. Delegation applies to the current and future locks of the holder. Delegation transfers voting power, not ownership of the underlying FOLD.

Unlocking. Locked FOLD can be unlocked at any time, subject to a 30-day delay:

1. Start the withdrawal. Voting power associated with the withdrawing FOLD stops immediately.
2. Wait through the 30-day cooldown.
3. Claim the FOLD when the cooldown ends.

Bonded FOLD

FOLD bonded to a ciphernode counts automatically toward governance voting power. It does not require separate delegation.

Bonded FOLD is already committed to network participation. Ciphernode operators post economic collateral to participate in the network. They are subject to a 30-day exit delay when they decommission their ciphernodes. The ciphernode system also uses sUSDS-denominated tickets, which contribute to committee sortition weight.

See the ciphernode documentation for bonding, tickets, committee selection, and operator penalties.

Vesting FOLD

Eligible vesting FOLD counts automatically toward governance voting power. It does not require delegation.

Delegating bonded and vesting FOLD

Bonded and vesting FOLD count for the bond owner or the vesting holder without delegation. An account that cannot vote itself, such as a Safe, can give this voting power to one other address:

1. From the owner account, call delegateBonded(delegate) on the BondedVotes contract.
2. From the delegate account, call acceptBonded(owner). The voting power moves at this step.

A delegate can represent up to three owners at a time. The owner can take the voting power back at any time with delegateBonded and the zero address. The delegate can give it back with dropBonded(owner). Only the current delegate of that owner can call it. If the owner asks a different delegate, the current delegation stops immediately, and the voting power stays with the owner until the new delegate accepts. A change does not affect a vote that already took its snapshot. Locked FOLD keeps its own delegation, which you set in the governance interface.

How the contracts add the three sources

The BondedVotes contract computes the voting power of an account. It reads all three sources at the same timepoint and adds them:

• Locked FOLD: the voting power that the voting escrow gives the account. This part follows delegation.
• Bonded FOLD: the bonded total of the account as a bond owner, from the BondedCheckpoints contract. While a delegation is in force, the bonded and vesting FOLD of the owner count for its delegate instead.
• Vesting FOLD: FOLD that is still under a lock policy in the FOLD contract. The contract subtracts the part that the bond already covers, and caps the result at the wallet balance.

Accounts with no voting power

The BondedVotes contract gives no voting power to these two accounts:

• The Interfold Foundation Safe, 0x5429D8c7fD14023f3c414126F94BbE25A05fC018
• The Gnosis Guild Safe, 0x12BEEF35025841EFccb77D6EE40df86400Fdb4bB

For these accounts, getPastVotes, getVotes, and balanceOf return zero. These accounts cannot give bonded or vesting FOLD to a delegate, and they cannot be a bonded delegate. The list is set when the contract is deployed, and it cannot change. The FOLD of these accounts stays in the total supply, which is the quorum denominator.

The exclusion applies to these two addresses, not to their FOLD. If one of these accounts transfers FOLD to a different address, that FOLD can give voting power to its new holder. If one of these accounts transfers the ownership of a bond, the bonded FOLD counts for the new bond owner.

BondedVotes does not see delegation in the voting escrow or in the FOLD contract. If one of these accounts delegates locked FOLD to another address, that address gets the voting power. If you delegate locked FOLD to one of these accounts, that voting power counts for nobody.

Voting weight and eligibility

The voting weight of a participant is determined by active FOLD voting power. 1 FOLD of active voting power = 1 vote. Locked, bonded, and vesting FOLD are not weighted differently once active.

Eligibility to vote

Any non-Foundation holder with active committed FOLD voting power is eligible to vote.

Voting-power snapshot

Voting power for a proposal is determined from the snapshot taken immediately before proposal creation (proposal creation timestamp − 1). The governance interface displays:

• The voting power of the connected wallet at the snapshot.
• The total voting power eligible for the proposal.

Changes to voting power after the snapshot do not change voting weight for that proposal.

The FOLD token uses timestamps as its clock (CLOCK_MODE is mode=timestamp). The CRISP program records the snapshot of a round as clock() - 1 in the transaction that requests the E3. The requester cannot choose a different timepoint.

Proposal types

Interfold governance uses CRISP-based secret-ballot voting as its standard governance path. Transparent voting exists as a fallback mechanism, not as a co-equal voting mode.

The underlying FOLD voting-power rules are the same for both proposal types.

IPP: Interfold Protocol Proposal

An IPP is the standard Interfold governance proposal.

IPPs use CRISP (Coercion-Resistant Impartial Selection Protocol), the reference implementation of the Interfold for encrypted secret-ballot voting. CRISP applies the confidential coordination model of the Interfold to governance. Encrypted ballots contribute to a shared result, and the committee decrypts only that combined result.

Each ballot is encrypted in the browser of the voter and tallied under encryption within an Encrypted Execution Environment (E3). No single ciphernode can decrypt a ballot. The combined result is public. These protections depend on the conditions in Privacy limits.

A CRISP voting round proceeds broadly as follows:

1. A CRISP voting round is initiated.
2. A ciphernode committee is formed.
3. The committee performs distributed key generation (DKG) to establish a shared encryption key.
4. Eligible participants submit encrypted ballots.
5. The tally is computed over encrypted votes.
6. The final tally is threshold-decrypted.
7. Anyone can verify the outcome. The verification does not decrypt individual ballots.

No single ciphernode controls output decryption.

CRISP therefore separates ballot visibility from outcome verifiability. Individual ballots stay encrypted, and the resulting decision stays verifiable, under the conditions that follow.

Privacy limits

The privacy of a CRISP ballot depends on these conditions:

• Committee threshold. Decryption needs a threshold of committee key shares (T + 1). If T + 1 or more committee members collude, they can decrypt individual ballots.
• Public result. The committee decrypts only the combined result, and that result is public. In some polls, for example small or one-sided polls, the result can show how individual participants voted.
• Sender. The CRISP server receives every ballot, so it sees each request. A ballot that the wallet of the voter sends also shows the voter address on-chain. When the CRISP server relays a ballot, the chain shows the relay address.

Changing a vote

A participant can submit a new encrypted vote before voting closes. Only the valid vote in effect when voting closes is included in the final tally.

Vote masking and receipt-freeness

IPPs also support vote masking. Vote masking makes observable ballot activity weaker evidence of how someone voted.

A mask creates a valid encrypted update without changing the underlying vote. On-chain, a vote, a vote update, and a mask look the same. For this reason, visible activity alone does not show an outside observer the true or final choice of a voter.

Vote masking makes receipts weaker: on-chain activity is not reliable proof of how a voter voted. This protection holds only under the conditions in Privacy limits. It does not hold, for example, when T + 1 committee members collude, or when the public result shows how a participant voted.

This technical blog post (opens in a new tab) covers the detailed masking mechanics.

FIPP: Fallback Interfold Protocol Proposal

A FIPP is the transparent fallback proposal type.

FIPPs are used strictly when CRISP is unavailable or an issue prevents the standard IPP voting process from being used. Individual votes and tallies are visible on-chain.

FIPPs use the same FOLD voting-power model as IPPs. They proceed through the same governance lifecycle after voting.

Proposal lifecycle

Interfold governance currently uses a multi-stage process:

Proposal → Community vote → Foundation approval → Execution

Creating proposals

Governance participants with at least 12K FOLD of active voting power can create proposals through the Interfold governance interface (opens in a new tab).

The standard proposal type is an IPP, which uses CRISP for encrypted secret-ballot voting. FIPPs exist only as a fallback when CRISP cannot be used.

Community vote

After a proposal is created, eligible FOLD voting power determines whether it passes its voting stage.

IPPs use encrypted secret-ballot voting through CRISP. FIPPs use transparent voting only when the fallback mechanism is required.

Foundation approval

A proposal that passes the community vote does not execute automatically. It moves to Foundation Approval, where the Interfold Foundation Board reviews the proposal before implementation.

Under the governing framework of the Foundation, the Board is expected to approve implementation. The exception is when the Board reasonably determines that a defined constraint applies. For example, a defined constraint applies when implementation would:

• Be unlawful, unsafe, or impracticable.
• Be inconsistent with the purposes or governing documents of the Foundation.
• Breach a binding obligation.
• Create material legal, regulatory, security, solvency, or operational risk.

If one of those grounds applies, the Board may reject, defer, condition, or return the proposal for modification. The Board must publish its reasons.

When the Board approves implementation, the passed proposal becomes a DAO Resolution.

Execution

A DAO Resolution can be implemented or executed in accordance with the governing documents of the Foundation and the configured Aragon OSx rules.

DAO and Foundation authority

The Interfold DAO and the Foundation have distinct roles within the governance system.

Token holders can submit and vote on proposals about matters within the purposes of the Foundation. Passed proposals that complete Foundation review become DAO Resolutions. The Directors are responsible for implementing DAO Resolutions, subject to their legal and fiduciary duties.

The DAO also has direct governance powers over parts of the structure of the Foundation:

• Electing Directors.
• Changing the size of the Board.
• Removing Directors. Director-removal votes do not require Board approval.

Certain matters may also be designated as Reserved Matters. The Foundation cannot act on a Reserved Matter without prior approval through a DAO Resolution.

Interfold Constitution

The Interfold Constitution is the charter of the Interfold DAO. It defines the governing principles and processes of the DAO, and the relationship of the DAO with the Interfold Foundation.

Protocol users do not adopt the Constitution merely by using the Interfold. Participants opt in through specified governance actions, including:

• Locking FOLD.
• Submitting or voting on proposals.
• Receiving payments made under DAO Resolutions.

Read the Interfold Constitution →

Governance parameters

This table is the reference for the live Interfold DAO configuration.

The CRISP program checks part of this timing when the E3 for a round is requested:

• A round that opens voting before the worst-case key deadline is refused.
• A round that leaves less than one hour for new vote commitments is refused.
• New vote commitments close one Avail finalization window before the end of the E3 input window. The CRISP deploy script sets this window to 10,800 seconds (3 hours).

Governance interfaces and resources

• Interfold Governance (opens in a new tab)
• Interfold Constitution
• CRISP documentation
• Ciphernode documentation
• Vote masking and receipt-freeness (opens in a new tab)

Next steps