Dev Fund: plans for top two proposal runoff

[iShogi]

Would be great to see new ZEC use cases via an Avalanche L1 bridge. Can add LayerZero standard and have ZEC across all of defi. Imagining new types of dapps and services built on top of something like this

[zancas]

Without sufficient time to transition the persons to-be-incentivized might well be too busy earning a living outside the zcash ecosystem to be sensitive to any incentives inside that system.

To put it another way, abstractions about cleaner incentive models look nice on paper, the reality is the expertise we’ve been building over the last few years at ZingoLabs, will likely simply have to disband if the ZCG funding pool is vaporized, without a transition.

[zancas]

Anyone who’s not watching Free2ZTV every Monday, should rearrange their schedule. It’s a great show!

[hanh]

@zancas

I miscalculated optimistically in several different dimensions when attempting to predict the time to ZIP317 implementation. Not only did I miscalculate up front, but I continued to be overly optimistic until the day before we actually released. This is important information for the community to consider.

I’m curious to understand why ZIP-317 took 1 year to implement. It’s a critical part of any wallet since the network rejects transactions when fees are incorrect. Could you share some insight into its development?

Everything else you mention is optional IMO, so a price tag of 600 000 USD seems excessive.

[Autotunafish]

Support for 317 transaction proposals wasn’t pushed to the ECC mobile SDK until this past March. I assume that was the blocking issue on dependent wallets.

[hanh]

I use librustzcash too and zip 317 was released in September 2023.

[joshs]

The ECC ZAC, ZecHub, Brazil and ZURE runoff polls are out. I believe the Spanish poll will be out before the end of the day.

@Dodger, are you planning to poll ZCAP?

[edit: Brazil has gone out]

[Autotunafish]

I mean this.

Expose APIs for working with transaction proposals

I just assume that wallets, other than yours, depended on this framework and added functionality (the Android as well but didn’t check there).

[hanh]

Well, let’s let them answer.
However the phrasing of the post seems to indicate a considerable amount of work on behalf of the Zingo team.
Waiting for the code to land upstream isn’t really the same thing.
I think they have their own implementation.

[dismad]

@zancas

the reality is the expertise we’ve been building over the last few years at ZingoLabs, will likely simply have to disband if the ZCG funding pool is vaporized

Can you expand on why the ZingoLabs team can’t compete with everyone else on the new mechanism that will be built?

@hanh

I’m curious to understand why ZIP-317 took 1 year to implement. It’s a critical part of any wallet since the network rejects transactions when fees are incorrect. Could you share some insight into its development?

I’d also like a response to this? Instead of joining forces, one dev gets it done quickly and the others don’t. Help me understand, as I want all teams to succeed.

[gordonesTV]

@peacemonger

For example: Usually, a company needs to allocate about 20% of its budget to marketing, more if it needs to be aggressive and win new market share. A project cannot take off without a solid marketing budget and a coherent GTM strategy. In an ideal world, I would like to see the current ZCG and its budget split up into two organizations:
• 25% to a ZCG-like org, responsible for community- and marketing-focused grants
• 75% to a ZCG-like org that is solely focused on technology grants

This is a great proposal!

You’ve been talking in this thread about the two options we’ll be choosing in this latest round, and many have laid out excellent advantages and disadvantages of both.

But this Dev Fund thing is just a first step of the many changes many of us are proposing within Zcash. For example, this proposal from @peacemonger.

I think we should propose changes within the ZCG, its structure and election. There should be changes within the ZCAP, and that we define if it is going to be a “Super ZCAP Caucus” or whatever we want to call it.

There must be changes within the ZF, just as at the end of last year there were changes within the ECC with the departure of @zooko

Zcash adoption needs to be further boosted, at retail, at small and medium businesses and entrepreneurs, and that will be achieved with community support. There is a big gap left (and that must be filled soon) after the suspension of the Global Ambassador Program, with a different name, structure and strategy, but that undoubtedly aims at the detail, the day-to-day life of the common user, which engineers and developers do not reach.

Anyway, as @joshs said in his weekly message: the tide comes and goes, and we must continue to tweak and optimize here. We are far from perfect, but at least we are trying.

[str4d]

Support for generating transactions with ZIP 317 fees was implemented in the zcash_client_backend Rust library (and thus available for its direct users to deploy), and internally available in the mobile SDKs, in November 2022. However, there was no way at that time to expose to the mobile SDK user what the fee was going to be before creating the transaction, and so at the time it was left internally disabled (using fixed fees instead).

The PR that included the commit you linked to is the one where we added mobile SDK APIs for working with “transaction proposals”: instead of having a single “send funds” API, there is now a proposeTransfer API that returns a transaction proposal (including fee) that can be reviewed by the user, and then a createProposedTransaction API that creates and sends the actual transaction(s). The initial Rust APIs for this were merged into zcash_client_backend in February 2023; we landed the mobile SDK PRs exposing those APIs in March this year, which enabled us to switch on ZIP 317 fee selection in the mobile SDKs.

