I imagine its easier for (insert wallet of your choice) to create a t-addr that you’ll send from, store the deposit address for (insert exchange of your choice) - then rely on the wallet to move funds through the t-addr in a way that’s acceptable to exchanges (ie: amount, timing, etc).
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?
It is a payment uri. It doesn’t force the client or binance to do anything. The client could still pay with shielded zec but the payment uri tells the wallet that transparent zec should be used.
If you are unfamiliar with them, I suggest you read the zip ZIP 321: Payment Request URIs
Apologies if this is too much of an interruption, yet THORChain planning their integration around transparent address is a property of them, not a property of decentralized exchanges in general. My own work (Serai, a decentralized exchange) has prior reviewed integrating Zcash and would do any integration via the shielded addresses. Accordingly, it’d be able to survive the removal of transparent addresses (and wouldn’t request their extension).
With regards to “building a Zcash DEX”, I find the discussion quite ironic because when the THORChain proposal was made, I commented for the cost quoted one may be able to build their own DEX for that cost. Today, with Zcash still not yet integrated into THORChain, the discussion has so shifted.
My other immediate comment is shielded atomic swaps for Zcash do exist. I wrote a Zcash integration for ASMR, my work on atomic swaps, years ago.
I’d be open to integrating Zcash. I’m currently keeping an eye on coins we can/should integrate after launch, and it’ll come down to:
Personal interest by developers and the community
I don’t image Zcash would be technically difficult. Despite discussing the shielded protocol, I have prior experience and the Serai codebase was designed to minimize requirements on external networks and be flexible around them
Regarding economics, the main question would be about ensuring liquidity.
Regarding community, I’ve had a few members of the Zcash community express interest Regarding developer interest, there are specific aspects to Zcash I can appreciate.
Since we don’t have much control as to who lists ZEC or not, I think we need our own on/off ramp. So the thought that came to mind was to make a some kind of finance co-operative, a legal entity in a friendly jurisdiction that can still access the US/Europe banking system, and hopefully more areas like Latin America.
The sole purpose of the co-operative would be to buy and sell ZEC, with the necessary KYC/AML process for the users, become “Tether for Zcash”. The co-op could operate like a Uniswap pool, where people can deposit liquidity and get a portion of the fee for every swap. The rest of the fees get distributed among the co-op owners periodically after covering the cost of building/maintaining the systems.
I think the key difference between this and something like Sideshift.ai is the connection to the traditional banks. What I keep hearing from people when I bring up using ZEC is “how do I turn it to dollars?” and just swapping for USDC is not enough for normies.
This could give the community more agency as to the availability of ZEC and could finally provide an option for yield for ZODLers.
I’d like to hear the community’s feedback and here are a few pre-emptive comments:
I don’t know how difficult/expensive the legal wranglings of creating such an entity are and I have reached out to members of the community with more knowledge than me about it.
I am concerned that, unless you can maintain Satoshi Nakamoto’s level of anonimity, building a DEX platform like Bisq for ZEC would put those devs in the same spot the TornadoCash devs found themselves if there’s a privacy coin crackdown.
On the topic of liquidity, does your platform have a minimum requirement? Or does its market sizing perpetually increase/ decrease based on supplies/ activities? In general, the Zcash market strength is very low as compared against larger more popular projects, so until that trend changes the economics might be tough to rationalize.
Serai hasn’t launched yet, and I’m refraining from any explicit decisions on what I’ll support the integration of until after launch as a matter of not only not side-tracking myself, yet not making representations to projects that cannot yet be backed (not like we can add more integrations before we’re live).
While I’m sure with integrations, the community will eventually form a matrix to evaluate priority, I’m unsure swap volume will be heavily weighted. Serai will most likely value liquidity commitments (as in, Uniswap-v2-esque liquidity, not as in, actively managed limit orders) and the validator commitments needed to actually support that much liquidity. Trade volume benefits the LPs, which encourages more LP, which benefits Serai (maintaining alignment), yet the direct benefit to the network is from people providing liquidity, not from it being swapped.
Considering this liquidity can be passively provided, it’s a much lower barrier to entry compared to providing liquidity on a limit-order centralized exchange.
Beyond prioritization, I can’t think of any minimum worth discussing. Technically, the network requires the validators maintain a fault tolerance of >=1 to protect the integrity of the liquidity, so post-launch if the validator count gets too low, validators may be obligated to remain despite effectively-nil liquidity.
While delisting procedures could be implemented and added, my personal view is any integration should be considered a commitment and it should only happen on truly exceptional circumstances (no validators still interested in being Zcash validators, effectively no liquidity/swap volume, etc).