The Interfold Constitution

Preamble

The Interfold protocol enables confidential coordination. Committees of bonded ciphernodes, selected via sortition, run a distributed key generation ceremony to produce a threshold fully-homomorphic encryption key with which computation over encrypted inputs can be run, with zero-knowledge proofs of correct execution, so privacy and integrity are cryptographic and game theoretic guarantees rather than trust in any single party or hardware.

Two institutions share responsibility for that protocol. The Interfold DAO is the community of participants who decide what the protocol does. The Interfold Foundation is the legal entity which owns the protocol's relevant IP, to which protocol revenue flows, and which engages with third-parties for commercial engagements, partnerships, and ongoing protocol development. It is bound by its own bylaws to act in furtherance of its Purposes, including the implementation of DAO Resolutions.

This Constitution is the DAO's charter. It defines the DAO's sphere, its process, and its relationship with the Foundation — which is itself governed by its own governing documents and is not bound by this text directly. Its goal is a stable middle: the community genuinely governs the protocol, and the Foundation can still hold IP, carry legal responsibility, and spend protocol revenue — while neither can quietly capture the other.

This document is deliberately short. It fixes a few principles and defers everything else to ordinary process, code, and amendment.

Article I — The Protocol and the DAO

1.1 The protocol

The Interfold protocol is an open-source system of smart contracts, circuits, and client software that coordinates Encrypted Execution Environments ("E3s"): sortition of ciphernodes, distributed key generation (DKG), encrypted computation, threshold decryption, and on-chain zero-knowledge verification of each step.

1.2 The mission

The DAO exists to keep the protocol secure, neutral, and improving, and available to anyone, everywhere, without permission.

1.3 Who this Constitution applies to

It applies to (a) the DAO as a governing body, and (b) every participant who opts in under Article III. It does not bind the Foundation, which lives under its own governing documents; the Foundation's relation to this Constitution is defined in Article II as a relationship between institutions, not as subjection. It does not bind users of the protocol: anyone may make E3 requests, provide inputs, build applications, or consume outputs without adopting it.

Article II — The Foundation: Recognized, Not Subordinated

2.1 The Foundation is its own institution

The Interfold Foundation is a Cayman Islands foundation governed by its memorandum and articles and bylaws, whose purposes include open-source development, security, and adoption of the protocol and the implementation of DAO Resolutions. It holds protocol revenue, conducts legal and compliance work, and designates the software repository. It is not bound by this Constitution, and this Constitution confers no personal obligations on its directors, officers, or supervisor.

2.2 One treasury

The DAO does not maintain a treasury. All protocol revenue — fees, incentives, and receipts of every kind — flows to the Foundation, which holds and deploys it, and the DAO's decisions about that money take the form of instructions to the Foundation under the phase in force (Articles 5.6 and VI). The DAO holds no claim on Foundation assets, and no vote of the DAO creates a debt, trust interest, or economic entitlement of any token holder.

2.3 Two paths to the Foundation

Because the Foundation answers only to its own governing documents, the DAO influences it through exactly two channels, and the Foundation's standing toward each is defined in this article:

(a) Resolutions. A passed proposal becomes a DAO Resolution — a governance instruction to the Foundation — once the Board approves its implementation. The Foundation honors each Resolution it implements, and may not evade, dilute, or reinterpret it beyond its text.

(b) The Board itself. The Board is elected, and may be removed, by FOLD holders under the Foundation's own instruments. The DAO will use this channel with restraint, but the community always holds it: a Board that persistently acts against the protocol's interest can be replaced without the Board's consent. This is the community's last resort, not a standing lever.

2.4 Foundation role within this structure

The Foundation’s role within this structure includes: (a) implementing approved DAO Resolutions promptly and in good faith; (b) giving reasoned notice to the DAO when it declines approval of a passed proposal (including why, under which ground, and any proposed modification); (c) keeping the software repository open source under the protocol's license; (d) not using its revenue, IP, or branding to steer adoption away from the DAO-designed protocol toward a parallel Foundation-controlled deployment; and (e) acting in furtherance of its purposes — which include the protocol's open-source development, security, and adoption — when interpreting its own documents.

2.5 The transition is one-way

The Foundation's role in the proposal pipeline moves through the phases in Article VI — full approval (Phase 1), qualified veto (Phase 2), exit (Phase 3). Transitions run in exactly one direction, are defined at adoption or by a Constitutional proposal, and may not be reversed from a later phase back to an earlier one. A Foundation decision to decline to approve a passed proposal (Phase 1) is a reasoned decision consistent with the reasoned-notice expectation in 2.4(b) — it is a constraint, not a power to set policy.

