I can see the inconvenience, but for what it’s worth I’d expect that with the amount of ZEC required to be in the top 100, most if not all people/entities will already be paying their taxes quarterly. It’s also the case based on my understanding of US taxes that while the frequency of payouts can complicate record keeping, the necessity of paying quarterly taxes is based on annual income not covered by withholding and not on the interval at which payment occurs.
2 Likes
Crosslink may address this issue, depending on the jurisdiction. The protocol tracks rewards every 10-day epoch and those rewards are automatically re-staked and auto-compound, but they are only paid out when you choose to unstake.
6 Likes
My intuition is that 40d lockup period is too long and is counter to attracting liquidity (which in turn impacts price). A model where someone can unstake and funds are released in the next 10d period would accomplish what is intended and is simple enough.
I also have concern with stake pulling funds from the shielded pool and wonder if Shielded Labs, or others, can surface alternative models for consideration, where increased liquidity due to yield opportunity would positively impact the size of the pool.
9 Likes
Just to clarify: the proposed mitigation for the privacy concern isn’t necessarily making the unbonding time long, but that it should be “inconvenient or impossible to unstake on demand” and the staking/unstaking events should be sufficiently quantized in amount and time. Both of these conditions could be satisfied with a much shorter unbonding period. I don’t immediately see a meaningful difference in privacy between a 7-day unbonding period and a 30-day unbonding period. Rather than debating the minimum unbonding period necessary to address the privacy concern, this initial proposal chooses a conservative number (30 days) and leaves this for further iteration and feedback.
My intuition is that 30-day lockups are way too long. Given the intense focus on shipping and iterating quickly there is a risk of path dependency here: there will be a temptation for things like long unbonding times to accumulate rationales in order to speedrun other parts of the design like social slashing, or for other desires like rewarding ZEC longs. This may lead to the decision becoming sticky. It may then be perilous for Shielded Labs to proceed with design/development of Crosslink under the assumption that long lockups will be tolerated by the community later on.
Of course, Shielded Labs can work on whatever they’d like. As Zooko said, it’s up to the community to give a yes or no vote to the final proposal. But the community’s veto power also has more teeth if signals are gathered early on. The purpose of this announcement is to solicit that feedback, but then anything that emerges as contentious may deserve early feedback directly from coinholders.
I do appreciate the careful thought that has gone into the proposal so far, particularly the privacy consequences!
15 Likes
I can’t see anyone being ok with Social Slashing, once it’s thought through.
https://github.com/ShieldedLabs/zebra-crosslink/issues/209
Every PoS system has figured out how to use incentives and code to align validator behavior. They didnt need to add a social layer nor pause button.
Many like Solana do not even use slashing. You can automatically punish poorly behaving validators with less or no rewards, it is painful. Engineers use code to solve problems.
Unstoppable private money cant have a pause button.
Of course when the state of the ledger is put at risk like Ethereum DAO or Bitcoins inflation bug the community will come together and make a one off fix. This survival instinct is implicit in everyone of these systems.
Using these extreme events that should never happen -especially when Crosslink only adds finality- as justification for a social court system on validator behavior just doesn’t make sense on any level. It also increases attack surface.
One can imagine a scenario in which a large amount of illicit funds flows into ZEC via a DEX and is staked in such a large amount that its fairly obvious which validator got the stake then the governments come asking for a freeze.
Overall Crosslink design looks like its from 2017 era. Not taking into account proof of stake is no longer experimental, it has become the standard.
There are proven mechanism and tokenomics. We don’t need to make ones up that add problems rather than solve them.
Zcash deserves better, let’s be better.
2 Likes
ZSAs will make sure the shielded pool stays big.
Hehe… as I said on twitter, this is a memetic KO.
I wanted to point out a potential disconnect though: if you’re pushing back against Track the User Stories and technical requirements for “Social Slashing” #209 then we mean different things by “social slashing”. I mean “the grass-roots ability to organize a hardfork/chainsplit, including altering the ledger arbitrarily” which all crypto has (and which I argue is the core innovation of crypto and the foundation for permissionlessness).
But if I take your post as pushing back against
Explore an Andon Cord design #210 (or any similar in-protocol intervention mechanism), then I still think we’re using the same words/concepts and (currently) disagreeing about the trade-offs.
BTW- I don’t outright reject your position, and am fairly partial to it, but I still want to spend some time/iterations where we scrutinize the trade-off space. The only sticking point for me, currently, is how privacy tips the scales and game theory.
Example: in a transparent PoS system, a very-badly-misbehaving validator (imagine it’s 100% clear to everyone they were actively executing double-voting attacks in order to profit from crashing the market price and destroying the network operationally as an extremum) can be “socially slashed”: an activist group splits the chain, resets the state to prior to attacks, and nukes the bad-guys tokens.
Now here’s the game theory issue: because that’s always theoretically possible, it raises the cost/downside to all attackers who might attempt something that catastrophic. If, OTOH, they can leverage strong privacy in any way that let’s them avoid having their funds slashed, now this threat is removed from the game theory, and this kind of more extreme attack may become more feasible.
We haven’t gamed this out yet, but we might as well in-thread to get broader coverage of ideas. My next thought here is even with 0-lockup delay, if they unstake into Orchard, the social slashing could still occur by rewinding just prior to the “Totally Unambiguous Bad Guy” unstaking… So at least for that scenario, it feels like the threat still remains without lockups.
I have low confidence we’ve explored the attack tree well enough, though.
(I’ll make a note to look into Namada & Penumbra security reasoning around these kinds of issues, too. If anyone else is aware of PoS systems with strong privacy and good design, LMK!)
I think we’ve already said this in other contexts, but time-to-market is one of our priorities, and that deserves to be an axis on the trade-off space. If we didn’t mind extending time-to-market, we could adopt a more sophisticated design with good trade-offs (my short list includes Penumbra and Namada staking).
In fact, the way we got to this design (which also has no “in-protocol slashing” nor down-time penalties) was stripping out complexity from existing networks. The unstaking delay and time/amount quantizations were then re-added in an attempt to balance privacy vs other goals.
One last detail: I consider “fast follow up iterations” to be lumped into “time-to-market”. In my personal opinion, I’d even be ok making “bad” choices on the trade-off curve to accelerate time-to-market, and then fix them with fast follow up improvements.
Some examples of that approach (and I’m not saying I approve of these yet, just widening the overton window):
- Remove privacy protections, ship it, see how bad that harms Orchard privacy in practice, then add privacy mitigations.
- Remove all lockup periods, then add them in a subsequent iteration after observing a finality compromise!
- Lower the issuance to finalizers/stakers from 40% to 0.01% for version 1.0, then for version 1.1, if all seems to be going alright, raise it to 0.1%, on the notion that “ramping up” usage (and reliance) on Crosslink is a good way to lower time-to-market for 1.0.
… and so on. These ideas might be untenable, and they are predicated on the idea that we can / should disrupt the ecosystem to some degree (especially if it can be narrowed to mainly disrupting the new finalizer/staking/delegation use cases without disrupting pre-existing use cases). These kinds of approaches may be no-gos if sacrificing some goal “temporarily” causes irreversible harm.
Examples of irreversible harm might be: a finality compromise is 100% unacceptable; or a “temporary” reduction of Orchard privacy causes long lasting brand damage, even though it is “technically” repaired 3 months later in a (fast) NU; or a loss of general network effect that takes too long to recover from; or locking in the kind of “path dependence” @ebfull mentioned above.
Despite how bad those sound, I think we can avoid the worst of “irrecoverable flaws” in a 1.0 and prioritize time-to-market and fast-follow-through, and for me that’s one axis I highly weight.
6 Likes
I wanted to chime in here with some other personal preferences on the trade-offs:
I like both of “reward long term holders more”, but also “facilitate more rapid adoption”. I’m not sure how to compare them. I should point out my personal motivation is to be more rewarded for longer lock-ups (since I’m totally down for them personally), and while I want to avoid personal biases, I’m not sure I fully can, but at least I can be transparent: I get a “good feeling” imagining it. Meanwhile “adoption” is also good. It’s easy to imagine a big wave of adoption, which Zcash deserves, but one big difference is I can personally choose to lock up my ZEC, whereas adoption requires a lot of non-me people to behave a certain way.
Next thought: I’m not sure how to predict how much impacts of these two hypotheses:
- “longer lock-ups mean more secure & better privacy, therefore more adoption”
- “shorter lock-ups means more financial appeal and more adoption”
For these kinds of trade-offs, I really want to learn from more successful product-y people. Are there ways we can A/B test? If not, then within certain grey zones of estimates, I’m almost a coin flip because I just don’t know how we can tell. This is financial engineering and incentives (already outside my expertise and super complex) meets long tail risks of security catastrophes… Hard to design around!
This is a very general reason why “appeal to the judgement of delegators” is an attractive idea to me: future delegators will understand nuances about future emergency conditions that we protocol designers can’t anticipate.
1 Like
I’d also add to this list “shifting the balance of power” since changes to the issuance have an effect on the coin distribution that is difficult or impossible to claw back later. It’s probably arguable how much that matters in general or whether that would be a huge deal in this particular case, but stakeholders (like coinholders) might be really sensitive to this in principle since the staking tokenomics decides whose hands hundreds of thousands of newly minted ZEC end up in.
What is the shielded labs teams answer to preventing, or mitigating against, third party liquid staking tokens that may arise in this dynamic? Proof-of-Stake is inherently centralizing, and while I agree that staking caps (e.g. 32 eth in ethereum) are not real deterrents to this, I wonder if there’s any thoughts.
The fear with LSTs is that they gain tremendous amount of marketshare and effectively gain substantial control of the network.
For example, Lido previously reached a substantial amount of marketshare in Ethereum. In Bitcoin, Lombard has had over 33% control of stake at times which means that Lombard finalizers could effectively halt the network should they so choose (Babylon bitcoin staking requires 2/3s for a valid finality signature)
I think parking this problem for a later date is a mistake and should be addressed head on.
This rationale only holds while PoW continues to be a part of Zcash. One of the key purposes of Crosslink is to safely introduce PoS into Zcash consensus without significantly weakening network security. There is the future that once the PoS side is proven out and support for the PoS half propagates through the ecosystem, block production could be migrated to the PoS side and then the PoW side wound down. It would certainly not be the case that the network would transition from Crosslink to a completely different PoS system. Integration of Crosslink costs us significant protocol complexity for the PoS protocol, with the expectation that it could in theory eventually support the network on its own.
Now, that doesn’t mean the rationale for not including slashing in the initial Crosslink design is invalid, but it is incomplete. If a slash-less Crosslink 1.0 is deployed, and then some future NU several years later transitions to solely PoS, and introduction of slashing at that point becomes necessary, then users that staked under the no-slashing regime would suddenly be susceptible to slashing, which may violate their expectations. I think any Crosslink design that omits protocol-level slashing needs to justify this not only within its immediate context, but also with consideration of the implications of a hypothetical future transition to a PoS-only network.
We’ve already seen similar conversations play out around pool deprecation (which needs to happen, and will be forced to happen in the event of a viable quantum adversary), and there we did state up-front that users should expect that they may need to migrate out of pools, but it’s hard to ensure this is conveyed through all the myriad of ways that people can obtain ZEC. By contrast, for Crosslink the act of staking is inherently centralized (given the current stated cap of 100 active Finalizers), which means it should be much easier to set user expectations at the point when they stake.
1 Like
I recommend looking at successfully deployed systems. Specifically Solana as it is the market leader. Whenever you have questions go see how they solved it.
If you need to slash for double signing do it. Otherwise solve it with code. No other system required a pause button and a court system on validator behavior. These are literally solved problems. Look at Solana.
Unstoppable, private money.
- Adding pause button and/or social court doesnt work
- Forcing illiquidity with lockups that have nothing to do with security doesnt work
- Compromising privacy doesnt work
Zcash is unstoppable, private money today. We cant comprise that. Maybe pure PoW is the way to go.
If a minimalist finality layer that didn’t compromise privacy, didnt add a social court nor force lock-ups beyond the proven security boundary of 2.5 days was proposed that would make sense. Because its just additive.
1 Like
whats the optimal % of circulating supply that should be staked so it makes network secure but doesnt remove all ZEC from shielded pools?
from my view if there was a 40 day unbonding i would stake max 5% of my ZEC
with a 5-14 day unbonding i would be more comfortable to stake close to 50% or more of my ZEC - i would think this makes the PoS more secure to have more staked? tho it reduces the shielded pool quite a bit.
another thing. imo 0.1 ZEC staking should be also option. its currently $5 and would make even more people able to stake a bit. yes the rewards wouldnt be big. but in case ZEC value grows a lot 1 ZEC minimum would make it kinda less accessible to many.
2 Likes
We split up our “milestone 4” into 5 sub-milestones. I’ll work to clarify those more publicly, but real quick the punchline is that we don’t begin implementing the functionality we’re getting push-back on until “4c”, which I estimate will start in Jan 2026.
Also, after we’ve already implemented it, there will be some simple “protocol parameters” (like epoch length or lockup period) which we can relatively easily tweak without much software engineering after the fact.
Sometimes in discussions like this, it can feel like one must convince everyone ASAP, but in reality we can iterate and experiment. (Remember, this is different than a “protocol proposal” like a ZIP, which typically is a complete design, but instead a very early “prototype design idea”.)
4 Likes
I have reservations with liquid staking tokens too. I can’t quite put my finger on it, but I simply don’t trust them.
I’m no PoS expert at all but this is a philosophy worth applying. I’ve repeatedly said that Zcashers have a tendency towards innovation that backfires when we decide to innovate in things that already work fine and are proven effective.
But this is also easier said than done. For my PhD studies, I research how privacy affects software requirements and let me tell you… the landscape SUCKS. Literally, “privacy ruins all the fun”. It imposes restrictions that when ignored, privacy is irreparably lost.
That’s why many times we have this feeling of wheel reinvention. As @zooko describes himself some assumptions completely broke after doing a thorough privacy analysis. 
and things turned out to be a bit more complicated than they were expected to be.
That being said, I have concerns about the 40-day lockup and coin-holder voting.
Staking and casting votes both require a lockup mechanism. If these are independent and incompatible with each other, then voting and staking will be frenemies at best.
@aquietinvestor, has SL thought of the possibility of staking being a form of fund holding attestation that can be proven to cast a vote?
I’m thinking out loud here. would it be possible to make a CHV 3.0 protocol that runs on proofs of funds so that stakers can prove they hold a certain amount of funds that are valid to cast votes?
3 Likes
We still need to evaluate how Crosslink and coinholder voting interact to ensure there are no unintended conflicts and to understand whether they can complement each other.
1 Like
Is it necessary to disclose this information? Is it not sufficient to monitor the finalisers just by knowing the aggregated staked amount for each? This seems like an improvement because the gross changes in the finaliser stake are not known, but finalisers can still be held accountable because the net changes are i.e. 5 users could have staked and 7 users could have unstaked in unknown amounts. This will create ambiguity and make it harder to fingerprint a staker, which I believe would be a big privacy improvement upon the current design.
With the help of the brave browser AI Leo, I was able to do some game theoretical analyse of the design and how it might hold up to typical user and investor interactions. That was one such recommendation it proposed that could improve the design (I get that it could be wrong, but I think it’s worth mentioning).
Some scenarios I wanted to investigate related to how investors might influence the overall privacy of the network, given that it has become very topical in this thread and @zooko is talking about it as a missed tradeoff segment. What I think is been overlooked is the behavioural characteristics of such investors and how i believe they are at odds with enhancing the privacy of the network in the current design. In a nutshell what I have learnt recently is good privacy in this system requires good behaviour and good behaviour is not a priority for a tradfi / accredited investor. This segment of investment will typically act in the following way:
AI Answer: (Behavioral Fingerprinting: Deposit → Stake → Unbond → Sell
-
The investor buys 100,000 ZEC from a KYC exchange and / or OTC desk:
-
Deposits a large sum into Orchard.
-
Stakes the full 100,000 ZEC shortly after.
-
Waits unbonding period.
-
Immediately sells upon release.
-
This predictable behavioral pattern creates a strong temporal correlation:
-
Observers can reasonably infer:
“The entity that staked 100,000 ZEC is the same one that sold 100,000 ZEC 30 days after unbonding began.”When the investor sells immediately after unbonding, it suggests:
-
The funds were never intended for long-term participation.
-
This liquidity signal is economically and behaviorally distinct, making it analyzable.)
-
The real problem here is that investors have no interest in leaving their funds idle in the orchard pool, nor do they have any interest in using the orchard pool for spending ZEC. They will only use it to stake in large amounts and sell upon unbonding. The above suggestion helps with this problem, but it’s still there. Ideally you want to have all staking aspects as shielded transactions, but I understand you can’t because of the security tradeoff. Perhaps it could be a plan to eventually transition the staking cycle to be fully shielded in the future? In the meantime, figuring out some way to do more than just suggest users and investors don’t stake all of their funds (you could implement it at the wallet level in zashi, for example) could be worthwhile.
Shorter staking times introduce a lot of instability and undesirable outcomes in my opinion. I don’t really understand the term liquidity in this context. Like in the banking system, if you want to stay liquid you stay in cash and if you want better returns you lock your funds in some kind of term deposit.
The only difference is that in the case of Zcash (unlike fiat or others POS blockchains) you won’t be debased while in your non staking position since the total supply is fixed (NSM is crucial to guarantee that).
Bottom line you shouldn’t stake 100% of your ZEC holdings, only what you consider to be some kind of long term savings. You can’t have your cake and eat it too.
Came on the forum for a few minutes so I can’t review all but I’ll say that hopefully we can still vote while staking. By hopefully, I mean this is of major importance.
5 Likes