Dev Fund Proposal: No dev dund, let FR expire, market decides

Build trust

  • Keep original agreement with community

Flexible ( no blockchain),

  • No consensus rules
    • No bug in new code for voting / treasury
  • No hard coding
    • No address security and legal problems
    • No amount / percentage problem with exchange rate

Professional,

  • Use any governance method,
    • First past post, majority, electoral college
    • Whatever community wants
  • Real world
    • Contracts can help funding and delivery
    • Best practice from public request-for-proposals

Freedom to opt-in

  • Miners fund projects
    • Pool can ask individual miners
  • Ecosystem fund projects
    • Business talk to customers and users
    • Other investment source
      • Not just miners / reward

Market of ideas,

  • Devs and Projects compete
    • No hand out, no bail out
  • Encourage independents
    • No special vendor / recipient
  • Align projects to community needs

Summary,

  • Decentralize.
  • No gatekeeper
  • No permanent tax
  • Free market decide
11 Likes

Thanks for posting this proposal and the rationale for it.

It seems similar to [ZIP 1001] Final: ZIP proposal Keep the block distribution as initally defined. 90% to miners .

Would both @jj6 and @mistfpga agree that the two proposals are the same, or are there notable differences?

1 Like

To be honest im not 100% sure.

They are similar in some aspects, this is more comprehensive though and mine is meant to be simpler. I haven’t written my proposal up properly yet.

a brief glance over this and there seems to be a few key differences.

  • Mine does not cover governance. (by design) v “Use any governance model” similar but not the same.

  • jj6’s zip would allow for this to be changed at any point in the future. Mine does not. although it does not explicitly prevent it if and only if it does not mess with the total coin cap, emission curve or block distribution past what has already been agreed via the initial opt-in I made when I decided to back zcash. no voting. it is more a reaffirmation of the original commitment.

  • Mine needs protocol level changes for donation addresses (a MUST) v No hard coding.

  • Mine explicitly calls for transaction fee donations over block distribution donations. (although I am flexible on this, I would need a strong argument to change my mind.)

So the spirit of the zip are very similar the but the end results are somewhat different (not by much, but on important points to me). I agree with a lot of @jj6’s post and hopefully we can help each other.

I think we will be submitting very similar zips. mine will be much smaller in scope though, and a bit more specific with opt-in / opt-out that I got from another proposal. There should be donate, burn, greed options. but I have not had time to update my zip yet. I am aiming for a deadline of 31st july, but I would like to get it done for a first round of feedback by 21st. I will not be online a lot in august.

Hope this helps.

2 Likes

Hello, could you please follow my request on Proposal authors, please read: Help making ZIPs ?

That will help me and ZIP editors know which forum proposals we can help turn into ZIPs. If I understand this proposal correctly, it advocates not changing the protocol in any way related to a Dev Fund. This is still a proposal that should be made into a ZIP as a “community resolution”.

Thanks again for your contribution!

1 Like

I have made major updated my proposal I think it fits inline a lot more with what @jj6 is suggesting.

However I have had no contact with them and no idea how to contact them.

Hopefully @jj6 will check back in at some point to let me know.

1 Like

If jj6 doesn’t show up again, I think we can safely assume that they don’t want to participate further. Since you’re stewarding basically the same idea as a ZIP, that’s probably fine.

1 Like

Edit - Moved comment to megathread