I agree here strongly, in the ideological sense.
But in the practical sense, we’ve created too much risk in discouraging CEXes with our recommendations that ~they need to get more technical~ and that causing a wave of delistings that could cripple the project. We need them a lot more than they need us (I’m talking about this in the context of money/ liquidity to allow ZF, ECC, ZCG to readily sell ZEC).
A vetting process was just my first idea, certainly not set in stone. A super-transparent address type that is available to anyone might make more practical sense because it would eliminate any need for case-by-case vetting of exchanges or individuals who would like to use super-transparent ZEC.
I suggest that super-transparent addresses would not interact with shielded pools, so that the entire address type could be easily assured to the public that super-transparent ZEC have never in any way interacted with the shielded pools/ ZEC.
It doesn’t seem like a highly complex upgrade… supposing that a requirements spec could be pulled together quickly, reviewed, agreed, described to Binance, etc. The feature of restricting ZEC and how they can interact with existing pools already exists (ZEC can’t migrate backward thru the turnstile, i.e.).
This sounds promising. Would this solution require the exchanges to recode their existing custodial infrastructure?
As PKR observed: ![]()
![]()
![]()
![]()
![]()