Article III — Who Opts in, and How

3.1 Users do not opt in

Interfold is permissionless. Making an E3 request, providing inputs, running a client, or building an application on the protocol does not adopt this Constitution, and cannot.

3.2 Opt-in is the only path in

The obligations of this Constitution apply to participants who opt in by locking the FOLD in the Interfold DAO's VE Locker, submitting or voting on a proposal, or by receiving payments made under a DAO Resolution. That opt-in is revocable: a participant may stop participating at any time and is not bound after that. Opt-in is lightweight — it never requires identity, personal guarantees, or legal signatures beyond interacting with the governance interfaces — and carries no economic obligation or liability beyond what the interaction itself requires.

3.3 Ciphernodes bond to the protocol, not to the DAO

Ciphernode registration and bonding are protocol mechanics under DAO purview; a ciphernode's operational duties arise from the protocol's bonding and slashing system, not from this Constitution.

3.4 No secret overrides

Any side arrangement between a participant and the Foundation that purports to modify, waive, or add to the rules of this Constitution is ineffective under this Constitution unless it is published in full on the forum and settled without objection before it takes effect.

Article IV — Guiding Values, in Priority Order

Values are ranked in a hierarchy. When a decision conflicts across values, the higher-ranked value wins. While options remain open, the community should seek only Pareto improvements — changes that improve one value without impairing a higher-ranked one — and if even that is impossible, the conflict should be resolved by amendment, never by silently letting a higher-ranked value be eroded.

1. Privacy of users is non-negotiable. No protocol change shall weaken the cryptographic exclusion of E3 participants from inspection of private inputs or intermediate states. Outputs may be revealed only according to the conditions defined for the E3. Privacy is not a feature to be traded away for convenience.
2. Openness and forkability. The protocol's code, circuits, documentation, and deployment tooling stay open source under the protocol's license, with verifier artifacts published. A viable fork must always remain possible; governance must never be allowed to break that property.
3. Credible neutrality and decentralization. No change may favor specific applications, operators, or jurisdictions over comparable ones; sortition remains the default committee-selection mechanism, and authority should be as widely distributed as cryptography allows.
4. Security before speed. Upgrades that touch cryptographic parameters, slashing, or verification carry the longest delays; governance cannot substitute for technical correctness.
5. Social and technical accessibility. Ordinary people with ordinary hardware should be able to build on and use the protocol, and the community should stay open and welcoming.

Article V — Governance Process

5.1 Proposals

A proposal may be submitted by any holder whose committed-FOLD voting power under 5.2 meets the on-chain eligibility threshold. A proposal must state plainly what it changes, why, what it costs (and which assets), what deployment(s) or parameters it affects, and whether it is Constitutional or non-constitutional as defined in 5.7.

5.2 Voting power comes from committed FOLD

Weight in governance attaches to FOLD that is committed, not merely held. The mechanics — implemented in the governance contracts and mirrored here — are:

• Locking FOLD creates a voting position that only the locker can withdraw;
• delegating that locked FOLD — to yourself or to someone you trust — is what activates its voting power;
• bonded and vesting FOLD count automatically, with no delegation step;
• each committed FOLD counts 1:1 toward voting power, whether locked, bonded, or vesting;
• a position can be withdrawn at any time: start the withdrawal, voting power stops as soon as it starts, and the FOLD becomes claimable after the 30-day cooldown.

The same committed-FOLD power determines both a holder's weight in votes and whether the submission threshold of 5.1 is met.

5.3 The single standard, on-chain, is the source of truth

All proposals — whatever their subject — vote under one set of rules: the quorum, majority, timing, and threshold mechanics implemented in the governance contracts. The on-chain implementation is the source of truth for the governance process; no Foundation document, policy, or off-chain statement defines, replaces, or supplements it. Those parameters are public, versioned, and change only through this process (9.1). There is no hidden second threshold, no off-chain counter-vote, and no separate "guardian" tally: if one number decides, that number is implemented on-chain and this article points at it.

5.4 Two paths, one two-stage flow

The DAO is built from two identical pipelines, each a separate staged proposal processor (“SPP”): a private process whose stage-0 body is CRISP voting, and a public process whose stage-0 body is on-chain TokenVoting.

Every proposal — on either path — runs the same two stages and ends the same way:

• stage 0 — the voting body approves (an encrypted CRISP ballot, or a public on-chain vote);
• stage 1 — the Foundation gate (which is an explicit part of both paths — see 5.5);
• → the SPP executes the approved actions on the DAO.

5.5 The Foundation gate is in every path

