Block-locked Tokens
In crypto, people talk a lot about the concept of incentive alignment.
Different mechanisms for “incentive alignment” have emerged, including staking, vote-escrowed tokens (aka veTokens), and lockdrops. All of these are ways protocols can encourage participants to have skin in the game. The idea is that this skin in the game means the protocol’s interests will become partcipants’ interests.
Yet underlying these mechanisms is the question of how long tokens should be locked. Most determine the lockup on a time basis — weeks, months, years, and so on. But that’s where I think the discussion of incentive alignment starts to unravel. Time is somewhat arbitrary. For instance, what incentives are aligned with a five-year lockup but not a four-year one? How do you determine the right time horizon from one protocol to the next? If the protocol only takes three years to grow to a size people thought would take five years, should participants be allowed to unlock early?
Lockups based on time horizons seem to work directionally (i.e. five years is better than five months) but get hazy on a detailed level.
That’s where block-locked tokens can come in. Blocks are like a crypto-native measure of time. They’re also a better proxy of demand for a protocol. If you know the range of how many transactions per second a block processes, setting a block-based lockup helps align expectations between the protocol and the participants for how much both sides think the protocol will grow over a period of time.
One consideration is that block speed may slow as demand increases. If the goal is to unlock tokens as demand increases (i.e., as the protocol grows), block-locks almost seem to achieve the opposite effect — slowing unlocks as demand increases. But pure demand isn’t the right metric for aligned incentives. Rather, lockers should want protocol growth, sustainability, and success. Slowing block speeds suggests there’s work to be done in scaling supply and the protocol hasn’t reached the level of success lockers aligned upon.
Block-locking may work in a variety of scenarios. Helium’s HIP 41 is exploring the concept with regard to protocol governance / voting shares. I could also imagine block-locking working well airdrops, as a way to encourage the rewarded early users to remain interested in protocol growth.
And I recognize that blocks may not be a perfect metric, either. This post is less about arguing block-locks are the right solution, and more about encouraging alternatives to pure time-based lockups. Incentive alignment is great, but it’s important to really understand what incentives we’re aligning and if the mechanisms we’re using are truly aligned with the goal. On the whole, I’m looking forward to more experimentation and innovation.
