Sidechains
Using some features I’ve described in the past (i.e. forks, asset locks, ZSA-addresses) should be enough to create 3 sidechains. These 3 sidechains enable some of the utilities present in many if the top 10 (by marketcap) cryptocurrencies.
Sidechains, by their nature, can change their block time to be much shorter then the Zcash main chain (e.g. 10seconds). Most sidechains will likely commit to merge back into Zcash main chain every main chain block. The merge process will use whatever state of the art aggregation techniques have been deploy in Zcashd/Zebrad making the sidechain very efficient.
The Z Amigos
ZCompute
This sidechain will enable user defined contracts. These contracts will allow the user to programmatically control how and when assets are transfered. This will be enabled by adding extra consensus rules to the main chain like asset locking, delayed transfers, conditional transfers, pseudorandom numbers, etc.
Fees charged by ZCompute go towards merging fees and rewarding ZComputed nodes. ZCompute could optionally charge enough to become an independent group/community that self funds upgrades and future operations.
ZRollup
This sidechain will enable anonymous groups of users to aggregate their transactions. This enables users to transfer their assets at a much cheaper rate. ZRollup will also have faster block times (e.g. 10seconds) allowing users to check for confirmations much quicker then in the main chain.
Fees charged by ZRollup will be much cheaper then on the main chain and will be used to pay for merging fees and rewarding ZRollup nodes.
ZLend
This sidechain utilises the fork asset locking functionality. These locked assets can then be used as collateral for other assets. The borrower will send a conditional transfer which can only be executed if repayments/equity thresholds aren’t met. The lender can earn interest in their deposited funds.
Fees charged by ZLend will pay for the merge
fees and also reward ZLend nodes.
Implementation of Sidechains
If we provide fork functionality in Zcashd/Zebrad then providing new consensus rules could be achieved with simple callbacks into a sidechain “extension”. This extra code could reject or delay transactions that do not meet the extra consensus rules. An example of this might be collateral for a loan where assets are “pending” transactions that don’t actually get executed unless interest/equity rules are broken.