The Foundation is wired into stage 1 of both SPPs as a single manual decision: in approval mode a passed proposal executes only if the Foundation acts; in veto mode it executes unless the Foundation vetoes. The mode is an on-chain parameter of each SPP and is itself changeable by the DAO under 5.7; the transition between the modes is the roadmap of Article VI. Two structural facts make the gate binding and non-bypassable: (a) only the SPPs hold execute permission on the DAO — the CRISP and TokenVoting bodies never may, and if either ever regained it, the gate could be skipped; and (b) the bodies can only report their result up to the SPP — they cannot act on the DAO themselves. The stage-1 mode at any time is read from the SPP config, not assumed.

5.6 Private voting is the default; public voting is the fallback

The private path (CRISP) is the default route for all governance: ballots are voted privately via the FHE secret-ballot E3, preserving the privacy of individual votes as well as the execution (Article IV, value 1). The public path (TokenVoting) is a fallback — available any time, at lower ceremony, and used if the CRISP stack is unavailable or compromised for any reason. The two paths share one FOLD ERC20Votes token (BondedVotes adapter) and one delegation registry, so committed FOLD voting power is identical across them.

5.7 Constitutional versus non-constitutional

The governance system may distinguish between Constitutional and non-constitutional proposal tracks. The classification of a proposal, and any thresholds, stage windows, or other requirements associated with that classification, are determined by the on-chain governance configuration in force at the time.

A proposal that amends this Constitution must use the Constitutional track and satisfy Article IX. Other proposals may also use the Constitutional track where required by the governance contracts, but use of that track does not by itself amend this document.

The non-constitutional track is the normal path for routine governance.

5.8 Security posture and emergency powers

(a) Current state. At the time of drafting, there is no standing emergency authority in the governance contracts. The only emergency lever that exists is a time-limited admin bootstrap (the Aragon Admin plugin) that hands the DAO's EXECUTE permission to a single address (a Foundation multisig) while the phased install proceeds (public process → private process). This is a known centralization risk, deliberately recorded here as such. It is intended to be removed, not preserved.

(b) Roadmap — two commitments, each by a governance proposal. First, disarm the bootstrap. Once it has done what it exists to do (letting the private process be installed), the bootstrap is to be disarmed — by a DAO proposal, executed shortly after the private SPP is live — so that all proposals must go to the DAO for a vote. Second, empower a security council. By DAO proposal the community should adopt a narrowly-scoped emergency power — for example, the ability to pause a specific plugin or verifier, or to trigger a circuit-breaker on the protocol-controlled assets or flows — vested in a designated security council, whose members are named on chain, whose use is limited to the categories of emergency stated in the proposal, which must lapse within a defined period unless confirmed by a DAO vote, and whose every action must be recorded and reported to the DAO with its justification. No emergency power may be used to block or circumvent a pending vote, nor to amend this Constitution.

(c) Interim rule. Until (b) is live, actual emergencies must be handled by the cooperative, documented, and post-hoc disclosed cooperation of the Foundation and the community — or, where the emergency is existential, by the levers this structure actually gives the community (the board-removal power of 2.3(b); the fork of 7.2). This Constitution states this plainly rather than pretending that a standing safe harbor exists.

Article VI — The Road to Full Community Control

The phase in force is the stage-1 configuration of the two SPPs — an on-chain parameter (the mode of each SPP, readable via getStages) — changed by DAO proposal (updateStages) and moving in exactly one direction. Each phase below names both its on-chain state and its character as a matter of governance; a transition is the moment that configuration changes.

6.1 Phase 1 — Approval mode (in force at adoption)

Both SPPs run stage 1 in approval mode: a passed proposal executes only if the Foundation affirmatively approves it within the stage window; if the Foundation does not act, the proposal expires. The Foundation's step is case-by-case, and every decline should be accompanied by a reason under 2.4(b). A declined proposal is not a rejection of the community's right to propose: it is declined this time, on these stated reasons — the community's responses are amend and re-vote, resubmit on different terms, or — where the clash is fundamental and persistent — escalate under 2.3(b) and the 8.2 ladder. This phase is a trust-testing period, and both parties should treat it as such: patience is the price of the exit that Phases 2 and 3 will deliver.

6.2 Phase 2 — Veto mode

