Firo's Privacy and Unified Addresses?

I’m trying to fully wrap my head around Firo’s Privacy. To set the record straight I’m not a fan of Zcash at all ie “trusted setup” and things I hear regarding ZIP320. It appears that Firo is not a fork or related to Zcash but is similar in functionality of transparent and non transparent addresses?

So here are my questions plain and simple.

Does Firo have Unified Addresses like ZEC?

If so does Firo embed a transparent address to the UA in a way that could leak user information?

So if a user such as myself were to swap assets, shield them, and post my (shielded) spark address, Firo’s design would not inherently expose a transparent address for adversaries to trace back to sources like KYC exchanges?

What got me here was how Zcash’s Orchard addresses can still include transparent elements in unified addresses, potentially allowing traceability if not used carefully.

[1] Say "Shielded Privacy" for UA that contain a T-address by emersonian · Pull Request #1853 · Electric-Coin-Company/zashi-android · GitHub

[2] Unified Addresses Composition - protocol - Zcash Community Forum

Firo does not embed transparent address in our Spark address.

1 Like

So in Firo, when a transaction is made from transparent address to spark shielded address (minting spark balance), the wallet is designed to send any change address back to a shielded address by default?

As compared to Zcash that exposes a change address if you send from transparent address to a shielded, it sends back to often result in change being sent back to a transparent address (depending on the wallet implementation)?

If it does that’s great. Does that mean all official Firo wallets that support Spark addresses do this (send change back to shielded spark address)?

@anwar So with Firo when a transaction is made from transparent address to spark shielded address, the wallet generates and uses a shielded address for the change to ensure that unspent outputs remain private?

Yes or No?

Currently, the change goes back to a transparent address. For e.g. if an exchange can support transparent address deposits only but can support SENDING to Spark addresses (such as Biconomy), then the change should come back to them to a transparent address. If you mandate the change to come back in Spark, then they would be forced to either:
a) support Spark; or more likely
b) not allow Spark address withdrawals.

Really I thought when sparking mints in the wallet, it sent the change outputs back to spark essentially shielding the all outputs?

Is this due to limitations of the protocol, or by design for compliance?
If its the latter why not automatically configure wallets to send change outputs to spark by default or provide manual option to configure this if users don’t need it?

1 Like