Announcing Zcash Labs - A Zcash Go To Market Company

Today we announce Zcash Labs, an independent organization focused on solving technical integration challenges for businesses and institutions interested in Zcash. We also help new projects get started through initial funding and support.

Our initial focus is Zcash blockchain integration and support for businesses and institutions, operating independent infrastructure services, and supporting new projects that expand practical Zcash use.

Technical Integrations

We help businesses and institutions integrate Zcash into their offerings and day-to-day operations.

Our process starts by understanding how you want to use Zcash, then identifying the best available technical solution. Where needed, we build custom solutions to solve the integration challenges in front of you.

Operating Zcash Infrastructure

We operate a Shielded Vote Validator and are building privacy-preserving Zcash infrastructure, including lightwalletd and full-node instances. We also plan to make new RPC services available as that work matures.

These services are intended to give users and integrators additional, independent options for accessing the network.

Supporting Adoption Focus Projects

We support promising projects that expand Zcash use with initial grants, technical support, and consulting.

We welcome projects that broaden Zcash use and may offer grants, technical support, or consulting where they are a good fit.

Supported Projects

We have already been helping independent Zcash-focused teams move from ideation to launched products, including initial grants to help get their work off the ground.

And we are proud to announce that one of the teams is already ready, launched, and available.

ZCASHTOCASH

zcashtocash makes it easier to convert Zcash to fiat currency. It uses Peer to facilitate peer-to-peer conversions, with enclaves releasing ZEC only after the fiat payment has been verified.

The service connects Zcash with six fiat-payment apps: Venmo, Revolut, Cash App, Chime, Monzo, and Zelle. The team estimates that this makes the service available in more than 100 geographies, and it is actively working to add further apps and locations.

We are pleased to have supported the team’s launch and look forward to supporting its continued growth.

Pioneering a Coinholder Grants Model

Zcash Labs is not a conventional consulting firm. We are pioneering a market-driven funding model built around the coinholder retroactive-grants process. We cover the upfront costs of integrations, new projects, and infrastructure ourselves. We pay supported teams directly and fund the work before seeking to be repaid through the coinholder grants process.

During each retroactive-grants period, we plan to seek reimbursement from coinholders, plus a 20% markup to cover the financial risk we take and our operating costs. Whether to fund a request remains the coinholders’ decision.

This creates a market-driven approach to project funding: we use our judgment about what coinholders will value when deciding which costs to cover, and we take the risk that they may decide not to reimburse those costs. If we exercise poor judgment, we bear the financial consequences.

By covering costs upfront, this model reduces funding uncertainty for projects that might otherwise wait for a grant decision before beginning work. We also aim to pave the way for others to replicate the model and earn incentives in a way that is closely aligned with ZEC holders.

Our first requests in this round are relatively small. We will view their approval as a signal that coinholders support the model and encourage us to take larger bets in the future.

What is next?

We have already been operating for some time and supporting teams such as zcashtocash. We also have more projects and integrations to announce. Stay tuned on Twitter and follow our blog, where we will share these announcements in the coming weeks.

If you are a business or institution looking to explore Zcash blockchain integration, or you are a new project expanding Zcash use, reach out to us at hello@zcashlabs.org.

Follow Zcash Labs

21 Likes

Congratulations on the launch!

Underwriting grants is a really interesting experiment. You’re taking on a pretty big financial risk if a project is funded, then months later coinholders reject your reimbursement. I think your markup is totally justified given this.

Ultimately most builders are bad at finance, and the paperwork around grant applications can really be a drag on productivity.

Giving developers the confidence to build today with funding, without the anxiety of “will coinholders reimburse me a few months from now?” is a really empowering new option.

I’m all about more funding from more places for Zcash! Kudos for launching this I wish you the best.

It could be helpful for you to publish a “Request for Zcash Startups” to give builders guidance on what types of projects you’re wanting to proactively fund.

Do you have a target check size per project that builders should be within for consideration for this initial launch?

1 Like

Congratulations! I think the fact that more teams are appearing is good for Zcash; there will be time to measure the impact later. I like the idea of ​​boosting teams and offering infrastructure like RPC and more. I also like the creative approach to leveraging funds controlled by coin holders; I’m still analyzing and reflecting on that.

I have a question about the financing model. When you finance a project upfront, do you (Zcash Labs) receive an equity stake in the business you’re financing, similar to a VC model?

1 Like

Thanks!

The role ends up being part technical project manager, part administrator, part financial underwriting (VC style). It is common for project managers to charge 10-20% in the consulting market, or even upwards of 45% with project guarantees. With the financial risk being taken on, I think 20% is fair, and I think sets a good baseline for others to follow.

Will certainly expand on the requests we want to fund; a rough outline is up on our Funding Model page.

