Two years ago, my team did a review of the BTCPayServer Zcash module. Back then we discovered that the module could use some improvement. It looks like some great development has been done since then; we’d like to take the time to formally confirm that. As the deliverable for this grant, we’ll assess what’s been built, what’s been improved, and what still needs work. Then we’ll outline suggestions for the architecture of the next features / remaining fixes.
In order to make it clear that our goal is to increase the strength of the Zcash ecosystem, we will recuse ourselves from any future paid development work on the next steps that we outline.
Note: My core team members are the same as they were in 2023, but we have shut down Birdcalls.is and are now working on a new company together, Who Technologies. This work isn’t on theme with our main mission now, so we’ll do this under my and Aeron’s long-standing catch-all LLC, LCFTA.
Personally, I would really welcome an independent external perspective and a calm, concrete assessment of what still needs attention. This is in no way an attempt to question the work or competence of the people who have been maintaining the plugin and supporting merchants. On the contrary, such a review can clearly highlight the progress that has already been made and what has improved.
What does the community think? Which criteria would you like to see in such a report to make it as useful as possible, for example, for merchants?
Firstly would like to comment that I appreciate your effort towards pushing for the BTCPayServer integration to be actively maintained and for reducing the barriers towards adoption.
Could you provide some more details on your team’s technical experience, namely with .NET and C#? Having some kind of technical architecture specification, documentation and recommendations to refer to would be nice, especially with guidance on following best practices for .NET.
My C# knowledge is fairly limited and I’ve been learning it as I go. I’ve been relying on my experience with Java, and some experimenting with C# scripting in the Unity Engine many years ago to help with picking up .NET, but having an outside perspective and feedback in the form of code review would definitely be helpful.
Am sorry that Birdcalls shut down. Would you be open to the idea of open-sourcing parts of the application, or helping work towards a lean modular calling solution that works with ZEC payments? I think there would definitely be interest in an open-source private group calling solution that people can pay for inside of apps such as Free2Z, zcash.me, ZECpublish, etc. This would help with moving off centralised platforms such as Twitter and Discord.
We definitely need to collect feedback from prospective merchants on what would encourage them to accept Zcash and I would love to hear your ideas and suggestions.
Hey @1337bytes, I’m so glad to hear from you. I’m replying to the second part of what you said first:
Thanks for your sympathy regarding Birdcalls! However, it’s not necessary. Long story short, we started Birdcalls with a very specific social goal: to normalize screenshot blocking. We achieved that goal. Now we’re happily on to new things. I have a lot of opinions regarding Birdcalls open-sourcing, Zcash private calls, threat modeling, accidentally creating barriers to entry, community goals, and feature prioritization, and I’d be happy to go into all of that - but that’s a separate discussion. Please feel free to start another post and @ me.
The thing that we want you to lean on us for is our technical expertise with architecting software systems including payment gateways.
We have a lot of experience building payment gateways. The equivalent of millions of US dollars have run through payment gateways we’ve built, and so we understand how to build them well. Here are some of the things that can go wrong with payment gateways that we’d like to look for:
First of all, of course, if a crypto payment gateway is built poorly, then sometimes money can just disappear. The person who sent it doesn’t have it any more, the person who is supposed to receive it doesn’t have it, it’s just gone forever. Burned coins.
Then there’s all sorts of edge cases to guard against. A few examples: How good is your double spend protection? If the currency exchange is wrong then of course you can lose the merchant money. How fast do currency prices fluctuate? What kind of guardrails have you built on allowing transactions to complete after a period of time? What if prices are fluctuating so fast that someone starts a transaction, then waits three hours to send their payment, and now the price has changed? What about refunds? Do you have a way to account for how much the price has changed? Etc. etc.
It may be that you’ve already built a lot of this! But it’s good to have outsiders to do an audit to publicly confirm that, and if there are improvements to be made, then we’ll be happy to spend some time assisting you through them.
In addition, we know that multi-wallet and multi-store support is desirable for this plugin. While we’re already in the codebase, we’re happy to share with you any information we find about how easy or difficult it’s going to be for your developers to build that.
Thank you for providing additional context in this thread. We had an initial discussion of your proposal, and before moving forward, I think it would be helpful to clarify a few points.
In particular, could you please clarify whether this work is intended to be a formal code audit, or whether it is not an audit at all but rather an advisory or architectural review focused on general feedback and recommendations?
Additionally, could you explain how the proposed evaluation would account for constraints at the Zcash protocol level (and, more generally, any blockchain), including cases where certain features such as refunds are not natively supported/provided? How would this align with the architectural characteristics of BTCPayServer? For example, the use of view keys for merchant wallets does not introduce double-spend risks and does not pose a threat to either merchant or payer funds.
More broadly, while we understand how traditional banking payment processing works, those systems rely on trusted third parties. Blockchain-based systems intentionally impose constraints precisely because there are no intermediaries. During our discussion, I found it difficult to explain how we would act on recommendations such as implementing payment refunds, given that some of these constraints cannot be addressed at the application level.
Clarifying these points would help us better assess the scope, expectations, and practical value of the proposed work.
Hi @artkor , thanks for your questions. I know that this project is personally important to you! I’ve seen that you’ve contributed code to the BTCPayServer Zcash plugin in the past:
So I’m sure you care just as much as we do about making sure that the plugin functions as well as possible.
My team was paid by Zcash in 2023 to do a review of the BTCPayServer Zcash module. Here’s the results of our analysis then, in the form of nine bullet points:
We are proposing to be paid the exact same amount of money (adjusted for inflation) to perform the exact same review again, in order to confirm that the 2023 problems have been addressed.
I am uncertain as to why there is confusion regarding whether we are proposing an audit or a review.
I think there might be confusion here. See above for the nine bullet points we identified as problematic in our 2023 analysis of the Zcash module, which we propose to review again to confirm that everything (except for multi-wallet and multi-store support) has been corrected.
I know that the committee was supposed to take this proposal to a vote this morning, and has probably already voted now. It’s unfortunate that you did not post these questions any time earlier in the 11 days since your last comment, so that we could have had time to respond before the vote.
I know that you did what you did in the last committee meeting because you thought it was the right thing to do. We all want Zcash to thrive, and specifically, we want it to be used in the world for actual transactions between regular people paying for goods and services. That’s what the BTCPay module can help Zcash achieve. That’s why it’s important that it be built well.
But after thinking about it for a while, I realized that there is a structural problem here that we can fix together. In the same way that my team is going to recuse themselves from doing any development work on the module (because we would have a conflict of interest if we were paid to point out problems and then we also got paid to fix those problems), you have a conflict of interest here. So, you should also be recusing yourself where necessary, in this case from the committee discussion & vote.
Your comments and questions are still important, of course! They should be communicated only in the general public forum.
Now that the vote has been postponed into the new year and the grants committee will now include @hanh , who has done the bulk of the development on this project and therefore has a conflict of interest regarding it, @hanhshould also recuse himself from the committee discussion & vote.
Could you explain what the conflict of interest is? Only me and @hanh have contributed code to the BTCPayServer Zcash plugin. In any case, I don’t feel that simply contributing code to a project would constitute a conflict of interest if it is unpaid and there isn’t some commercial motive.
I feel that @hanh’s input into the discussion would be valuable (at least when it comes to technical expertise, this could be a separate comment in the form of a forum post though); however yes, there would likely be a conflict of interest when it comes to a vote due to his work on zcash-walletd.
While @artkor hasn’t contributed code, he has contributed documentation. Lack of proper documentation was one of the things we called out in our original review of the module back in 2022, so part of this proposed review will indeed include directly assessing @artkor’s contribution.
I just posted this in the other thread, it’s probably least chaotic if we keep the conflict of interest discussion there:
The ZecHub documentation is not official documentation for the BTCPay plugin and I plan to create a separate documentation resource/website under the btcpay-zcash organisation. For now the official BTCPayServer documentation together with the ZecHub documentation has been sufficient, together with me answering merchants’ questions. Until there is a proper documentation website, I don’t see the value in a documentation review that will simply reiterate what is already known.
I don’t think that he should recuse himself from the discussion and vote; as FPF have stated, contributing code to a project does not constitute a conflict of interest, and his documentation resource is not official documentation for the plugin. This discussion feels like unnecessary meddling in the grant review process.
Thanks for the clarification; you don’t think that anyone should recuse themselves from the vote, and you don’t think that the documentation should be included as part of the review.
Do you also not think that the review should take place?
Am confused what you mean by this. Hanh has been paid for work on the BTCPayServer plugin in the past, so he would be required to recuse himself. I don’t see any reason why Artkor should recuse himself from the discussion and vote.
I don’t believe that the unofficial ZecHub documentation should be included as part of the review. I’m grateful for this resource, but the documentation on GitHub should be improved.
At this point I do not see the value in a review of the project in the form of a text review of the plugin. $15k is a lot for what I understand will be a forum post.
Regarding documentation, noted. I disagree of course, but I think we’ve both made our arguments plain enough for the committee to be able to make their decision.
Regarding the entire value of the review: My team got paid the same amount of money two years ago to do this same review. Do you think that the review two years ago was also not worth it?
Thank you for submitting your proposal. Following a thorough review by the ZCG and a period for community feedback on the forum, the committee has decided not to move forward with this proposal.
We sincerely appreciate the time and effort you invested in your application and encourage you to stay involved and continue contributing to the Zcash community. Further details will be available in the meeting minutes to be posted later this week.
Thank you for your consideration. I’m so glad that the voting recusals did happen. Both so that healthy precedent could be set for the future, but also so that we all know that there was only one issue being decided here.
For posterity, I did make a follow-up post regarding this. There’s some relevant commentary there from community members and stakeholders:
