Introduction to Picasso Generalized Restaking Layer
Restaking has been described as a new primitive in crypto economic security that enables the rehypothecation of a token on the consensus layer. Specifically, the process of staking involves a user staking an ecosystem’s native asset to that ecosystem’s validators. The user then receives a receipt token representing this stake. They then “restake” this receipt token with validators again. This mechanism enables users to multiply the crypto economic security (and the yield) of their initial tokens, as they are essentially able to stake the same assets twice, receiving yield and supporting PoS validation both times.
What is Generalized Restaking?
Economic security is a necessary construct for applications building in the decentralized space. Eigenlayer introduced ETH staking. Picasso is introducing restaking of assets on multiple Proof of Stake (PoS) networks to establish cross-ecosystem pooled security to Actively Validated Services (AVSes).
Restaking has been pioneered and popularized by EigenLayer, which is a protocol for restaking ETH on Ethereum. In particular, users staking ETH are able to opt into EigenLayer’s smart contracts for restaking their ETH and thus extending the crypto economic security to additional applications within the ecosystem. EigenLayer thus addresses rising concerns of fragmented security on Ethereum, helping to bootstrap the security of various protocols/applications. EigenLayer’s total value locked (TVL) at the time of writing is over $7.5 billion, indicating that there is a clear demand for restaking.
Despite the benefits of restaking, this concept has largely not yet expanded beyond the Ethereum ecosystem. However, there is a huge potential for restaking on other chains. Leveraging the fact that Picasso is a L1 Cosmos SDK chain that is also a hub for cross-ecosystem IBC, we are able to make this restaking layer cross-chain. Thus, vaults associated with this system will exist exclusively on IBC-enabled chains. Registration and accounting of AVSes are managed on Picasso. Vault contracts are to be deployed on Solana, Picasso and Ethereum in H1. Picasso Generalized Restaking facilitates a broad spectrum of assets from PoS networks. In effect, this will enable a larger supply of tokens with a lower opportunity cost to be restaked, and therefore, decrease the cost of acquiring AVSes.
In this network, validation is powered by operators who accept restaked tokens contributed by anyone. Operators are selected according to governance on Picasso. Their role is to check the smart contract on-chain and use these inputs to construct blocks. The block is finalized when signed by more than ⅔ of validators. Restaked funds are sent to Picasso and encoded on the block as part of the header data, which we create a proof for. The block is stored on our internal ledger in addition to being encoded on the respective chain.
A core rationale behind creating a Restaking Layer is that it enables partial block building in every domain. This addresses the censorship and block proposer agency issues outlined previously.
Architecture at a Glance
Generalized Restaking Flow
The following process outlines the journey of users' LST deposits on a PoS chain, including delegation to AVSes, emission earnings, and un-staking procedures.
Users holding LSTs on PoS chain (e.g. Solana) deposit into the vault contract. At this point no further action is required from the user unless they specify which AVS to delegate their stake to.
The value of the deposit is propagated via IBC to the Orchestrator on Picasso and sent to the accounting contract.
AVSes register and propose an amount to pay for restake in exchange for security.
Restakers earn direct emissions from at least 40% of the revenue generated by AVSes.
When a user un-stakes, they will have to wait for a 7 day un-bonding period and their stake will be withdrawn to their origin address on the origin network.
AVS & Operator Eligibility
Operator Eligibility
- Individuals with a Picasso address can join as Operators, and there is no minimum requirement for the amount of restaked tokens.
- It's possible for an address to function as both a Restaker and an Operator simultaneously, although this is optional.
- Operators have the option to engage in network activities without possessing any restaked tokens. They can receive token delegations from other Restakers or self-delegate using their own restaked tokens.
- To become an Operator, a governance proposal must be initiated on Picasso to become onboarded via on-chain governance.
AVS Requirements
The AVS onboards operators. Operators can select which AVS they wish to validate for. The exact process is detailed in the following manner:
- Once an AVS has been successfully onboarded, their next step involves persuading operators to validate on their behalf.
- Subsequently, operators will typically delegate to the AVS by default.
- Users retain the option to abstain from delegating to the AVS, thus remaining unaligned with the operator to whom they have delegated.
- AVSes must prepare off-chain code for operators to execute customized slashing
- Comply with the verifier interface to enable slashing of any malicious or misbehaved operators and avoid Fishermen.
Requirements for the operators vary depending on the use case of the AVS.
To initiate discussions regarding onboarding your project, please reach out to our team on Discord and complete this AVS Questionnaire.