On transition, both SPPs run stage 1 in veto mode: optimistic — a passed proposal executes unless the Foundation vetoes it within the stage window; silence is consent. The Foundation moves from approving to objecting. Two on-chain facts define this phase, and they are deliberate: a veto, once reported, is irreversible on-chain — it makes the stage permanently un-advanceable and the proposal expires, and there is no un-veto; and the veto takes effect without any reason on chain. The constitution's discipline therefore sits where it can reach: (i) the Foundation is expected to publish a reason for every veto, publicly and inline, and only for the enumerated categories — illegality or conflict with the Foundation's own governing instruments; material legal, regulatory, solvency, security, or operational risk to the Foundation; or a matter touching the Foundation's constitution, treasury transfers, intellectual property, token issuance, or key management; (ii) a veto that states no such reason, or opposes a proposal on grounds outside those categories, is a departure from the expectations in 2.4 — it is recorded as such, treated as evidence that Phase 3 should be accelerated, and is fair input to the 8.2 escalation ladder; it is not treated as void, because voiding a single proposal on-chain would pretend to a power this structure does not have; (iii) accordingly, the remedy for sustained veto abuse is the transition to Phase 3 — the mode parameter is DAO-controlled, and the gate can only shrink. At this phase the Foundation's vote is a brake, not a gate, and its brake list should be the shortest one consistent with its own legality.

6.3 Phase 3 — The gate is removed

On transition, the SPP stage configuration is updated so that no manual stand-in decision remains in the proposal path: passed proposals execute on governance schedule after the window closes (5.8). The Foundation continues to hold the treasury and IP, run compliance, maintain the software repository and governance infrastructure, and act as the protocol's legal entity; and it continues to be reachable by the levers this structure already knows: the community's 2.3(b) board-power, the 5.8 emergency regimes that by then should exist, and — always — the fork.

6.4 Why the roadmap is built this way

Approval mode exists because it is the only stage-1 configuration consistent with a community that has not yet demonstrated the capacity to absorb what its passed proposals do — and because its cost to the Foundation is bounded: case-by-case decisions on real proposals, not a standing veto quota. Veto mode is the strongest mode the Foundation holds in which the default for a proposal is to pass: a silent Foundation cannot slow the DAO; it can only block by individual, reasoned, published veto.

Removal exists because the point of the roadmap is that the DAO eventually needs no permission at all — when the gate is gone, what stands between the community and its own future is the law, the Foundation's own instruments (Article II), and the fork.

Article VII — Minimal Governance and the Fork

7.1 No sediment

Every proposal that creates a standing cost, a new privilege, or a new permission-gated exception must say why the lighter alternative fails. Minimal governance is the default: prefer the mechanism with the least standing overhead that achieves the goal.

7.2 Fork safety is a structural duty

If governance is captured, the community's sovereign response is to fork, and this Constitution treats that as legitimate. Therefore the Foundation role described in 2.4(d) exists to keep forking technically viable: the protocol's code, circuits, documentation, and verifier artifacts stay open source and published, and no action of the Foundation may make running the protocol infeasible for anyone but it. Open source is a floor, not a ceiling.

Article VIII — Disputes and Enforcement

8.1 Off-chain law

This Constitution is a governance framework only and is not intended to create legal rights, obligations, or liabilities for or among participants, Token Holders, the DAO, or the Foundation. Where a dispute between the DAO and the Foundation cannot be settled by the channels in 8.2, it is resolved under the instruments that actually bind the Foundation — its memorandum and articles, and its own internal procedures — with the community's standing remedy always available under 2.3(b).

8.2 The enforcement ladder

Working in order: (a) publish and challenge — contested declarations, vetoes, or resolutions are put on the forum for community review; (b) the vote — a Constitutional proposal can correct process and, where the phase allows, can set the terms of a transition; (c) the board — sustained, good-faith failure by the Foundation to act consistently with the expectations in 2.4 is the case for a replacement vote under its own governance documents; (d) the fork — the ultimate exit, always available. No participant may be punished, sanctioned, or chilled for any of (a)–(d).

Article IX — Amendment

9.1 Ordinary changes

Parameters of the governance system (quorum, majority, delays, submission thresholds, and the phase parameter) are changed by ordinary on-chain participation under Article V; that is not an amendment of this document.

9.2 Amendments to this document

This Constitution may be amended only by a proposal that (a) meets the supermajority and quorum prescribed for Constitutional changes (set on-chain), and (b) observes an extended cooling period after passage, longer than any ordinary delay, so that participants who disagree can exit.

9.3 Protection of the core

An amendment that would weaken Article II.2 (one treasury, no DAO asset claims), Article VI (the one-way roadmap), the ranking of the values in Article IV, or the opt-in rule of Article III, requires that the amendment's text say so explicitly — it may not be implied, bundled, or described in terms that avoid the word "weaken."

9.4 Asymmetric construction

Amendments are read as written; a doubt about the scope of a change resolves against the party that proposed it.

Article X — Interpretation and Effect

