Well, they can try to create multiple accounts with fake information or trick legitimate users into providing their deposit addresses.
I am pretty sure Binance uses transparent addresses. I doubt they would want to touch a shielded adress with a 10 foot pole.
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).
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: 
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
Just updating everyone on the things that I am working on that are relevant to this issue.
As a personal note, I absolutely love the amount of community ideation that this thread has generated!
Thanks for all your hard work, @Beth! You deserve a raise.
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.
@kayabaNerve Serai decentralized exchange is very important for zcash.
zcash community should give priority to various DEX’s and other Peer 2 Peer options.
If development of Native Atomic Swaps within zcash ecosystem are advance enough then even removing t-address and removing sapling pool with trusted setup will be easier.
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:
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.
It’s definitely a possibility.
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:
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).
Quick Update: Last week, I contacted Binance to propose several alternative solutions that could potentially resolve their concerns. These alternatives are simpler to implement than Binance’s suggestion of creating a new transparent address type. I have requested Binance to review these alternatives and then arrange a call with their wallet and listing teams and me, @joshs, and @Beth.
Alternative Solutions
Required return address (h/t: @squirrel)
a. Binance introduces a new policy requiring Zcash users to provide a return t-address on the “Deposits” page.
b. A deposit address dialog prominently displays a notification that failure to provide a return address will result in the funds that were sent from a shielded address being burned after a certain period of time.
c. Binance should communicate this policy change clearly to its users through announcements, emails, and notifications, ensuring that all users are aware of the new requirement.
d. If a return address is provided, any ZEC sent from a shielded address to the user’s Binance address is automatically returned to that address.
Viewing key submission (h/t: @joshs)
a. Users have the option to submit a viewing key to detail the source of funds.
b. Funds from shielded addresses are not available for trading until a valid viewing key is received and verified.
c. If a valid viewing key is provided, the ZEC can be deposited directly on the exchange.
d. Users receive multiple email and UI warnings emphasizing that non-compliance will result in the burning of deposited funds after a specified grace period.
e. Note: This solution can work together with Alternative Solution #1: Required return address.
Payment URI (h/t: @hanh)
a. Binance would need to integrate a payment URI into the deposit QR code, which currently reflects the t-address.
b. Transforming the URI into a QR code would take an estimated day or two of development time.
c. Zcash wallet developers would extend the payment URI specification with an “exclude” value to specify the desired pool for transactions.
d. The wallet would recognize the URI and exclude shielded ZEC from being sent to Binance.
e. Note: This solution can work together with Alternative Solution #1: Required return address.
Payment disclosures (h/t: @nuttycom & @str4d)
a. Binance would need to support receiving funds from a shielded address, so that they could support receiving payment disclosers in the memo field.
b. Assuming Binance is using Zcashd, this change is relatively simple to make.
c. A payment disclosure would be provided in the memo field and would prove to Binance the source address of the funds.
d. Binance would need to implement a policy that requires all Zcash deposits include payment disclosures.
e. If payment disclosers are not provided, deposited funds are burned after a grace period. Alternatively, if implemented, Binance could donate those funds to the Zcash Sustainability Fund.
f. Note: This solution can work together with Alternative Solution #1: Required return address.
I would think there are legal issues with burning user funds, which is why they requested this new address type.
Has any effort been made yet, about hypothetically implementing Super Transparent addresses?
(Transparent Addresses that can only be interacted with among other Transparent Addresses)
There have been some preliminary discussions, but nothing has been decided. It’s very much in the exploratory phase.
Great News!
My thoughts are that with Binance now coming forward with these new sorts of requirements requests (driven by policy sensitivity), we’ll be doing ourselves a favor to assume that eventually every CEX will end up requesting similar sorts of requirements.
This is why it feels more cypherpunk to build a future-proof solution into Zcash now (using software), rather than convincing with soft skills Binance (and other CEXes in the future) that they ought to support the regulatory requirements by doing more Zcash-unique internal book keeping and UI efforts.
Would it really make sense, for this Zcash team to have to on a 1-by-1 basis, convince other predominant CEXes: Coinbase, Kraken, Gemini, Crypto-com, Kucoin, Bitfinex, OkEx, Huobi, et al to also build and maintain similar Zcash UI specifics and internally managed Zcash holder records?
Cannot binance handle this with administrative procedures?
They could change their TOS that any ZEC sent from a shielded address is flagged and the user is only able to withdraw those funds to a T address and not use them on the platform.
Ive not used binance for a while but its my understanding full KYC is in place to have an account
Yes, to address concerns related to transaction monitoring, regulated exchanges like Gemini often employ Enhanced Due Diligence measures to verify the source of a user’s funds. However, the Binance representative we spoke to emphasized that implementing such measures is operationally burdensome and therefore not a long-term solution.