Distribution Mechanism Proposal

The following is co-authored by me and @daira.

Last year, the community clearly advocated for a change in funding and governance. The direct funding model was retired in November 2024, and development funds have been channeled into a lockbox while the community decides how it wishes to govern funds.

Three proposals have surfaced so far, including the zBloc from me, Loan Directed Retroactive Grants from Kris (which could be coupled with zBloc), and a Dev Fund Proposal from Milton. Each proposal envisions an on-chain k of n, multisig for distribution.

We will be creating a ZIP for the implementation of the zBloc so that the community can thoroughly vet the idea.

We also propose that any remaining specification (e.g. finalizing ZIP 312) and library implementation work needed to support the use of FROST should be completed well in time for the NU following what is currently defined as NU7, while the community determines which proposal or variant it wishes.

This will allow us to implement a solution and reduce the risk of further slippage in the implementation of a distribution mechanism while the community works through the details of one of these proposals or variants.

FROST on Zcash will also allow for other use cases, including multi-sig for custodians, Zashi Vault, and other self-custody wallets, and social key recovery.

Given that the Zcash Foundation developed FROST, we believe it would be best equipped to complete this work. If it does not have the capacity to do so, other organizations may want to pursue it. Funding could come from ZCG or a retroactive grant upon completion of the implementation, along with a new governance and distribution mechanism. ECC will take on any user interface and key management needed to support FROST in the Zashi and Zallet wallets.

We look forward to hearing back from the Zcash Foundation or others who may be interested and ready to support them. If no one steps up, ECC will take this on as soon as our schedule allows.

15 Likes

Just to clarify the role of FROST here:

We expect that the signatures used directly to authorize governance changes will need to be attributable, i.e. it should be publically visible how every party to zBloc has voted. This does not require (and probably cannot use) FROST for the overall multisignature.

Instead, FROST would be used for the signatures of each party to zBloc, to mitigate the risk of key compromise or loss within a given party. This makes usable FROST a blocker (since at least some and probably all zBloc parties will want to use it), but the mechanism itself does not depend on any details of FROST.

6 Likes

FROST is done. The work we’re currently doing on the FROST server (which is also pretty close to done) is the way we believe will be most practical for deploying FROST in the short term, but it is not the only way.

We already support generating FROST-signed transactions with Ywallet transaction plans. It shouldn’t be hard to migrate it to support PCZTs to integrate with the ECC stack.

ZIP-312 is also practically done, it’s just missing describing the integration with PCZTs (which requires the specification of PCZTs) and it has some additional content which is currently waiting for review/feedback.

In short, I don’t think FROST is blocking anything, and the few things missing will certainly be done before NU8. (“Usable FROST” is very ill-defined though. If that means FROST usable by some polished GUI tool, then yes, more work is needed. But for governance, I think the our CLI tool should be enough)

I also think FROST could also be used for the overall multisig. We already did a proof-of-concept of “Nested FROST” and it works, if people want to deploy that, we can clean up the proof-of-concept and integrate it to the library. I will double-check but I believe attribution can be achieved by simply publishing the signature shares and the participant’s verifying key shares. (The trickier part is proving a “no” vote since it’s basically the absence of a signature share, but this could be solved out-of-protocol and wouldn’t preclude using FROST)

9 Likes

:white_check_mark: for this

1 Like

The work you poured into it is admirable but if this is still standing, as Zcash holder, I am very worried. What happens if one of those components disappear? (i.e. ZF) What happens if a few members belong to more than one entity? It seems pretty complicated and fragile. Maybe I am missing the elegance of it.

2 Likes

Good question. The others can vote another entity out if it is defunct or behaving in a way that a super majority believes is not in the best interest of the project. It also allows for new constituent groups to enter. It’s highly adaptable.

Yes, a community member can participate in multiple groups. For example, core devs might work at ECC, participate as a collective constituency, and vote their tokens separately.

But this isn’t a one person, one vote model. It’s a public vote as a constituency. For example, a coin holder that works at ECC might chose to vote their tokens differently than the organization they work for.

2 Likes

Thank you for your answer.
I just would like to point out that a core engineer working for the ECC will have a massive weight because it will appear in at least 3 pools, and in 2 of them his/her weight can be relevant.

1 Like