Hey folks! I want to introduce Matt Luongo from Keep to you, if you don’t already know him. Matt’s the founder of Fold, which is an awesome app that you should try out! You can buy coffee with Bitcoin! (No Zcash in it yet https://twitter.com/fold_app/status/1071867160299884544) He’s also the founder of Keep, which has just announced this very interesting federated side-chain between Ethereum and Bitcoin named “TBTC”: https://tbtc.network
Keep has been contributing to Zcash in multiple ways. They worked on EIP-152 (BLAKE2b Compression Function F) in the new Ethereum upgrade and also before that EIP-1108 (alt_bn128), and recently they helped with the FlyClient ZIP, ZIP-221. Matt has been posting some ideas about Zcash governance on twitter, and I thought I would try to get him to post his ideas here.
As a company we’re very interested in devoting more resources to Zcash development, but the current fund structure and governance process have been discouraging. In particular, the incentive for a team like ours to join in development without an obvious source of funding or ramp-up is a problem. The foundation’s grant system is interesting, but grants are a difficult mechanism in an ecosystem with a steep learning curve, especially for established teams of builders- we need to be able to budget and work by quarter to ship significant work on the scale of teams like the ECC or Parity.
I’ve been watching the governance debate a bit from the sidelines, and think we have a perspective that might be interesting to the community- a team of outside developers that would like to work on Zcash. I’m digging through proposals right now to better educate myself on the state of play, but in the meantime, I’d love to hear everyone’s thoughts on how to bootstrap new developers in the space!
Welcome to the forum, @mhluongo! I look forward to hearing more of your perspective.
Meanwhile about this:
Many of the proposals funded in the past had timescale of half a year, so budgeting by quarter (with the proposal submitted sufficiently in advance) would be compatible with that. Especially if you set milestones at closer intervals, to make people comfortable with a long planned duration.
Are there other barrier to applying for Foundation grants?
Great question. I’m not sure what I see are barriers, necessarily, but rather a question of appropriateness – especially around scope and team focus.
The scope of what a dev team wants to build makes a huge impact on the fit with the grant process. For our team, the projects that are most interesting are a Zcash / Ethereum bridge, and a new Go Zcash client. Both are significant undertakings with maintenance, design, documentation, and support components, and both are well outside the scope of the largest grant I’ve seen on grants.zfnd.org.
For projects like these, there’s a time investment and project complexity that I can’t commit resources to as a business owner, unless I have reason to believe that project funding will continue after the roadmap is complete – that there will be maintenance and roadmap extensions, and that the now-specialized engineers working on these projects will be able to continue on similar work.
Compare to the ECC and Foundation, who have some reasonable ongoing expectations around budget- and can make sure Zcash is the ongoing core focus of their people.
A couple ways to reframe the issue.
Compare today’s grants, which are fixed-scope, to something that looks more like a fellowship. I’d expect funding the growth of developers in the space directly would increase the number and quality of grant proposals, as well as the volume of unpaid community work.
Another way to look at it is that the ECC and Foundation have an effective “monopoly” on reliable funding to focus on improving Zcash. Whether we believe that’s a problem depends on our beliefs around what makes a robust community.
The founder’s reward was a brilliant incentive-alignment mechanism at Zcash’s launch, and I think leaning into a similar mechanism for longer-term funding for teams or individuals is a complement to a grant program.
To be clear, I’m not in charge of product at Fold anymore, and I can’t speak to their interest. Will has taken over the helm and makes those calls.
But, from my time running Fold, the Bitcoin fee events made it very clear that we needed better L2 payment infrastructure rather than doing this all on L1. The Fold team is heavily invested in Lightning – I think a robust infrastructure for Zcash on Lightning or BOLT would be the way to go rather than wasting L1 resources on a short-term integration with long-term costs to chain state.
We had extensive public discussion of open-ended “fellowships” in previous iterations of the grant program, and there was a lot of push-back against that. A common sentiment was that there should be a concrete plan set out to justify the use of funds (though it may of course be adjusted later).
Open-ended funding makes sense when the recipient has a clear track-record, tasks that are inherently unpredictable, and a suitable incentive/governance structure to focus the funds on Zcash. There aren’t many such entities in the Zcash ecosystem… When they arise, I agree that it would be good for them to get more flexibility in the use of funds, whether by open-ended grants from the Foundation or by direct funding from (perhaps future revisions to) the Dev Fund structure. Conversely, some of the Dev Fund proposals strive to also put the funding of ECC and Zfnd under critical scrutiny and make it subject to ongoing approval (with the difficulty that we don’t have a suitable overarching governance entity to perform such review and approval).
In any case, the current Zfnd grants program is quite compatible with grants that are large and lengthy (even multiple years) but are well-specified with concrete plans and milestones.
Good teams don’t grow on trees, and Zcash is competing with other ecosystems for those teams’ attention.
I’m not familiar with all of the details (and would love to be educated), but I do know Parity recently built a new client- a big step toward a more resilient Zcash- but I haven’t heard about any further plans… and that’s a shame. Having the Foundation maintain that client makes sense to me from a governance perspective, but not having incentives to keep the team or the individual devs working on Zcash is unfortunate.
This is a really interesting conversation. It’s clear that a grant-based program would not offer a path for a team like Keep to become a central pillar of the Zcash community, the way Zfnd and ECC currently are. My question for you, Matt, is what would? What would make Keep decide to forego all competing offers from other cybercoins and devote yourselves to making Zcash better and better year after year?
Why would Keep ever forego working on other chains? From what I can tell, they are focused on working on tech that is applicable to all chains. Do you think that companies seeking to work on Zcash should only work on Zcash like the ECC or are you open to companies like Parity that work on other blockchains (ETH, ZEC, DOT, etc)?
Today, the primary option for teams that want to do serious work in the space and get paid reasonably well is to launch a new L1. This is a huge duplication of effort in my opinion – VCs are funding engineering projects that look more like research, further fragmenting the space, and often aren’t getting the results they want (lack of traction and differentiation).
Ongoing sources of funding means we can break this pattern, rallying teams to an existing chain rather than starting a new thing.
Focusing more on how we make decisions, what are we looking for?
Interesting work that aligns with our values (self-sovereignty, privacy as consent).
An opportunity to build expertise that’s difficult to replicate (deep tech).
Work with both longevity and a reasonable margin for professional engineering.
A broader scope than client work (we’re a product studio, we want to own a product)
Leverage. Are we the right team for the job? Can our work make a difference and move the market?
So exclusivity is a funny thing. We’re deeply interested in cross-chain interoperability, and Keep has a specific mission-driven product it’s shipping right now – tBTC. That work is positioned directly against exclusivity, which is sort of the anathema of interoperability.
Keep’s production studio, Thesis, has discussed “adopting” a client for a chain. That’s the sort of opportunity we’re looking for: ongoing product ownership, some amount of autonomy, and an opportunity to grow the ecosystem.
Personally, I don’t think companies working “for” a particular chain need to be exclusive to be incredibly valuable, especially if their other work is in an adjacent ecosystem – in fact, that’s a great way to save cash by having a team learn on another ecosystem’s dime. Still, one company funded by two “competing” chains with a broad scope seems like a conflict.
The way I see the ECC, their commitment to only work on Zcash is one of a few conditions that would put them in a “first among equals” type scenario in the case of a multi-company dev fund.