I am so pleased to see that this project proposal is generating a discussion. This project has been in the back of my mind for our team for over a year, so it’s exciting for me to see the community engaging with it now. I’ll give some more thoughts and responses.
Bridge Subnet + Shielded Zcash Subnet
In our initial discussions about this project, the idea was to create a Subnet to handle bridging with support for bridging to the C-Chain, but to leave the architecture open enough to allow anyone else to also bridge to their Subnet as well. With Prof. Matthew Green’s interest in supporting shielded transactions on Avalanche (and as Milton points out, another project is already part way there) it does make sense to me to make sure these two projects (and two Subnets) can function together harmoniously. I do think that architecturally the way to implement this is with two Subnets (as described earlier). As far as project scope, it seems like there are a few options, and we are open to finding a project scope that works for the Grants Committee.
Tokens and Staking
Shielded Zcash Subnet
For the shielded Subnet running the Zcash chain, it makes sense to me to use ZEC.z as the staking and gas token, as Matt suggests. (By the way, I’m using the naming convention for ZEC.z that Avalanche uses for its bridged tokens. For instance, BTC.b, USDC.e, etc.) This is a win all around for the reasons that he describes.
Bridge Subnet
For the Zcash-Avalanche Bridge Subnet, I see from our discussion here that the staking token is perhaps the most controversial aspect of this project, so let me put some more time into explaining our reasoning behind creating a ZAX token for this purpose.
As described earlier, we propose that it be used for both staking and gas, but one thing also worth pointing out is that new ZAX would also be minted and then distributed as rewards to validators for participating in the Subnet.
The vision here is for the Bridge Subnet to follow the model that successful blockchains have already implemented and to avoid reinventing the wheel. This Bridge Subnet really is a small blockchain with all the benefits and complications that that entails, and by far the safest path is the path well-trod.
Pkr’s idea of providing ZAX proportionally to all Zcash holders appeals to me more and more, and this would also simplify the user experience when using the bridge. Fresh ZAX would be minted as users bridged ZEC to ZEC.z and would be automatically deposited into their wallets on the Avalanche side, with a small amount deducted for bridging fees. Bridge users would then have a choice what to do with the rest of their ZAX. Stake it? Save it for future transactions? Sell it? We would want to implement a locking period for ZAX to prevent a fast sell-off, but eventually everyone should be able to sell all their ZAX to others who would like to buy it. I could see this being very appealing to perspective bridge users: use the bridge, claim their ZAX, and initiate its unlocking clock. What a great way to organically get the community trying out the bridge!
To Zcash users who normally just think about one token, ZAX may seem unnecessarily complicated from a user experience point-of-view, but I assure you that once you’ve entered the Avalanche ecosystem, dealing with multiple special-purpose tokens is the norm; many projects have one.
Over the longer term, we envision that red·dev would take on the role of a smaller Electric Coin Company for this Bridging Subnet, and like the them, red·dev will require a dependable income stream. This is another reason to create ZAX, as a portion of staking rewards can be apportioned to red·dev. Also, ZAX aligns incentives; the more successful the bridge, the bigger the rewards. This also frees up the Grants Committee from ongoing funding; all this project requires is seed funding.
Along the same lines, not using ZAX raises another issue. If we were to use another token for staking—say AVAX or ZEC.z—the Bridge Subnet would have to pay rewards in this currency, and because we can’t mint it, a supply would have to be bought, diverted, or financed, creating a host of new questions and problems. For instance:
- What is the source of these funds?
- As values of tokens and bridge use fluctuates over time, how are adjustments made to staking requirements and reward amounts? If these must be done manually, who is responsible?
Another issue with using a token besides ZAX as the staking token is that the Subnet would have to implement slashing of funds for malfunctioning or misbehaving validators. Avalanche has avoided implementing slashing (the only funds at risk are your potential rewards). As someone who has run an Avalanche validator, let me tell you what a wonderful thing this is not to live under the specter of slashing day in and day out. Avalanche has been able to do this successfully because they are using the AVAX token for staking, and everyone realizes that if the Avalanche network were to malfunction or to be successfully attacked, the value of AVAX would plummet—in effect platform-wide slashing. This keeps everyone incentivized to validate the network with care and integrity. Some fudders have been skeptical that this would work, but at this point, the Avalanche platform has proven itself.
However, if Avalanche were to stake its validators with another token, say for instance BTC.b, the same incentives would not be in place. An Avalanche validator could misbehave with no concerns about tanking the price of bitcoin. The only way then to enforce good behavior would be to threaten to slash each validator’s BTC.b.
We would face a similar problem if another token besides ZAX were used to stake the Bridge Subnet. We would have to implement slashing of that other token in order to enforce good validator behavior. This is a huge minus imo, especially in the Avalanche ecosystem where the norm is no slashing.
An International Bridge
As we talk here in a Zcash forum, it’s easy to think of this bridge as a “Zcash property,” but in fact, this bridge is connecting two sovereign platforms, just like the Peace Bridge connects the US and Canada. I’d urge that everyone take on this mindset. Both platforms will benefit, and it serves both communities. Whereas the Shielded Zcash Subnet that Matt proposes would be much more closely connected to Zcash (with 1:1 pegging, etc.), this Bridge Subnet serves as a way station to parts of Avalanche that have nothing to do with Zcash as of yet and may not even yet exist. This “international” aspect is yet another reason to use an independent token for staking the Bridge Subnet validators.
Custody of Funds
Both Matt and Milton have raised an important security concern about funds custody. These wallets and smart contracts could become large honeypots indeed. Avalanche’s SGX Bitcoin bridge does something interesting to mitigate this problem. On the bitcoin side, it does keep the bridged bitcoin in a wallet, but on the Avalanche side, it never takes custody of the BTC.b. Each user’s BTC.b is protected by the same private key as secures their bitcoin wallet. These cryptography gymnastics are done by having the user sign some data with their bitcoin private key, then extracting their public key from the signature, and then using that public key to create a wallet on the Avalanche side that only the user’s bitcoin private key can unlock. (My team is familiar with this kind of thing already, as we had to use a similar technique to verify an X-Chain digital signature on the C-Chain for the tutorials that we wrote.) I’m sure there are other ways to further protect bridge assets, but I think it would be a good idea to start with something like this, especially considering the similarities between Zcash and bitcoin.
OK, that was a long one! 
I think is worth it writing all this down though as it helps us think about these issues clearly and in a documented manner. Thank you so much for the comments so far. We will be submitting a formal proposal soon.