Got to disagree here, it's one of the more profound questions in the space that @Milos is raising: "but how does ZKP usage affect auditability". See, there's a trite response: addition holding under a homomorphism still means addition holding (think like "well, the ZKP proves that new coins weren't minted, so just because you can't read the balance directly doesn't mean it isn't guaranteed to be fixed supply!"). But in a profound way this is not a good analysis: we don't only consider correctness, we consider recovery modes under incorrectness: *whatever* reason for random new bitcoin getting minted, we will see it in the utxo count (gettxoutsetinfo rpc); obviously it would be a bug, but we'd see it. in zcash it was warned in advance (by people like Peter Todd especially, but also I and others raised this alarm) that you don't have that counting function, so if *any part of the stack* fails, you will not know. That problem cross applies to *any* property you want a public blockchain to have, that if you cover it with ZK you need to be 100% sure there is no error, and you cannot be. None of this is some kind of checkmate atheists, never use ZKP, but it should be food for very serious thought. My way of putting this years ago is that "it's in the DNA of blockchains to be public". This is why I've always been focused on ZK for second layers.