10.1 Terms

"The Protocol" means the deployed Interfold contracts, circuits, and their verifiers. "E3" is an Encrypted Execution Environment — one confidential-computation instance.

"Ciphernode" means a node operator serving in a protocol committee.

"SPP" (Staged Proposal Processor) means one of the two staged proposal processors on the DAO — the private process (stage-0 body: CRISP) and the public process (stage-0 body: TokenVoting) — of which, per 5.5(a), only these two hold execute permission on the DAO.

"Stage 0" is the stage in which the voting body votes.

"Stage 1" is the stage in which the Foundation gate operates; "the Foundation gate" means the single manual Foundation decision in Stage 1 of each SPP, which, depending on mode, is either an approval or a veto (6.1–6.3).

"CRISP" means the protocol's FHE secret-ballot / private-voting mechanism.

"DAO Resolution" means a proposal that has passed an on-chain vote and has been approved by the Board for implementation, as described in Article 2.3(a).

"Bootstrap" means the phased admin bootstrap (Aragon Admin plugin) described in 5.8.

"Voting power" has the meaning given in 5.2.

10.2 The specification outranks this document on technical questions

Where the protocol's public documentation defines behavior, ambiguity is resolved by the specification, then by the longer-established behavior. This Constitution is a governance document, not a technical specification: it never overrides cryptographic correctness.

10.3 Letter and spirit

The rules are applied by their letter in ordinary governance. When this Constitution itself is amended, the spirit of the values in Article IV guides interpretation, so that an amendment cannot smuggle in the opposite of a value it purports to preserve.

10.4 Severability

If any provision is unenforceable or invalid, that provision alone is removed and the rest continues to apply; the parties should promptly adopt an amendment that best preserves the intent of the removed provision.

10.5 Adoption

This Constitution takes effect on the date its canonical text is recorded at the URI on the metadata below and its keccak256 hash is mirrored in the governance contract (or, as initial deployment, recorded in the deployment record). Until the Phase 3 milestone of Article VI, this is a working constitution: it is expected to be amended, and each party should treat its terms as a living document under revision — but a living document that can only move in one direction.

Appendix A — Lineage and Key Design Choices

This draft synthesizes: the ENS constitution (binding articles with permissible/not-permissible examples; supermajority amendments); the Optimism Working Constitution (a Cayman foundation as a named steward with enumerated duties; interpretive principles including the right to fork); the ArbitrumDAO constitution (constitutional vs. non-constitutional proposals; layered exit delays; a narrowly-scoped, reportable, reversible emergency power; a bounded foundation role); Lido's framing of a DAO as the deliberate compromise between centralization and decentralization; clr.fund's core-properties discipline (credible neutrality, resistance to collusion, bribery, griefing, and sybil attacks); and Pocket Network's ranked principles with an explicit priority rule.

Design choices, given the Foundation's own governance structure:

1. The Foundation is recognized, not subordinated (Article II): it answers to its own instruments — which bind it to act in the best interests and on behalf of the DAO — and this Constitution reaches it only through (a) its role in implementing DAO Resolutions and publishing reasoned rejections, and (b) the community's retained power to replace the Board.
2. One treasury (Article 2.2): all protocol revenue flows to the Foundation — there is no DAO treasury to protect, split, or block. The DAO's financial power is the power to issue Instructions to the Foundation, and no vote creates a claim against Foundation assets.
3. The roadmap is one-way, and it is on-chain. (Article VI): approval mode (Phase 1) → veto mode (Phase 2, veto reported on-chain and irreversible, Foundation is expected to publish a reason within the enumerated categories, and an out-of-category or unexplained veto is treated as evidence that Phase 3 should be accelerated — not as a void, since the SPP cannot be overridden per-proposal) → gate removal (Phase 3). Forward-only transitions via Constitutional proposal; no step backward. The mechanism is the SPP stage-1 configuration (readable via getStages, changeable only by DAO via updateStages), so a transition is literally a parameter change, not a ceremony. This is the structural answer to the "governance theater" model: the gate can only shrink, and what shrinks it is a vote, not a promise.
4. Opt-in (Article III): protocol users do not opt in; only those who participate in governance (or receive a protocol grant) opt in, and revocably at that. This is the structural answer to the "DAO controls everything" mode.
5. A single transparent standard for voting (Article 5.3), set on-chain in the governance contracts, guards against a hidden second threshold multiplying influence.

Version 0.3 (draft). Concepts rooted in the
@theinterfold/the-interfold-governance implementation (Aragon
OSx, SPP-based staged processing, CRISP/TokenVoting bodies,
Foundation gate at stage 1).