Cross-posting my question to NEAR here as it applies to Maya as well.
Maya: Can we get clarity on how you implemented shielded support, and where exactly in your stack Orchard/shielded is supported?
AFAIK full Orchard support would require that Maya validators move to FROST for liquidity storage instead of using TSS.
I want to caution everyone to what we should flag as “traceable orchard” support across our community. When is an orchard transaction traceable? When someone deposits into Orchard with an exact amount, then withdraws from Orchard that same nearly-exact amount. Especially if the withdraw happens soon after the deposit.
To a new dev in our ecosystem, the easiest way to support orchard is to allow users to deposit into an orchard address, then immediately transfer those funds out into a transparent address. That’s almost as good as not using orchard as all, it’s very very traceable.
When a project claims shielded support, let’s be vigilant about verifying what exactly they mean by that. The “traceable orchard” approach I define above is not entirely bad - it is a baby step towards full orchard support - and is perhaps better than nothing. But what I really don’t like about it is that users get a huge false sense of security.
(Context: Immense tooling and understanding exists for Bitcoin addresses, which is why I strongly support Zcash transparent addresses (which are essentially BTC addresses) for developer evangelism. T-addresses got us NEAR and Maya years sooner, if ever. TSS is the technology that allows Maya and NEAR to safely store massive amounts of Zcash across multiple validators in a mostly-trustless, decentralized way. But it does not support Orchard addresses. For that you need FROST. So, transparent addresses are essential right now, and are absolutely both a feature and a bug.)