docs(addition): add docs for generalised restaking layer (#4454)

docs/docs/intro.md

@@ -27,7 +27,7 @@ slug: /
           </div>
           <div class="card__body">
             <h3>Architecture</h3>
-              Read about the extension of the IBC protocol beyond Cosmos, the Composable Virtual Machine (CVM) and Restaking on Solana.
+              Read about cross-ecosystem IBC, the Composable Virtual Machine (CVM) and Picasso Generalized Restaking.
           </div>
         </div>
       </a>

docs/docs/technology/restaking.md

@@ -0,0 +1,79 @@
+# Introduction to Picasso Generalized Restaking Layer 
+
+Restaking has been [described as a new primitive](https://consensys.io/blog/eigenlayer-a-restaking-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](https://www.eigenlayer.xyz/) 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).
+
+:::tip
+The first opportunity for Restaking on Solana is live. Users have a chance to get in on the action early and earn boosted rewards through [MANTIS games](../technology/restaking/mantis-games.md) - a team staking competition on [mantis.app](https://mantis.app/).
+:::
+
+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.
+
+:::info
+This documentation refers to [Composable Cosmos](../networks/composable-cosmos.md) as Picasso as we are currently undergoing a name change of the Composable Cosmos chain to Picasso.
+:::
+
+In this network, validation is powered by operators who accept restaked tokens contributed by anyone. Operators are selected according to governance on Picasso Cosmos. 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 Cosmos 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**
+
+![architecture](../technology/restaking/genz-restaking.png)
+
+## Key features: 
+
+- **Cross-Chain Backed Assets Restaking**: While Eigenlayer exists as a Restaking layer on Ethereum for ETH and ETH LSTs, Generalised Restaking supports native assets from multiple ecosystems, including Solana, Cosmos, Polkadot, Ethereum, and more. UX is abstracted away from users via CVM. 
+- **Flexible parameters for AVSes**: AVSes can be integrated into the system as needed, with the ability to onboard and offboard at will. AVS builders possess the flexibility to define slashing conditions and customize decentralization parameters according to specific requirements.
+- **Emissions and Revenue Sharing**: Users will be earning a fixed yield and additional share of the revenue generated from AVSes on Picasso by restaking their assets. Additionally, PICA stakers will be earning a portion of the yield as well.
+- **Permissionless onboarding**: PICA governance on Picasso Cosmos cast votes to decide whether to onboard an AVS, and they have visibility into the amount they intend to reward for security purposes.
+
+## 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.
+
+1. 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.
+
+2. The value of the deposit is propagated via IBC to the Orchestrator on Picasso Cosmos and sent to the accounting contract.
+
+3. AVSes register and propose an amount to pay for restake in exchange for security. 
+
+4. Restakers earn direct emissions from at least 40% of the revenue generated by AVSes. 
+
+5. 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. 
+
+<!-- ## Security Measures
+
+- Slashing: An interface will be established that validators must adhere to, similar to the framework in the Solana IBC AVS. 
+
+- Vault contracts implement a 7 day un-bonding period as a crucial security measure to secure against potential vulnerabilities and allow swift response to malicious behavior. There will be an un-bonding period for registering and unregistering AVS.
+
+- The IBC Protocol is the only transport layer utilized for sending accounting messages between different PoS chains and Picasso Cosmos. -->
+
+## AVS & Operator Eligibility
+
+### Operator Eligibility
+- Individuals with a Picasso Cosmos 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 Cosmos 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](https://forms.gle/pYv7P5of5Wb9avkC8).*

docs/docs/technology/restaking/architecture.md

@@ -0,0 +1,103 @@
+# Technical Architecture
+
+Smart contracts utilized on Picasso Cosmos for the Restaking Layer are written in CosmWasm. Contracts in domain specific PoS Blockchains are written in the smart contracting framework of the respective execution layer.
+
+
+![architecture](../restaking/architecture.png)
+### Restaking Vaults 
+A smart contract is deployed on each PoS chain in the system to accept restaked assets to power the restaking layer, along with staking vaults for the Cosmos ecosystem assets on Picasso Cosmos.
+
+Vault Contracts are designed to receive Liquid Staked Tokens (LSTs). The assets that will be initially accepted are: 
+
+1. Solana LSTs 
+2. ETH and ETH LSTs
+3. Monad LSTs and Native Withdrawal 
+4. TRX LSTs 
+5. lsDOT
+6. BNB LSTs 
+7. Cosmos assets via Picasso: 
+   - stTIA/milkTIA 
+   - stDYDX 
+   - stATOM
+   - SEI LSTs 
+   - PICA LSTs 
+   - Berachain LSTs 
+
+### Operators 
+An actor responsible for executing off-chain software logic restaked from the AVS. These operators function between Restaking Layer and the AVS. Operators retrieve their instructions from the AVS Registration Contract, which informs them of the validation tasks.
+
+Upon registration, operators are stored in the Operator Assignment. Within this contract, operators also register for the AVSes they intend to validate. Subsequently, they must obtain delegations to interact with these protocols.
+
+Operators receive delegations from the Delegation Management contract in the following manner: 
+
+1. Users delegate their assets to particular operators to the Vault Contract via the Delegation Management contract.
+2. The total value of the user’s stake is derived from the Accounting Contract. 
+3. Through this delegation, users can select which Actively Validated Services (AVS) they wish to validate.
+4. Operators have the option to accept or decline these delegations. 
+5. The Operator Assignment Contract specifies conditions that delegators must adhere to, including the percentage fee charged by operators.
+6. The Delegation Management Contract facilitates asset unstake calls for users. 
+
+:::note
+When selecting an AVS, Operators and Stakers should be aware of the associated slashing conditions that are set by the AVS.
+:::
+
+### Actively Validated Services (AVSes) 
+AVSes are decentralized applications that require economic security such as roll-ups, L2s, data availability layers, sequencers, dApps, cross-chain bridges, and virtual machines. AVSes define what logic they would like validated by interacting with the AVS Registration contract. In this contract, they will parameterize: 
+
+- Amount of stake i.e. how much security they require.
+- The type of asset or assets accepted.
+- The set of operators they’d like to interact with.
+- Slashing parameters. 
+  - Slashing parameters and proofs of successful behaviour must adhere to a specific framework.
+
+Once the parameters are established, AVSes proceed to engage with the Rewards Distribution contract to allocate rewards corresponding to the desired distribution period. This process defines the rewards rate per unit of security, wherein, for instance, an AVS may pay $50 of their native token for 1 unit of security (e.g., 1 sol of security). Additionally, a length of time must be specified for each epoch by the AVS. A fraction of the rewards (20%) is automatically allocated to PICA stakers.
+
+### Orchestrator 
+
+This Orchestator is a smart contract deployed on Picasso designed to execute fundamental operations including:
+
+- Interfacing with the AVS Registration contract which facilitates registration and unregistration processes.
+- Updating the Accounting Management contract to reflect staked and unstaked amounts.
+- Updating the Accounting Management contract to record the amount slashed.
+  - Sending a notification to the vault to transfer slashed assets to the community pool.
+- Updating the Delegation Management contract with user delegations.
+- Facilitating interactions between the Delegation Management contract and the Operator Assignment contract.
+- Slashing Manager:
+  - Adding contracts authorized to perform slashing.
+  - Revoking slashing permissions from specified contracts.
+  - Monitoring historical stake updates to ensure that withdrawals are only permitted once no middlewares possess slashing rights over the withdrawn funds.
+
+### Verifier 
+The Verifier contract is responsible for verifying that operators execute the consensus of the Actively Validated Services (AVS) correctly. It dispatches slashing operations to the orchestrator and receives IBC proofs of slashing conditions from the AVS. Additionally, it forwards the slashing operations to the orchestrator for the AVS, ensuring thorough validation of the AVS's performance.
+
+### Accounting contract 
+This contract is responsible for updating the state of vaults deployed on various chains based on actions such as {stake, un-stake, slash}.
+
+### Fishermen Protocol
+These are actors who ensure operators are being honest and signal if an operator is misbehaving and needs to be slashed. Anyone is allowed to become a Fisherman and rewards are provided to any misbehaviour reports via Slashing. 
+
+### CVM
+Send stake and un-stake messages from PoS chains to Picasso Cosmos. Users can originate these requests from the PoS chains they restake assets. Additionally, users can (un)delegate their stake to operators of AVSes. These are all operations that are executed on the chain where the user assets live, and are propagated using CVM.
+
+### Slashing Contract
+The process involves detecting malicious behavior, initiating slashing requests, and executing specific steps based on the type of slashing chosen by the AVS.
+
+1. Monitors detect malicious/anomalous behavior and begin a slashing request to the involved chain.
+2. A cross-chain message is sent along Picasso Cosmos, with the stakes frozen for the affected customer and deposit and withdrawals disabled. Pending deposits and withdrawals in the present epoch become invalid.
+3. Proofs are given to the slashing contract
+4. Dependent upon the type of slashing required, a number of steps can then happen:
+   - If a cryptographically provable offense occurs, it is easily proven and implemented into the smart contract.
+   - If consensus-driven slashing is involved, more time/additional proofs are needed.
+   - If a slashing veto is triggered, a lengthier sequence occurs to finalize slashing.
+5. Taking into account the slashing outcome, Picasso Cosmos reaches consensus and the staked amount is updated. The resulting data is sent via Picasso Cosmos to all impacted chains.
+6. User funds are slashed.
+
+### Fee Distribution
+The fee distribution process is carried out in the following manner:
+
+1. The AVS sends a reward proof to the Accounting contract to begin the fee distribution process.
+2. Picasso Cosmos triggers fee distribution process that are set by the AVS.
+3. When consensus is reached, a fee distribution request is sent to appropriate blockchains.
+4. A cross-chain message is sent over Picasso Cosmos to the restaking vault located on the network where the user has deposited their stake. 
+5. This bulk operation further includes fees that must be sent to PICA stakers. 
+6. Restakers on other networks who may have also restaked on the same AVS can claim their rewards.

docs/docs/technology/restaking/governance.md

@@ -0,0 +1,27 @@
+# Governance
+
+The onboarding process for operators occurs following approval by PICA governance on Picasso Cosmos. Similarly, AVSs are required to undergo onboarding via PICA governance. The inclusion of asset types within the restaking layer also follows the same governance process. Any assets subjected to slashing will be redirected to the community pool on Picasso Cosmos.
+
+Initially, the owner of the contracts on Picasso Cosmos will be set to a multisig. In the next stage of governance, the owner of the contracts on will be designated to the Upgrade Authority address. This ensures that PICA governance retains control over the contracts for the purpose of upgradability.
+
+The restaking vault on Solana is currently governed by a multisig until decentralised governance is established. This is composed of a 7-of-9 multisig at address `JD4dNpiv9G24jmq8XQMuxbQPKN4rYV7kue2Hzi1kNT4Q`. As we move toward the launch of SOL IBC, we will look to expand this multisig in the greater pursuit of further decentralization. The **Admin & Upgradability multisig** is responsible for the following:
+
+- Whitelisting tokens
+- Setting the staking cap
+- Setting if the guest chain is initialised or not
+- Upgrading the contract
+
+Signers for the multisig are as follows:
+
+- Miguel Matos — Board member, Composable Foundation. Professor at the Universidade de Lisboa & Researcher at INESC-ID.
+- Dan Edlebeck — Advisor, Composable
+- Blas Rodriguez — CTO, Composable
+- Joe DeTommaso — Head of Strategy, Composable
+- Jafar Azam — Product Owner, Composable
+- Dhruv D Jain — Research Analyst, Composable
+- SolBlaze — bSOL LSD
+- Don Cryptonium — Community Member
+- Polkachu — Validator Operator
+
+### Deployed Contracts
+Currently, the Solana vault contract has been deployed on mainnet and is accepting restaked Solana LSTs. The contract address is `BoNnRkatYrN7ckA9oAU4e7cHYfwKPgLEuzkKg4LWaHeH`.

docs/docs/technology/solana-restaking/mantis-games.md → docs/docs/technology/restaking/mantis-games.md

@@ -1,6 +1,6 @@
 # MANTIS Games
 
-In order to bootstrap liquidity on the [restaking layer](../solana-restaking), there will be a team competion in phase 2 of MANTIS Games. The MANTIS Games involve the following phases, all designed to make participation maximally enjoyable and rewarding:
+In order to bootstrap liquidity on the [restaking layer on Solana](../restaking/vaults.md), there will be a team competion in phase 2 of MANTIS Games. The MANTIS Games involve the following phases, all designed to make participation maximally enjoyable and rewarding:
 
 ## Phase 1 - NFT Auction 
 Phase 1 introduces teams: during the course of MANTIS games, users can register to join a team on the MANTIS app. Along with your team, you will be able to participate in various competitions on [MANTIS](https://mantis.app/).

docs/docs/technology/restaking/roadmap.md

@@ -0,0 +1,15 @@
+# Roadmap
+
+The rollout plan for Picasso Generalized restaking will proceed as follows:
+
+1. Initial implementation of the [Restaking Vaults on Solana](../restaking/vaults.md).
+2. Launch of the first [AVS for Solana IBC](../restaking/sol-ibc-avs.md).
+3. Expansion to include vaults for Cosmos ecosystem assets on Picasso.
+4. Launch of Restaking Layer on Picasso including all the necessary contracts.
+5. Begin onboarding AVSs.
+6. Migration of Solana IBC AVS slashing parameters to Picasso.
+7. Validators of the AVS for Solana IBC act as operators of this AVS, they have the opportunity to operate other AVSes in the future. 
+
+:::info
+As the generalized restaking layer contracts are still in the development phase, the slashing process is currently managed by the first AVS for Solana IBC. Upon the launch of the Orchestrator contract, slashing logic will transition to be overseen by the orchestrator on Picasso.
+:::