So far we have done 5-10 ZEC grants for startups, and are eying larger amounts for strategic integrations. If the model proves out this round, I will view that as a signal to take larger financial risks.

1 Like

No equity stakes so far, we have contracted teams to build Zcash integrations so it is a revenue tied to deliverables for them. No plans to take equity as ZEC is the unifying alignment.

I think if the company ever took an equity stake it would not be submitted for a grant, though the company invested in may have costs worthy of a grant. Regardless of the grant, we would commit to disclosure the ownership structure and relationships involved.

2 Likes

Good to see more solutions for real world problems!!

2 Likes

Congrats on the launch! Awesome (:

1 Like

I know I’m late to the party but… huge!! Congrats and keen to see more on Zcash Labs

3 Likes

I have said it before - I have a bias towards retroactive grants.
I’m a born skeptic when people ask for large sums of free money up-front.

And like you Tom, I prefer it when someone has skin in the game.

So I will say clearly: I like what Zcash Labs is trying here.

The zcashto.cash experiment is simple enough.

Zcash Labs put up USD 5,000 of its own money, helped get the project built, and is now asking coinholders for USD 6,000 via the retro grants program - its cost plus 20% for its time and financial risk. That is explicitly how Zcash Labs describes the business model.

Tom also made the experiment clear:
“We will consider any [coinholder] YES votes to be implicit support of this type of model…”

And an outright NO is to be interpreted as opposition to the model rather than zcashto.cash itself.

Fair enough.

But now comes an interesting bit.

Before coinholders have even decided whether to reimburse that first USD 6,000 experiment, Zcash Labs has put USD 80,000 behind Ledger and the Ironwood integration.

The Ledger agreement was announced on September 15.
Q3 retroactive-grant voting did not begin until September 17, and runs until September 29.

That is quite literally putting your money where your mouth is.

Tom is not waiting to find out whether coinholders approve his first small experiment before risking substantially more capital on the model.

Your capital, your profit, or… loss.

3 Likes

The Ledger case seems to me a better demonstration of what Zcash Labs might become than the zcashto.cash funding.

Ledger already has an approved USD 300,000 ZCG grant. That grant has one milestone, with no payment until all deliverables have been completed and reviewed and approved by ZCG.

In other words, Ledger has been carrying the working-capital burden itself. Some may say that Ledger is charging a lot, but like it or not, Ledger hardware wallet users need full, maintained, Zcash shielded support. And the ZCG milestone model ensures delivery before payment.

But.. then came the unexpected. Ironwood.
So, Zcash Labs has stepped in with USD 80,000 for that additional Ironwood work.

Ledger is careful to separate the two arrangements. Zcash Labs has no authority over Grant #152. It cannot change it, approve it or direct it. ZCG retains that authority.

Ledger also says that whatever Zcash Labs chooses to do later through Zcash community processes regarding its sponsorship is Zcash Labs’ own business, and Ledger is not a party to it.

So what does that mean in plain English?

My reading, when you put that language next to Zcash Labs’ published funding model, is this:

  1. Zcash Labs pays Ledger now.
  2. Ledger gets certainty and working capital for the additional Ironwood work now, rather than waiting for the eventual USD 300,000 ZCG single milestone payment.
  3. Then, if Zcash Labs follows the model it has just publicly described, Zcash Labs can go to coinholders and ask to be reimbursed through the Coinholder-Directed Retroactive Grants Program - presumably for its cost plus its stated 20% markup.

If the cost basis is USD 80,000, that would mean a future request of USD 96,000 if the same 20% model is used.

That last part has not been announced as a Ledger retroactive grant application yet. I’m translating the published Zcash Labs model into what it would mean here.

And importantly: if coinholders eventually say NO, Ledger has still been paid.

Zcash Labs takes the loss.

It is not Ledger getting USD 80,000 early from ZCG.

It is Ledger getting USD 80,000 early from a private underwriter, who then takes the risk that coinholders may or may not later agree that the outcome was worth reimbursing.

Money where your mouth is.

Skin in the game.

I like it.

4 Likes

I thought more about a concern raised elsewhere: Zcash Labs or other grant applicants voting on their own retroactive grants.

Zcash Labs has disclosed that it holds ZEC and participates in ZEC voting. It has not disclosed how much.

As a private venture, I think that is reasonable. This is Zcash. I don’t think somebody should have to publish their personal or corporate holdings simply because they participate in governance. Apart from protecting your privacy, who wants to advertise large crypto balances and make themselves a future wrench-attack target?

But that creates a genuine trade-off.

If voting is shielded, how do we know whether an applicant voted for their own application?

We don’t.

Should we be concerned?

ZIP 1016 explicitly says that no organisation or individual faces restrictions on voting their coins. That differs sharply from ZIP 1015, where a ZCG committee member with a financial interest in a proposal must recuse themselves. They leave the discussion and cannot take part in the committee vote on that grant.

People raised this at the time of ZIP 1016’s introduction too. A funded organisation could build a large ZEC position, use it to influence future votes, and keep seeking more funding. Large holders could also dominate outcomes or vote with other financial interests in play.

So self-voting in coinholder grants is not a loophole. The coinholder voting model accepts it.

That means the system cannot depend on applicants voluntarily restraining themselves.

Assume applicants advocate for their grants and vote their own coins.
Assume large holders may vote strategically.
Assume wealth concentration creates concentrated signalling power.
Assume reputation creates influence.

Then constrain those incentives with things we can actually verify.

That is why retroactivity matters.

Coinholder-Directed Retroactive Grants are not:
“Give somebody USD 1 million and hope they deliver.”

They are supposed to be:
fund → completed work → public evidence and cost scrutiny → review → vote → possible reimbursement

The work should already exist. The evidence should be inspectable. Applicants should disclose costs and other funding.

Coinholders then need to decide whether the finished work is valuable and whether the amount requested is justified.

So the strongest criticism of Zcash Labs is not:
“The Labs principals can vote to pay themselves.”

The stronger criticism is that Labs could accumulate several kinds of influence at once. It chooses what to fund, presents the work for reimbursement, may hold meaningful voting power, and successful grants build reputation that may make later, larger grants easier to approve.

That can become self-reinforcing:
capital → project selection → completed work → reimbursement → reputation → more influence

Retroactivity reduces execution risk. It does not eliminate concentration risk.

That, to me, is the real governance question: can we get the benefit of a private actor willing to put capital at risk first without allowing capital, reputation and voting influence to become more important than the evidence?

Reputation exists in every grants system. Established ZCG teams benefit from their track record too. In fact, track record is one of the strongest signals available when funding future work.

The important difference is that with retroactive funding, reputation should never substitute for evidence.

If Labs eventually applies for, say, USD 1.2 million retroactively (USD 1 million of underlying cost plus 20%), then show coinholders the completed work, proof of completion and actual usage, the budget, what Labs funded and any other funding, and disclose the conflicts.

Then let coinholders decide whether the completed USD 1 million of work plus the requested 20% premium is worth paying USD 1.2 million for.

That gives coinholders a much better information environment than committing USD 1 million before the final result exists. Prospective grants can reduce that uncertainty with milestones, monitoring and oversight, but retroactive funding changes who carries the execution risk.

Private capital goes in first, the work gets done, and only afterwards does Labs ask for reimbursement plus a return.

That does not eliminate governance risk. It gives coinholders much better information when they vote.

And I don’t think the 20% is ridiculous on its face. The comparison is not 20% versus zero.

Nobody finances, selects and oversees work for free. The real comparison is 20% versus the alternatives: builders carrying the cost themselves while they wait months for a single milestone payment, a standing grants committee with its own administrative costs, or the work not getting done at all.

And the 20% is not guaranteed. Labs only earns it on work coinholders approve.

If coinholders say no, Labs doesn’t lose 20%. It loses 100% of what it spent.

Do the maths. Fund six USD 1 million projects. Coinholders approve five at USD 1.2 million and reject one. Labs has spent USD 6 million and recovered USD 6 million.

Zero profit.

And that is before counting the months of capital tied up between paying the builder and the vote.

So the real expected return is likely to be well below 20%. The premium pays for putting capital at risk before anybody has agreed to pay for anything, for the risk that coinholders reject the work, and for the cost of choosing, funding and overseeing projects in the meantime.

Good administration is not free either. ZCG has a standing committee and administrative infrastructure because prospective grants require due diligence, accounting, custody, milestone supervision and continuing judgement. Coinholders already pay for that, through the block rewards that fund ZCG, whether a grant succeeds or not.

Under the private model, Labs carries that cost itself and prices it into a premium that coinholders only pay on work they approve.

Labs also has an obvious incentive to argue that the projects it funds deserve reimbursement.

That is why the governance design matters. Don’t design the system around the assumption that interested parties will restrain themselves. Design it so self-interest has to operate against evidence and scrutiny.

For me the protections are simple: the work has to exist first, and reputation must never replace evidence.

If coinholders are going to make multimillion-dollar decisions, I would much rather they judge completed evidence than multimillion-dollar promises.

I am against pure coinholder voting for governance generally, but I do support its binding use here for the retroactive funding experiment, because coinholders are judging finished, inspectable work rather than betting on promises.

Zcash Labs is exactly the sort of experiment we should be testing, not condemning.

The question is not whether the Labs principals may vote their own coins. ZIP 1016 already answers that. The question is whether the model still works if we assume that they do.

Voting on the current Q3 retroactive grants ends on September 29th.

Then we get the results of the first real test of this new model.