[Dead] Dev fund proposal: Full Node/Transactions Directed Dev Fund (was: opt-out mechanism for sharing block rewards by miners for dev fund)

One possible mechanism here would be to do something similar to how Ethereum does miner steering of parameters like gas limit. Basically there is a “current average” X, which is an average of the value chosen in the last 1024 blocks. And in each block, the miner chooses the value Y which is within 0.999X and 1.001X, something like that. The result is that a) miners can make a choice within some range for each block, and b) the range itself can drift over time according to those choices.
A decent description is here: https://hudsonjameson.com/2017-06-27-accounts-transactions-gas-ethereum/

1 Like

20% at the current exchange rate will not be enough for the salary of the fund and ECC after halving in 2020.

7100 a day now, there will be 3550, right?
20 * 3550/100 = 710 per day at 20% tax.
710 * 61 * 30 = $ 1,300,000 per month.
The fund is about 800 thousand and ECC is now 1,100,000 until the state is replenished, so you can round up to 2 million per month, you will need to spend only on salaries, without additional activities, right? And this at the current rate of about 33 percent.
Where am I mistaken?

I think you missed something, the part that it is stated that the funds should be 50% to ECC and 50% to Foundation. It’s not an add up.

Means if the dev fund results in $1,000,000, the ECC gets 500,000 and the Foundation gets 500,000.

Talking only about the Foundations Dev Fund guidance here and at least that is my understanding for “equal distribution”.

I said something else, I say that 20% may not be enough to continue, the fund does not need a price for a coin as they say, therefore there is no market effort, and they try to achieve adoption and adoption through high-quality technology, and users themselves must to do everything in order to join this system, China is apparently able to develop a client themselves who wants to use zcash.


Miners on their own, investors on their own and the community are also left to their own devices, the miners will leave further due to low liquidity and volumes, investors have already left, the community has split up, the fund is sharing money, the strategy is for development.


This is only required for mandatory dev fund proposal, not for opt-in based proposal.

Everyone needs to read this before they finalize their dev fund proposal:


I was under the assumption that Aug 31st is deadline for submitting draft ZIP. Just read:

@nathan-at-least @zooko @joshs looking forward to hear your answers to my questions in “How to hire ECC” thread.

I’m taking time to come up with a proposal based on new information being surfaced everyday.

1 Like

I responded in the thread. I hope it helps.


I have updated my proposal. Please take a look, Zcash community!

@daira and I made an initial review pass over this PreZIP. This is not a formal part of the proposal process (in particular, @daira is not acting in hir role as ZIP editor); this is just a joint comment between @daira and myself on the current state of the PreZIP.

Add a credit to Andrew Miller (as it appears this proposal incorporates writing by him).

This content should be in the Specification. The Abstract should only provide a summary of the ZIP; the ZIP should remain complete without the Abstract.

This is unclear as to what the intended consensus rules are. In particular, this could be interpreted as the miner having full control of DF%, as they are given control of the number of coins minted for the NTDDF, which is effectively DF%. It could also be interpreted as the miner’s and transactions’ signals being added together, effectively giving each “entity” partial control over the full DF%. The intent needs to be clarified for the ZIP draft; the full algorithm is not necessary now, but would need to be specified for the final ZIP.

If the intent is that transaction creators should have control over DF% (or some fraction of it), then this is also gameable, because miners could create a block containing some fraction of legitimate transactions (to collect fees) and fill enough of the rest of the block with fake transactions to bias the result to their desired DF% rather than what would result from the legitimate transactions. This is indistinguishable in the consensus rules from a block containing only legitimate transactions.

Replace this with “The maximum amount that the Zcash Foundation would receive under this proposal is 5% of block rewards, and the maximum amount that ECC would receive is 15% of block rewards.”

The content in this section should be part of the Specification. Quoting the ZIP guide:


Describe design constraints on, or goals for the solution – typically one paragraph for each constraint or goal. Again, don’t actually specify anything here; this section is primarily for use as a consistency check that what is specified meets the requirements.

There is significant difference in analysis and implementation work required between these two options. For example, there is more complexity in a transaction format change, and it requires more work from the ecosystem. (If there were other NU4 proposals that required a transaction format change, then this could be paired with them - but that analysis comes later.) If the ZIP is proposing a particular signaling mechanism, it should be clear whether it intends for only one of these (and if so, which), or both.


  • “Signalling via full node software flags” is under-specified; it does not indicate how the consensus rules could enforce this.
    • Are full nodes somehow influencing the miners’ blocks? This seems hard to achieve, and the strategy would need to be specified as part of the draft.
    • Are full nodes rejecting blocks that don’t satisfy their required DF% bounds?
      • If the flag specifies a minimum DF%, then miners will trend towards all blocks having max-DF%, otherwise they risk losing blocks entirely.
      • Similarly, if the flag instead specifies a maximum DF%, then miners will trend towards all blocks having zero-DF%.
      • If the full nodes specify a range, then you have both issues at once; the miners would have to guess the most likely range, and this would increase the orphan rate and the chance of chain forks.
  • Signalling via a transaction is gameable per above.

This reads like a specification. It should either be reformatted as an open issue, or moved into the Specification.


Consensus rules could make full nodes reject blocks where miner doesn’t set DF% based on signals in the transactions. You’re right, Miners could gamify this with fake transactions if the transaction fees are low and also not mine legitimate transactions if they can get around algorithm to select DF%. This could make network unusable and mining non-economical because of increased ZEC volatility.

Fair point. I’ve not mentioned the algorithm that I was thinking to mitigate this. Will update the proposal once I get it right.

Can you expand more on why that is hard to achieve. This could help me understand the complexity and also how consensus rules can be forced.
One option could be full nodes validate the blocks based on signal-ing provided by transactions => Reject the block if the median of DF% < actual DF% set by winning miner in the block.

1 Like

Meta question:

@sonya @joshs does this proposal if accepted by community make Zcash a security?

1 Like

Disclaimer: I am not a lawyer.

There were concerns about the regulatory implications of a dev fund with no opt out being granted to a for-profit company. I can’t elaborate on the details of those concerns, since I don’t have the necessary expertise.

Don’t worry about that for now :slight_smile: As I’ve told others, we’re consult our lawyers as needed before the feature selection deadline.

1 Like

No one can say with certainty about any of these proposals. Even if the community believes something is not, the SEC could chose to pursue it, which could be very expensive and cause damage regardless.

I don’t believe Sonya is correct based upon our consultations. Nonprofit and for-profit have no bearing. Direct funding (regardless of who receives it), if I understand your proposal correctly, would likely result in this type of model being presented to https://www.sec.gov/finhub for feedback.


I’m concerned about this. Manipulating transaction-weighted voting by injecting artificial transactions would be very easy, whether by miners (essentially for free, as long as blocks aren’t full) or by others (as long as transaction fees are low, and specifically a fixed 0.0001 ZEC for shielded transaction).


Consensus rules could make full nodes reject blocks where miner doesn’t set DF% based on signals in the transactions

If the consensus rules say that miners must set the DF% based on the transaction signals (othewise their blocks will be rejected), then it’s misleading to say that

miners can also “opt out” by minting a lower number of coins for the NTDDF, or none at all.


Maybe a bit picky… its the pools that include txns & mint coinbase txns, not the miners

1 Like

Do you have any suggestions, love to hear if there is some quirky way to avoid this issue.

1 Like

I’m pulling off this proposal. There are much better proposals out there now. Example: