Crosslink: Early Tokenomics Design

[shieldedmark]

I put together a little tool that so people can get their heads around the economics of staking via this particular design of Crosslink:

Crosslink Economics Simulator

TL;DR: What matters most is your stake relative to the TVL of all staked positions.

Other intuitions:

1. Your annualized earnings balance out no matter the size of your finalizer. The voting power only affects the tempo of the accrual.
2. Adding stake is mostly linear and has only a small effect on your annualized earnings % because adding stake increases TVL.

[zerodartz]

love it. could we have the orchard pool ZEC amount also changable?

[zerodartz]

thanks for the updates @shieldedmark

now the yield estimate is more clear at different orchard pool sizes. (difference is big with different pool size)

[shieldedmark]

I would like some feedback about the feasibility of adapting Penumbra-style Shielded Delegations to Zcash. I went a layer or two into the onion myself, and sketched the following.

Level-setting (PLEASE READ):

• The following is purely exploratory and is not intended as a change to Crosslink v1.
• Crosslink v1 protects information about the identity of the staker, this is a potential improvement

Cross-posted from GitHub, feel free to reply here or in the ticket.

---

Sketch: Penumbra-Style Private Delegations for Zcash

This exploratory sketch adapts Penumbra Private Delegations to Zcash to achieve shielded delegations, and publicly verifiable voting power. This effort is motivated by strict privacy and trustless finalizer weights.

Sketch

Here’s how we might be able to achieve this natively with ZEC:

1. Create a new staking consensus domain (Merkle tree + nullifier set), separate from Orchard’s
2. Each finalizer generates a staking keypair (separate from spending keys) and registers its public key as finalizer_id in a staking transaction.
   1. Consensus state stores the map: finalizer_id -> { ... }
3. A delegator spends v from Orchard, and creates three artifacts:
   1. A staking note commitment inserted into the chosen finalizer’s subtree
   2. An additively homomorphic value commitment (V = v·G + r·H)
   3. An encrypted payload that only finalizer_id can open to (v, r)
4. From there, delegations can be redelegated, unbonded, and retired in similar fashion, strictly maintaining the balance between the staking pool and Orchard (spends insert a staking nullifier / spend marker; redelegation re-mints a new staking note)
5. Once per epoch, all finalizers must publicly prove that their weight W = Σ V over all eligible leaves in that finalizer’s subtree, consistent with the staking state

Goals

• Privacy:
  • Delegator identity and delegation amounts are publicly shielded
  • Only the designated finalizer_id can unseal v via their private key
  • Staking domain transactions are sufficiently indistinguishable from one another
• Completeness
  • Finalizer weight W equals the sum of all unspent, epoch‑eligible staking notes to finalizer_id, with no omission
• Integrity:
  • No inflation: Finalizers cannot benefit by over-reporting W > Sum(v_stake)
  • No omission: Finalizers cannot game by under-reporting W < Sum(v_stake)
  • Spending authority remains with the delegator, finalizers cannot spend delegations
  • Values balanced are strictly enforced cross-domain: Δstake + Δorchard = 0
• Compatibility
  • Uses familiar Zcash constructions
  • Use the native ZEC token

The rest of the owl

To complete the full design, we would need to decide on:

• Completeness aka “no omission”: per-finalizer Merkle tree vs. Penumbra flow-encryption
• Domain separation (Orchard vs Staking): tags for commitments, hashes, keys, and sigs
• Finalizer registry design: minimal fields, activation/rotation rules
• Encrypted payload design: keying/derivation, binding/AAD, padding
• Data structures: staking and value-balance enforcement fields for block header / transaction / consensus state
• Policy: slashing, bonding/unbonding rules, liveness/penalties, activation/rotation rules