Contingent Staking on Cardano
A deep dive into what contingent staking enables on the Cardano network, and the pros and cons of such an upgrade.
Written by @CalvinsBrew
In the last couple of weeks, a firestorm has emerged in the Cardano ecosystem that harkens back to the days of single- and multi-pool operators fighting for favor in the eyes of public opinion (a.k.a. Twitter).
Generally speaking, Cardano is a passionate community. Because of this, the public sphere of debate is usually heated and often becomes more dramatic than necessary (I am also to blame here).
Inflaming the passion, however, was the recent rise in regulatory actions by the SEC. In particular, the debate was ignited by their charge against the centralized exchange, Kraken, for offering unregistered securities through their custodial staking program.
Following the announcement by the SEC, Charles Hoskinson streamed a live video regarding the allegations by the SEC and what that meant for the staking and regulation as a whole. In that talk, he mentioned contingent staking as a possible solution for stake pool operators wanting to comply with local regulations (future and present) when running their stake pools.
And, in traditional Cardano fashion, drama erupted.
So, what is contingent staking and why are so many Cardano community members concerned about it's application? First, you have to understand how staking currently works on the protocol level, so let's recap.
What is Staking?
In the Cardano network, holders of the $ADA cryptocurrency have the ability to delegate their tokens to network pools, which in turn mint blocks of transactions for the network.
Unlike other staking protocols, like Ethereum's recent upgrade from Proof of Work to Proof of Stake, Cardano users do not lose custody of their $ADA. Instead the delegation acts like a vote for a particular community actor, and gives the influence of their "stake in the network" to that pool operator. The higher the stake a pool operator commands, the higher the chance that their pool is chosen by the protocol to mint blocks.
Upon minting a block, the pool and associated delegators receive a reward from the protocol in the form of more $ADA, effectively creating a yield on their $ADA holdings.
This is all well and good, and works quite well in its current form (and even acts as the membership key for The Brew Club!).
As it currently works, however, pool operators have no say in who delegates to their pool. Anyone from anywhere in the world can choose to delegate their $ADA to a pool, including BREW as an example, and there's absolutely nothing we can do as pool operators to stop this transaction from happening.
This is where contingent staking comes in.
What is Contingent Staking?
Contingent staking is exactly the same as regular staking, except that instead of a single signature from the delegator, it requires two signatures: one from the delegator and another from the stake pool they are trying to delegate to.
In essence, contingent staking is identical to a multi-sig transaction (something that already exists on the network for transactions that require more than one signature to be valid).
In order for this to work, a new staking credential would need to be implemented at the base layer of the protocol (similar to how different payment credentials already exist for sending payments), and once implemented a new form for staking would then become possible.
The outworking of this feature would be that, just like you have different kinds of addresses on Cardano such as Payment, Staking, and Enterprise addresses, there would now also be more than one kind of staking credential for your wallet: Regular and Contingent.
When a pool operator spins up a pool, they would then determine if this pool required a signature from the Regular Staking Key or from the Contingent Staking Key.
If they chose to be a Contingent Staking pool, then only delegation transactions signed by the user's Contingent Staking Key and the pool's key would be valid delegations, effectively allowing the pool to make decisions about who could delegate to their pool and who couldn't, since the delegation would also need their sign-off.
Let's say a pool didn't want to go this route, or you already run a pool the current way? Nothing would change for you.
Okay, so why the concern around contingent staking? If it sounds like a pretty cool feature, that's because it is. There's a lot of possibilities that open up with this idea, specifically things like:
- Member-Only Pools: Only qualifying members can stake to the pool.
- DeFi Pools: 100% of rewards are used and invested into higher-yield vehicles for delegators.
- Mission-Driven Pools: 100% of rewards are used to support charities.
- And more!
But why would contingent staking be required for these?
Well, in short, it isn't.
However, it does make it pretty easy to have some sort of conditional agreement tied to a signature, such as any sort of metatdata the pool may want to add to their delegation transaction, like a Terms and Conditions or other type of legal document that the delegator can associate their signature with on-chain and that the pool can verify before supplying their side of the signature.
And yes, for some of these possibilities (including #2 in the list above), those Terms may be things like KYC and AML agreements in order for the pool to comply with local regulations.
In fact, Charles in his original video about Staking and Regulations actually used KYC as the primary example as to why the community might want to integrate contingent staking, and thus this is the primary reason why the conversation around contingent staking has been so heavily leaning on KYC compliance.
And, to be fair, some of the use-cases above do make this attractive from a compliance perspective.
Let's say the pool wants to invest all the funds earned by the pool into DeFi products and promises you a higher return on your $ADA holdings than just what the protocol can give you from normal staking. In order to do this, the pool would need to register with the SEC as offering a security, and ensure that its customers went through KYC and other regulatory requirements before allowing them to delegate and earn higher yields.
But complying with regulation brings up a sore point in crypto, because most joined crypto in order to escape legacy finance.
Businesses or Public Infrastructure
The prevailing argument for contingent staking rests on the idea that running a stake pool is the same as running a business, and that businesses need to comply with their local regulatory requirements in order to stay, uh, legal entities.
This is, of course, an easy argument to make, but it assumes an overly-simplistic view of a crypto worldview heavily dominated by a cypherpunk ideology.
While many run their pools as businesses (even The Brew Club does this and is registered as an LLC in the US), there is an equal if not larger amount of pool operators who view their contribution as simply providing public infrastructure for a system that has historically remained resilient and resistant to centralized control and overreach.
To be fair, this was precisely the ethos upon which Bitcoin was founded and encryption in general, and it is unlikely to be removed from the crypto-sphere without much effort — be it long and gradual or sudden and violent.
And the disparity between those who view running a pool as a business and those who view it as a moral responsibility creates the imbalance of debate that is currently prevailing in the Cardano community. There cannot be sensible dialogue about these things without a consensus on the foundations of what we're all doing here.
It's my understanding, however, that even public infrastructure runs as a business. The customer is simply the public, rather than the consumer, and is often paid for by the government and by the revenue of taxes.
In the context of the blockchain, the public is the delegators and the government is the protocol, so the idea that running a stake pool is akin to running public infrastructure is actually quite accurate and should be preserved as a foundation upon which to view our participation on the base layer of the protocol.
To this point, however, even public infrastructure has employees, expenses, revenue, and operates almost identical to that of a business. However, the question must then be asked: can public infrastructure refuse service to its customers?
I'm not a civil expert here, but my understanding is that the answer is both yes and no.
- No because the public roads are usable for anyone and I don't need to ask permission.
- Yes because while I don't have to ask permission, I do have to follow the rules and some roads may only be for certain types of people, such as construction workers.
In this sense, I don't see a convincing argument to be made that just because a stake pool is public infrastructure that it should also be completely open to anyone all the time. In fact, I see a lot of reasons why it may not be to certain groups of participants.
All that being said though, it's still a gray area as to whether you can qualify a delegator as a customer. In the protocol, there is no business relationship between the delegator and the SPO at least as it pertains to the delegation transaction and rewards.
Even when considering the minimum fee and margin of rewards that the SPO gets to determine when setting up their pool, the $ADA transferred to both delegator and SPO comes directly from the protocol treasury, and not from the SPO himself. In that sense, both the SPO and the delegator and customers of the protocol.
However, it may get fuzzy when considering other ongoing relationships between delegators and SPOs that are beyond that initial transaction of delegation. For instance, many SPOs maintain Discord communities, and within those contexts they may extend additional services for delegators who want to pay more for certain services or products, and this may reinforce the business definition of an SPO.
All in all, there is a lot of terminology in crypto that is yet to be legally defined. In light of that, flexibility within the protocol does allow for an adaptation to changing legal situations that would give a blockchain an edge over its more rigid peers.
Software or Cypherpunk?
Again, the general ethos of crypto is to resist tyranny through unbreakable resilience and security, and this is often referred to as the cypherpunk ideology. To quote it directly:
A cypherpunk is any individual advocating widespread use of strong cryptography and privacy-enhancing technologies as a route to social and political change.
Cypherpunk is not just software — it is activism in the strongest sense. But it is also more than just idealism. Cypherpunks have created much of the freedom we enjoy today within our countries and the privacy we have is almost completely attributable to cypherpunks fighting for the legality of encryption, which the government intentionally tried to regulate into allowing backdoor access when and if it deemed necessary.
Thankfully, this was thwarted and cypherpunks were at the forefront of that fight. Yet, while that is a strong ethos in crypto and why so many of us are here, are these ideals all crypto is? Or can you have cypherpunk pillars in crypto and yet be about more than that?
The maximalist in this sense would say no; that any compromise to the original ethos is a betrayal of the mission in the purest form, and that if you can't have full conviction in the principles of crypto that you should pack up your bags and go home.
I find this viewpoint extremely limiting to the purpose of being cypherpunk, especially in that the goal is widespread adoption of cryptography and privacy-enhancing technologies.
The other ethos of Cardano is to be the financial operating system of a global network, being fair and open and available to the most disenfranchised. I see no reason this can't be accomplished while also promoting cypherpunk principles along the way.
Yet, in order to be a financial operating system used by billions, it must be flexible. There is no way around it, and to accommodate billions you also have to make room for those who aren't cypherpunk in any way whatsoever. Doing so not only creates a better world, it also promotes the message of cryptography by its very nature, creating enormous change throughout the process.
Is Contingent Staking Necessary?
There is disagreement on whether contingent staking is a required feature at this point in time. While some say we're not even close to governmental regulation regarding staking, few are aware of the Infrastructure Bill that was passed recently that does indeed mention KYC requirements for block producers. This hasn't been much of a discussion as the government states that it will not enforce this, but the legal framework is there for them to change their mind at any time, and the entire discussion of contingent staking was presented in light of this and the possible future of a wider crackdown in the United States.
In my mind, contingent staking is another tool in the box, and while many could use it to enable KYC, most wouldn't unless they were required to. KYC is a fraction of the world, and while it doesn't fit into the cypherpunk worldview, it has to fit in some area because blockchain is for institutions and governments too — just in a fairer, more transparent way that can be verified by a network made of up thousands of different people from different groups and perspectives.
And I think that's kind of a win.
One thing I think worth point out is an argument made by PSB in that adding features to the base protocol should only be done if absolutely necessary. Adding additional complexity runs the risk of introducing bugs, making the software bloated, and sometimes for little gain.
If contingent staking is indeed added, it should be well after more pressing matters are dealt with, such as protocol governance.
I'd also like to thank a CS critic, Vanessa Harris, for her contribution and review of this article, and her continued participation in the Cardano ecosystem.
Subscribe for Free!
Stay up to date on the latest Cardano developments through insightful ecosystem commentary, delivered weekly.
We take your privacy seriously. You can unsubscribe at any time at the bottom of each email.