[zancas]

Great questions, let’s discuss it in the our proposal thread when, and if, it exists.

[zancas]

@dismad

Can you expand on why the ZingoLabs team can’t compete with everyone else on the new mechanism that will be built?

There seems to be some miscommunication here.

We’re very happy to compete for funds once the lock-box mechanism exists.

It doesn’t exist right now.

@hanh

I’m curious to understand why ZIP-317 took 1 year to implement. It’s a critical part of any wallet since the network rejects transactions when fees are incorrect. Could you share some insight into its development?

TL;DR It was low priority.

We weren’t focused on ZIP317 for most of that time.
We had a workaround, and other priorities (faster sync, background sync, address books, Nym integration, zcashd deprecation, contribs to librustzcash, expanded test, basic mode, ValueTransfers etc.).

Because of our workaround our transactions weren’t being rejected.
Moreover, the zcash_client_backend code that we are using is fairly volatile, so locking in to it pre-maturely causes us to incur upgrade costs.

We can dive into details, but I don’t think this is the thread for it.

[zancas]

It’d be super cool if @nuttycom completely won this debate by implementing a POC lock-box. I would love to lose to that!

[dismad]

@zancas

There seems to be some miscommunication here.

We’re very happy to compete for funds once the lock-box mechanism exists.

It doesn’t exist right now.

So no one having hard coded funds encourages cooperation to get this complete then? Perhaps I’m misguided in my estimation.

[zancas]

I don’t think “encourages cooperation” is accurate.

An abrupt complete transition to the lockbox scheme implies a significant and unplanned reallocation of various efforts.

It would mandate that the lockbox implementation is the single highest priority to which all other priorities must subordinate.

Are you comfortable asserting that priority? What would you base such a strong assertion on?

There are a few other priorities that I’d like to see progress toward:

• DEX
• PoS
• Nym
• Community/Education
• ZSAs
• better mobile apps
• hardware wallets

I don’t really know exactly how those should be balanced and prioritized, but I trust the discretion of various participants to often be not-incorrect.

Consider the outcome once the lockbox is established.

The funding pool, so-managed, will be custodied by trusted community members. These community members will be delegated this responsibility through some transparent and hopefully-community-representative process. Once these deputized community members are in place they will be charged with evaluating and selecting grant submissions from the community. They’ll be held accountable for their effectiveness… they’ll… basically be a new iteration of the ZCG.

The ZCG is already the mechanism we have that has these desireable properties. Should we needlessly disrupt, and potentially irreparably damage their current operations… so that we can upgrade the platform they work on (in important ways) so that they can then begin to operate again?

That’s how I see migrating the 20% dev fund to a lockbox ASAP.

Why don’t we instead, transition with intentionality and to the new mode of operation without disruption? The hybrid model allocates MOST of the dev fund into a lock box. This seems likely to be sufficient incentive for significant focused effort.

[dismad]

@zancas

An abrupt complete transition to the lockbox scheme implies a significant and unplanned reallocation of various efforts.

This is how a large percentage of the community voted, you can’t ignore that.

@zancas

It would mandate that the lockbox implementation is the single highest priority to which all other priorities must subordinate.

Are you comfortable asserting that priority? What would you base such a strong assertion on?

There are a few other priorities that I’d like to see progress toward:

• DEX
• PoS
• Nym
• Community/Education
• ZSAs
• better mobile apps
• hardware wallets

I don’t really know exactly how those should be balanced and prioritized, but I trust the discretion of various participants to often be not-incorrect.

IMHO, I think you’re tackling too much and spread too thin. Pick three and get those complete. Then move down the list.

@zancas

They’ll be held accountable for their effectiveness… they’ll… basically be a new iteration of the ZCG.

The ZCG is already the mechanism we have that has these desireable properties.

I think its clear to large portion of the community that ZCG isn’t working so well for many large grants. The status quo isn’t working. How the new system will look, work, and feel, should be a high priority for you, for me, and for all of us. If it isnt, you should have voted to send all funds to the miners.

Please keep in mind I appreciate your efforts and I don’t mean to ruffle feathers, I’m simply speaking my mind.

[zancas]

@dismad

IMHO, I think you’re tackling too much and spread too thin. Pick three and get those complete. Then move down the list.

I don’t think ZingoLabs is going to produce all of the above, I think Zcash Grant Recipients are contributing directly or indirectly to all of the above.

[dismad]

@zancas

I think Zcash Grant Recipients are contributing directly or indirectly to all of the above.

Great, let them compete for their fair share of the lockbox. Level playing field. Retroactive funding works.