Transparent & Shielded DEX with Maya Protocol

Just one query from me @hanh , will the time line of this grant be affected as your grant has been approved for at least milestone 1 of the coin weighted voting/air drop grant.

Also vice versa will the other grant time line get blown out if this is approved?

Otherwise i love it, this is a critical service for zec


THORChain is again thinking to add Privacy coins like ZEC and XMR

@zkcroc It shouldn’t have a big impact. The first milestone is mostly doc writing and discussions.

@silentZcollector They have been considering doing that several times over the past few years.


It doesn’t work like that for THORChain.

No, it’s just one man asking random X accounts. I’m willing to bet 5 $ZEC that Thorchain will not integrate $ZEC until the end of this year.

He’s the Thorchain tech lead but the poll is not binding or anything.

1 Like

Thank. you for the detailed explanation!

Could you expand this a little bit? What are the mitigations that can be performed from Wallet UI?

Could wallets provide an arbitrary return address that is not the original sender? That’s how works currently for shielded ZEC.

1 Like

Yes a custom refund address is possible, but keep in mind you need to include this in the OP_RETURN. Which isn’t a problem on most chains, except for Bitcoin and Zcash itself because of the 80 bytes OP_RETURN limit. If this limit can be increased by Zcash itself, then sure no problem.

However does it make sense? You do a shielded tx and you still enter your ZEC address in the memo (either the z-address or the taddr). So you would still reveal one of your wallets.

Is this your way of communicating this grant is dropping support for sending to shielded addresses (and potentially also receiving from them)?

If so, I’ll have to reiterate a necessity to deprecate t addrs is shielded infrastructure, ready to go. This would continue to fail to provide that infrastructure when Zcash did not have its exchange status recently change (which would have made this grant urgent) and has limited funding (questioning if it wouldn’t be optimal to fund shielded infrastructure instead).

Receiving to t addrs also has significant metadata side channels compared to receiving to z the “wallet UI” phrase ignores while shifting the burden to them.

I don’t personally support this for the reasons above, again if so. Apologies if I misunderstood your update.

If this will still support z2 MP and MP 2z, with manually specified return addresses, I do likely support it :slight_smile: My remaining concerns would be cost (prior noted) and potentially timeline.

EDIT: See below question following up on MP 2z before taking the above ‘endorsement’ into account, please.

1 Like

This, with the caveat that manually specified returned address, is not officially supported yet (I think, I lost the link to the gitlab issue @GiMa). In this case, it would either be z2mp at the user’s risk or only t2mp.

Edit: On behalf of @Gima because of his new user limits

z2 MP is possible with custom refund address (keep in mind the 80 bytes limit). TC has added this for EVM’s only, we can add it for all chains. PR issue


To clarify, how do you plan to support MP 2z?

The outgoing view key alone is not inherently valid as it’s not enforced by the circuit and accordingly can be set to any arbitrary value regardless of the actual outputs created.

1 Like

The mp2z tx comes from mp. The Bifrosts will have access to the vault ovk and must use it.

… except the OVK-encrypted data isn’t verified in circuit. A malicious validator set can send to their own address, yet insert into the OVK that they sent to the claimed address. Is there an additional mechanism to verify it being proposed?

I don’t think they can do that. The ovk allows the validator to recover the shared encryption key and decrypt the note. So they can’t send to another address.

Thank you for the citing the process there. I was referring to how the Cout is sender-malleable. That isn’t an issue per the above.


Revealing your shielded address won’t reveal your transactions, so that is not a problem. Revealing a one-use t-addr also doesn’t pose a problem, as long as the ZEC enters the shielded pool eventually.

1 Like

Awesome to see you guys here active on the forums! It’s unfortunate how THORChain played out but I think it’s for the best we go in your direction.

Getting Zcash integrated on a dex with streaming swaps should be a top priority… let’s get this done :handshake:



@mayaprotocol do you have a public repo that we can see any current code or is it all private?

maya node code? Maya Protocol / MAYANode · GitLab


How long is an integration such as this expected to take? Are we looking at end of this year or next year before this becomes a reality?