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.
Has any effort been made yet, about hypothetically implementing Super Transparent addresses?
(Transparent Addresses that can only be interacted with among other Transparent Addresses)
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.
Last week, I had a call with Binance about the four solutions we proposed as alternatives to creating a new “exchange-only” transparent address type. Unfortunately, Binance has decided to reject all of these alternatives. They cited practical difficulties in implementing policies like the Required Return Address and Viewing Key Submission and also have concerns about burning customer funds. The Payment Disclosures proposal was also rejected because it would require Binance to accept funds from a shielded address. Hanh’s Payment URI idea was originally met with interest; however, it was ultimately dismissed because it does not fully prevent transfers from shielded addresses.
The only available course of action is to implement the “exchange-only” address type. Failing to do so will result in ZEC being delisted from the Binance exchange. Binance is giving us until February 29, 2024 to comply.
Compliance Categories & Timing
Binance has categorized privacy coins into three groups based on their willingness to comply with implementing an “exchange only” address type.
Immediate Risk of Delisting: Coins like Monero, which has already stated it will not comply, will likely be delisted next month.
Under review: Projects like Zcash, that are actively seeking compliance solutions, but may face community or resource challenges, have been given until the end of February to comply.
Compliant or Actively Working Towards Compliance: Coins such as Firo, which have adopted or are in the process of adopting the new address type, are not at risk of delisting.
The Binance representative stated that their stance on privacy coins is in response to increased regulatory pressure, including MiCA, recent initiatives from US regulators, and compliance to the settlement with the US Department of Justice.
Next Steps
The potential delisting of Zcash by Binance is a significant issue that requires serious consideration. A delisting carries the risk of limiting the accessibility of Zcash, potentially slowing user adoption and adversely impacting the price of ZEC. In addition, given Binance’s role as a major liquidity provider to numerous centralized and decentralized exchanges, the delisting could have broader downstream implications. There is also the possibility of a ripple effect where other exchanges consider similar actions in the future. It is crucial that we understand and prepare for the consequences of not adhering to their request.
Regardless of whether or not we decide to comply with Binance, we need a strategic plan for how to proceed. In the coming days, I will initiate discussions with ECC and ZF to thoroughly evaluate the consequences of a potential delisting and develop a path forward. Additionally, I am considering organizing a Twitter Spaces event in early January. This will offer the community a venue outside the forum to discuss this issue and share their perspectives.
Don’t waste time implementing this address type. It is so easy to circumvent this restriction by just sending to a t-address first that regulators will undoubtedly soon require Binance to do extensive KYC or delist Zcash.
The regulators got Binance in a particularly tight grip because of the settlement, so it is not certain at all that it will spread to other exchanges without a legal battle.
What Zcash needs to do in response is to create secure bridges to other chains or atomic swap protocols, and also prioritize censorship-resistance by choosing PoS protocol with many validators and also integrating network privacy for wallets and nodes.
Even if you could meet those demands (which basically amounts to making Zcash a permissioned payment system), ALL Zcash still passes through shielded addresses before they can be spent per the shielded coinbase rule.
I think it’s a good idea to assume that the stance Binance is taking towards “privacy coins” may make it’s way to all regulated exchanges eventually. So whatever decision we make re: Binance now, it’s probably best to assume that we are making it for all the other regulated exchanges Zcash trades on as well.
Another way to put it, we should make this decision re: Binance as if Coinbase, Gemini, and all the others are making the same requests.
I thought for a long time, what is the point of ‘exchange only’ addresses? What is the difference between an ‘exchange only’ address and a transparent address? Basically they want a type of address that cannot directly interact with the shielded pools do I understand correctly?
If you want a new address type that makes sending funds from shielded very hard, it could be done without modifying the protocol by just defining a new encoding of a regular t-address.
Basically, a wallet could take the same t-addr as before but represent it as this new t-addr (let’s call it t2).
t and t2 can be converted back and forth as this is just a different encoding prefix: taddr ↔ t2addr
From Binance perspective, the code change is minimal. They need to add this conversion in their address generation.
Wallets that want to send to Binance also need to convert. At the same time, they must restrict the source of the funds to transparent. If a wallet doesn’t do that, these t2 addresses will look incorrect.
The only way to circumvent these t2 address is to convert from t2 to t manually without using a supported wallet, directly for binary, and then use the resulting taddr. I think that requires knowledge that 99.999% of the users don’t have. It cannot be done by accident.
All in all, it is just a few days of work. The encoding/decoding is already in librustzcash.
This sounds like a pretty reasonable solution to me. It’s not protocol-enforced, but providing a wallet-based solution like this would be workable and as you say it’s not a huge amount of work, although it does present some UX challenges because the wallet would need to inform the user that they have to de-shield funds before being able to make such a transaction or else would need to create a chain of transparent transactions, one to de-shield the funds and then the next to send to the exchange’s t2-addr.
That doesn’t seem too bad, because both the de-shielding transaction and the transaction to the t2-addr could be created and submitted to the chain at once; block construction will select whole such “transaction chains” from the mempool at once.
It’s a bit silly, but if all that Binance actually wants is for funds coming to them to be spent only from transparent UTXOs, this is the least-invasive and most readily implementable solution I’ve seen suggested. Also, it doesn’t actually require a significant compromise of the user’s privacy; the deshielding t-addr can be fresh each time.
That part is not needed. The wallet can just show that the spendable balance for a t2addr (= balance in t funds). The user can manually deshield. The required part is that Binance doesn’t receive funds from shielded funds. It would be convenient to auto deshield, but it is not necessary.