Shielded Staking on Penumbra

On a proof-of-stake chain, users stake tokens to help secure the network, and in return, the network issues staking rewards for their participation. On every other proof-of-stake chain, this requires each user to publicly record their token holdings. Penumbra is built different. Penumbra is the first chain to create private proof-of-stake, providing privacy for delegators while retaining accountability for validators.

Why is this important?

First, without private staking, holders of the staking token would have to choose between maintaining privacy or helping to secure the network, participate in governance, and receiving staking rewards. Instead, users should have privacy by default, with no loss of capability.

Second, there is no alternative, because Penumbra records all user data privately in a single multi-asset shielded pool. Unlike other private transaction systems, there are no transparent addresses to use. Instead, the entire interchain is our transparent pool.

Third, it follows a key design principle for Penumbra: privacy for individuals, transparency for aggregates or organizations. Penumbra validators have public identities and are accountable for their behavior, but individual delegators can maintain privacy -- or disclose their activity to whomever they wish.

The Challenge of Shielded Staking Rewards

As we described in one of our very first posts, however, shielded staking presents an immediate challenge: how can the network pay out staking rewards, without knowing who the delegators are?

Unlike a transparent chain, where all delegations are public, and the chain can simply credit delegators' accounts with staking rewards, if the delegations are private, the chain has no way to know the amount and duration of each delegation.

Our solution is delegation tokens: protocol-native, validator-specific liquid staking tokens.

Rather than treating "unstaked" and "staked" as different possible states of a single staking token, which the chain must track for each holder, we represent different states as different tokens. Delegating stake to a validator exchanges staking tokens for that validator's delegation token, similarly to shares of a liquidity pool. Undelegating exchanges delegation tokens back for staking tokens. And the exchange rate between staking tokens and delegation tokens prices in what would be a staking reward in other systems.

This design makes all delegations to a particular validator completely fungible. But because delegation tokens are not fungible between validators, the network can still individually slash misbehaving validators. Individual delegators gain privacy, but validators retain accountability.

Some users may want an LST that does create fungibility between validators, by pooling stake over multiple different validators and redistributing slashing risk. Whether a protocol designer likes it or not, this demand exists, and the market will find a way to meet it. Because Penumbra's staking is natively implemented with per-validator LSTs, staked funds are already tokenized, so stake pools can be implemented just by a contract that pools those tokens, rather than having to introduce additional trust assumptions like multisigs.

Shielded Rewards with Validator Exchange Rates

How does the exchange rate mechanism allow the chain to handle shielded staking rewards?

Instead of tracking staking rewards directly, the chain tracks an exchange rate between the staking token and each validator's delegation token. This exchange rate prices in the cumulative staking rewards since genesis. When a user delegates stake to a validator, they exchange their stake for delegation tokens at the current rate. This discounts their share of the delegation pool for the rewards from genesis up to their delegation, which they didn't earn. But now, they are on an equal footing as every other delegator. And later, when they undelegate stake from that validator, the exchange rate will credit them for all of that validator's cumulative staking rewards since genesis.

Since they discounted their share on delegation, this nets out to the continuously compounded staking reward exactly over the period they delegated, without requiring the chain to track that information!

Unbonding and Slashing

For a proof-of-stake system to provide security, it must have a way to slash (penalize) validators who violate the rules of the protocol. The exchange rate mechanism makes slashing extremely easy to implement: to slash a particular validator, the chain just adjusts the exchange rate of their delegation token.

Unbonding is slightly more challenging. If a validator could break the rules, then immediately withdraw their stake, they could escape consequences for their misbehavior. To prevent this, proof-of-stake chains have an unbonding mechanism that delays withdrawals of staked tokens. Like other Cosmos chains, Penumbra has a fixed unbonding delay, tied to the IBC security parameters.

Unlike a Cosmos chain, however, Penumbra's unbonding delay does not lock tokens while they are unbonding. Instead, we add an additional token state: instead of converting delegation tokens directly into staking tokens, an undelegation action converts them into unbonding tokens. These are nominally 1:1 with staking tokens but remain bound to a specific validator and exposed to slashing. Once the unbonding period ends, unbonding tokens can be converted to ordinary staking tokens, accounting for any slashing that occured while the tokens were unbonding.

Because unbonding tokens are liquid, users can transfer or sell them, but because they remain exposed to the validator's behavior, slashing risk is conserved. A user who wants to undelegate sooner than the unbonding period can do so by selling their unbonding tokens to someone else who's willing to take on the slashing risk -- and the discount should reflect the market price for that risk.

Alternatively, an undelegation queue could be implemented using the DEX: delegators who want to undelegate faster can create auto-closing limit orders with their delegation tokens with a slight discount to the protocol-native exchange rate, and be matched against users who want to delegate and see that they can do slightly better than native delegations by taking the other side of the trade.

Getting started

This system is live on the Penumbra testnet, and you can use it today, either as a delegator or as a validator. Testnet tokens have no value, and testnet activity is not incentivized in any way, but this is a great way to play with the software and test it out.

As a Delegator

Staking actions are fully supported in the Penumbra web interface using Prax Wallet, the browser wallet for Penumbra. Use the Discord faucet to request tokens and the testnet frontend to stake, swap, or send tokens. Unlike frontends for transparent chains, this frontend runs entirely on your computer, using an ultralight node embedded in your wallet to index only the data your wallet can view.

As a validator

To run a validator node, check out the Penumbra guide. Unlike Cosmos chains, Penumbra validators have separate identity keys and consensus keys. This allows the validator's long-term identity keys to be defined and kept in cold storage, independently of the mechanism used to sign blocks for a particular network. The Penumbra testnet is a good environment to practice validator key management setups.