Proper QF—from on-paper to onchain

Ethereum exists to be a trustless settlement and social coordination layer. At least that's its raison d'être that we subscribe to at Octant.

Understandably, there's been a push for years for Ethereum-dapps to be more usable and appeal to a less technical, ideological audience. But the resulting "pragmatic tradeoffs" (trusted admins, offchain calculations, etc) have all too often shown an uncanny ability to stick around.

If no one takes the hard path, we’ll lose the properties that make Ethereum worth using in the first place. That's part of the story behind the recent Ethereum Foundation CROPS manifesto:

CR — Censorship Resistant

O — Open source

P — Private

S — Secure

But the other part of the story for going all-in on CROPS now is the development of tools that let us have our cake and eat it too.

Trustless and accessible

In our last post we laid out the proper math for capital-constrained QF (aka pQF). The equations are tricky and, relatedly, expensive to run on Ethereum mainnet. Mainnet scalability has come a long way, but updating a QF tally with each vote cast is still too expensive to ask of every participant. Introducing an unchecked admin to run the round calculation offchain is a CROPS-non-starter.

Enter Octant's Zero-Knowledge (ZK) Vote Coprocessor and our user-friendly, CROPS-aligned implementation of quadratic funding (QF) running in Epoch 12.

The other ZK unlock

A zero-knowledge proof (ZKP) is a cryptographic method that allows a party to prove a specific statement is true, without revealing any underlying information used to establish that truth. The verifiable "truth" can take on a wide variety of forms including that you completed a series of computations correctly.

Privacy is a natural application, but not the only one. The type of ZKPs that we're interested in have another useful property: they’re cheaper to verify than redoing the raw computation.

This attribute is a huge scalability unlock. It's the key to how zk-based Layer 2s work and is extensible to our challenge to run a quadratic funding round. Using a ZKP, we can trustlessly tally QF round results, prove the result onchain cheaply, and enable broad, low-gas participation without compromise.

Let's walk through how it works.

A round, beginning to end

1. The round opens. The round sponsor (in this case Octant) creates the round onchain. The projects, matching pool, and duration are fixed in the round smart contracts. In Epoch 12, the matching pool is funded from Golem Foundation ETH staking yield.
2. Voters sign up. A voter completes a transaction to enter the round. There are two participation paths for this epoch:

• GLM lockers can use WETH rewards they've accumulated from locking GLM. They send some or all of their rewards as a voting deposit. Lockers can only do this process once per round. Their total direct contributions are fixed after this step.
• Non-lockers can use WETH directly from their wallet. This is the first time an Octant epoch has included this participation option. The motivation is to broaden the epoch's preference aggregation reach while supporting GLM as the source of the matching pool. The mechanism will work by splitting half of the WETH into a voting deposit (which will earn QF matching). The other half is used to buy GLM at market and burn it. As long as the matching multiplier on the donated half is at least 2x, the non-locker is rational to prefer this method over a plain direct donation.
• 3. Voting. Voters sign EIP-712 ballots and send them to Octant's sequencer. Each signed ballot is just data; no transaction, no gas. Voters can change their mind by just signing a new ballot.

1. The round closes. When the round timer runs out, the sequencer takes every signed ballot it has collected and posts them to Ethereum as a blob—the same in-protocol data type that L2s write to. Blobs are public, which allows us to make the rest of the system verifiable.
2. The tally. A separate offchain service called the coprocessor watches for closed rounds, reads the blob, and feeds the ballots into a zero-knowledge proof program built on SP1 (Succinct Labs' general-purpose zkVM). Inside the program, the system does what an honest round administrator would do by hand: it verifies every signature, removes duplicate votes by nonce, enforces each voter's per-round budget, and computes the pQF allocation across all projects.
3. The proof. Once the SP1 program finishes, the Succinct Network produces a Groth16 proof—a few-hundred-byte cryptographic receipt that says "given these specific ballots, this is the resulting tally." Anyone can verify this without rerunning the underlying computation.
4. Verification. The coprocessor submits the proof to a TallyVerifier contract. It checks it against a verifying key for what computation should have run. If anything is off—bad inputs, modified program logic, or a tampered tally—the contract reverts. If the proof holds, the round results are permanently recorded in the VoteRegistry contract.
5. Distribution. With the tally settled onchain, two PaymentSplitter contracts are deployed for the round—one for direct contributions, one for the matching pool—and each project's allocation becomes claimable directly without any further action by Octant or the sequencer.

Five of the eight steps (1, 2, 4, 7, and 8) happen onchain, and three (3, 5, and 6) happen offchain. But every offchain step lands an onchain artifact: a signed ballot only counts once it's in a public blob, and a blob only counts once it produces a proof the contract accepts. The offchain components do some heavy lifting computationally while the onchain components support their credibility.

What's in the proof vs in the future?

The proof attests to a specific bundle of facts about the tally: that every signature was checked against the corresponding voter, that duplicate votes were removed by nonce, that no voter exceeded their per-round budget, and that the pQF math itself—both the QF totals and the α-scaled allocation—was carried out as specified. It also commits to both the voter set established at signup and the recorded sequence of blobs, so neither the voters nor their ballots can be quietly swapped between flush and proof.

Voter addresses and ballot choices live in the public blob, not in the proof. So this isn't a private voting system (yet).

We also rely on an RPC to provide the proper data to our coprocessor (bad data would result in an invalid proof rather than sneaking into the published results). The Octant-run sequencer could omit ballots, but not forge them.

We have work to do on privacy and being fully trustless, but we’re committed to doing it. We're excited to roll out this next step towards an Ethereum and CROPS future.

Epoch 12 is coming

We have an amazing cohort of open-source projects and builders represented in Epoch 12. You still have time to lock GLM and start accruing rewards to vote with. You don't want to miss this!

Lock GLM