Hello @machinesunmachine!
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.