# introducing virya i will not give a one-liner about virya right now, before understanding what and why virya is, we first need to be familiar with the crisis ethereum is facing ## centralization of stake -- crisis for ethereum ### delegated proof of stake ethereum changed it's consensus from POW to POS during merge by splitting the chain into 2 chains - execution and consensus layer. ![image](https://hackmd.io/_uploads/B15fYqNwR.png) while implementing new consensus algorithm, ethereum chose to go with casper-ffg which was vanilla POS (you need to stake multiples of 32 ETH to be eligible to run a node, can't stake less than 32 ETH) instead of opting for dPOS (delegated proof of stake) dPOS would've helped ethereum users to stake as little as 0.1 ETH and delegate it to a validator, who will then use the stake to vote on blocks and earn and distribute rewards to delegators. ethereum devs argued that dPOS will lead to centralization because most of the chains who have implemented dPOS have only ~100 validators, but since then solana, who is a dPOS based network has crossed ~3000 validators. the main issue with previous dPOS chain was the message overhead, solana solved that and was able to scale dPOS beyond 100 validators. dPOS has clear benefits over current ethereum staking structure, any normal user would've been able to stake with any staker, from solo/home staker to institutional staker in one-click and amount can be as less as 0.1 ETH, but instead of that we currently have a system where users can only stake multiples of 32 ETH (32, 64, ...), they need to run their own validator or trust someone with validator keys to run a validator for them. ### makeshift delegated proof of stake > markets adapt. ethereum didn't add dPOS so rocketpool, lido and others started implementing dPOS at application level, enabling any user to deposit any amount of ETH into their smart contract, which will then be given to node operators in their respective network for validating ethereum. this makeshift dPOS was implemented by having a single staking contract where anyone can deposit eth, staking contract will then give eth to node operators based on some rules which differ from protocol to protocol - lido dao accepts node operators through a centralized filtering process and then a dao voting process - rocketpool is decentralized, anyone can become a node operator and deploy a minipool, where they will be required to add 8 or 16 ETH of their own with 10% of the value staked in RPL (rocketpool token), then they will receive the remaining eth from staking contract to start the validator these protocols didn't stop at this, they started giving out ERC-20 tokens for user's stake, lido gave stETH and rocketpool gave rETH. lido won the battle against rocketpool because stETH cultivated a deeper liquidity across pools and thus wider adoption across defi. rocketpool's model is also very self limiting, where if they don't add many node operators, they will be bottlenecked by how much eth they can intake, which is why on their homepage, you just buy rETH off secondary markets. --- due to choices of ethereum community, we are now stuck with a very bad version of POS, we have increasingly more centralization of stake than solana and the craziest thing about this is that we haven't seen anyone meaningfully working towards decentralizing stake and propose actual solution which solve these. lido today (july 2024) controls ~29% of the stake, it reached to ~33% at it's peak, cexs combined control ~20% and now lrt protocols are new which control ~8-10%. centralization will increase as these type of market tend to centralize if not forced otherwise. we can't depend upon lido and other cexs to self limit themselves, any normal person wouldn't just self limit themselves, lido today earns more than $1B in fees (btw this isn't shared with their token holders), don't you think they want to increase that? there are many arguments to be made about lido not being centralized, that they have 29 operators and are actively working towards decentralizing it. some of it is true, some of it isn't. they have 29 operators that were selected through a centralized process, only allowed to run the node a certain way, using whitelisted relays, all of them are institutional operators. there are also concerns around other factors considered for decentralization like geographic and client diversity which many of them lack. we need a force which can stop ethereum's stake from centralizing and actually align incentives in a way that ethereum's stake decentralizes. ### what do we count as stake decentralization? more entities controlling stake -- even if it's little, it matters more encouragment/incentives for home stakers to operate increased nakamoto score, currently it's 1 ## introducing virya virya's mission is to decentralize ethereum -- distribute stake, increase geographical and client diversity and major of all, bring back the community culture that was built on ethereum for more than 8+ years but became non-existent since mid-2023. virya helps communities to permissionlessly deploy staking pools with lsts, and a multi-asset liquidity pools supporting deep liquidity and facilitating trade between lsts. issuer can deploy lsts for various usecases and promote home/sophositicated stakers to start validating on behalf of them. for example, **zachxbt** launching his own lst called **zachETH**. they will not need to run their own infra, infra can be handled by a home staker but they can have another income stream for securing our ecosystem while also decentralizing ethereum each deployed lsts will have a custom yield module which issuer can modify to create new yield usecases for it's users, possibly helping node operators earn more rewards than usual staking. multi-asset liquidity pool will help absorb the adverse condition of depegging as it will have very deep liquidity of multiple lsts and ethereum, as well as having access to virya protocol buffer (more on this later) ### game of incentives every protocol is a function of aligning incentives of multiple types of users that are involved in them. alignment of incentives should happen with a single goal in mind. for virya, it is to decentralize ethereum stake we have 3 types of users - staker - node operator - issuer defining incentives for each of them - staker - <ins>**work:**</ins> stake ethereum and receive lst - <ins>**incentive:**</ins> lst with a deep liquidity, acceptance across defi ecosystems and other chains - node operator - <ins>**work:**</ins> operate nodes for lst issuer (can be lst issuer themselves) - <ins>**incentive:**</ins> more liquidity to run more validators and earn more commission - issuer - <ins>**work:**</ins> organize community around unique or better usecases of lsts, more on this later - <ins>**incentive:**</ins> attract more liquidity through new reward usecases and use the node infrastructure for possible business or open source purpose in a nutshell, issuer can seamlessly issue lsts around various usecases, staker will be able to access their unique and better yield while also having access to deep liquidity pools and defi integration and node operators will get more stake assigned to them with time, thus increasing their rewards. this makes virya to be at a perfect spot, where all of the parties have aligned their incentives which benefits themselves as well as ethereum protocol and our quest towards improving it's decentralization. ## how does virya works? virya has 2 major parts in it's protocol - permissionless lst issuer - multi-asset liquidity pool let's go over each of them and understand how it works ### permissionless lst issuer permissionless lst issuer or plt for short is a set of smart contracts and oracles which will help us deploy lsts, manage rewards among other things ```mermaid graph TD subgraph execution chain Staker[Staker] SC[Staking Contract] Issuer[LST Issuer] BC[Bond Contract] SP[Stake Pool] MP[Marketplace] OP[Operator] WQ[Withdrawal Queue] RM[Reward Manager] RV[Reward Vault] OC[Oracle Contract] SPo[Smoothing Pool] end subgraph offchain O[Oracle] Node[Node] end subgraph beacon chain R[Rewards] end Staker -->|deposits| SC Staker -->|withdrawal request| WQ OC -->|reports| SC Issuer -->|owns| SC Issuer -->|owns| BC SC -->|mints LST| Staker SC -->|gets bond amount| SP SC --> |executes custom reward logic| RM OP -->|registers| MP MP <-->|matches| BC BC -->|deploys for new operator| SP WQ -->|access buffer liquidity for unstaking| SC O --> |reports data about cl and el rewards| OC R --> |fetches data| O Node -->|deposits el and cl rewards| RV WQ -->|access buffer liquidity for unstaking| RV RV -->|share opt-in operator rewards | SPo ``` lst issuer deploys 3 contracts - staking contract - entrypoint contract for user's stake, oracle, liquidity buffer, among other things - deployed through virya's factory contract - reward manager - use the yield/reward in a unique way, different for each issuer - virya provides the interface - issuer needs to write the contract, deploy it and pass address while deploying staking contract - bond contract - define rules for which operator will be eligible to operate - virya provides the interface - issuer needs to write the contract, deploy it and pass address while deploying staking contract ### marketplace virya will have a marketplace to facilitate the demand of operators among lst issuer. node operators can register onto marketplace with how many validators they can run. whenever staking contract has multiples of 32 eth, it will activate bond contract (which has the operator eligiblity rules), then it will trigger marketplace. marketplace will execute a FCFS auction, any operator who is eligible can execute the transaction and start the process of becoming an operator. operator will then have 48 hours to complete the onboarding process. ### onboarding operators bond contract will also have an `onboard` function which will onboard selected operator. based on the logic, operator will either need to bond some eth and then receive their stake from staking pool or they will receive all 32 eth from staking pool -- it all depends on the logic of `onboard` function once they are onboarded and have setup validator on their system, they will need to point their withdrawal and fee recipient address to staking contract's address. ### custom reward/yield manager issuers can use lst yield in whatever way they want. let's go over some examples, they range from normal to very crazy **uniswap** launches their own lst - **uniETH** instead of launching liquidity pools with wETH, uniswap can enable launching pools denominated in **uniETH**. depositers will earn extra yield of staked/restaked eth (with other incentivies through customized rewards). it will also help uniswap to expand their brand while also decentralizing ethereum. similarly, **aave** can launch their own **aaveETH** -- a cross chain lst earning more yields on aave. *my favourite example* -- **zachxbt** launching his own lst called **zachETH**. they will not need to run their own infra, infra can be handled by a solo staker but they can have another income stream for securing our ecosystem while also decentralizing ethereum one more good example -- **pudgy penguin** launching **pudgyETH**, using the yield to give **pudgy toys to underprivileged kids** **yuga labs** launching **apeETH**, turning yield into apecoin for stakers. **mr. beast** launching **mrETH** and using the yield generated from lsts for many of his good work. custom reward/yield manager has a function `useRewards` which will be called by staking contract once our beacon chain oracle reports to them. ### withdrawal queue and buffer whenever someone deposits ethereum into the staking contract, the eth is left there for some time before it can be used to stake with an operator (because of ethereum's 32 eth stake limit). also, rewards accured on beacon chain (when withdrawed) and execution chain will be deposited into rewards vault. till then, this liquidity can be used as a buffer for anyone looking to withdraw their staked ethereum. if buffer is empty or has less available liquidity, withdrawal will be added into withdrawal queue and be processed either when we have liquidity in buffer or by unstaking a validator (if needed) user's can also use our multi-asset liquidity pool to directly convert lst to eth. --- ### how can we decentralize other aspects? virya wants to meaningfully decentralize ethereum and it will not just happen by only decentralizing stake, other factors also matter like geographic, client, builder/searcher/relay, diversity and share of home vs institutional operators across a set of operators. ethereum has many el and cl client implementation, including but not limited to - execution client - geth - reth - nethermind - besu - consensus client - lighthouse - prysm - lodestar - teku - nimbus we cannot force anyone to use a certain client or relay or anything. we can definitely encourage operators to use diverse implementation of software, so the decentralized stake can be operated by an equally distributed operators in terms of geography and client diversity. virya and it's community will conduct a research and make a list of under-represented elements in geographical, client and builder/searcher/relay diversity. this will help us to give incentives to any operator who follows/uses any of these things. incentives will be given by virya and it's partners (optional) in the form of possibly (not fixed) xp boost, tokens or preference during marketplace fcfs auction. ## multi-asset liquidity pool virya multi asset pool or VMA is a liquidity pool that contains multiple lsts and allows any lst to any lst swaps in an efficient manner. ```mermaid graph TD C -->|Yield-bearing| A A[User] -->|Deposits LST| B[VMA] B -->|Issues| C[VIM Tokens] B -->|Contains| D[Multiple LSTs] B -->|Allows| E[LST to LST Swaps] F[Oracle] -->|Provides| G[LST Prices] G -->|Used for| E ``` ### yield bearing token for liquidity pool -- $VIM ```mermaid graph TD H[Staking Rewards] -->|Contributes to| I[VIM Yield] J[Trading Fees] -->|Contributes to| I K[Custom Rewards] -->|Contributes to| I ``` depositing lst in this pool, users get $VIM tokens in return, which are themselves lsts and yield-bearing tokens. $VIM is a yield-bearing token as its yield is the weighted average of the staking rewards of all the lsts in the pool, plus trading fees earned from the pool, plus custom rewards from lst issuers. ### pricing mechanism of the pool ```mermaid graph TD L[Dynamic Fees] -->|Encourages| M[Pool Rebalancing] ``` the price for each lst is dependent on eth balance on cl and rewards (priority fee, mev) accumulated on the execution layer, which comes from an oracle. this price is then used to calculate the exchange rate for lst to lst swaps. for swapping, dynamic fees are implemented in order to encourage swaps that help rebalance the pool. ### benefits for users ```mermaid graph TD N[User Benefits] -->|Includes| O[Staking Rewards] N -->|Includes| P[Custom Rewards] N -->|Includes| Q[Restaking Rewards] N -->|Includes| R[Trading Fees] N -->|Access to| D[Deep Liquidity Pool] N -->|Access to| X[Defi Integrations] ``` users will earn more interest on their lst by simply depositing them into the virya multi asset pool. they will earn the staking rewards, custom rewards from lst issuers, restaking rewards, and multi asset pool trading fees. users also benefit from having a very deep liquidity of lsts, thus decreasing the chances of getting bad prices. also, as there are multiple lsts, smaller lsts can always swap to larger lsts to access deeper liquidity pool. ## (re)staking restaking has been making headlines for quite some time now. it involves staking the staked assets to secure non-ethereum networks. so, more than 1 network will be secured using the same asset. it benefits the staker and node operator, by helping them earn more yield and also airdrops for involved protocols. we are also working on virya restaking -- aggregation of multiple restaking providers. if an lst issuer wants to opt-in to virya restaking, they will need to deploy a contract `Restaking Module`, which will also deploy it's own liquid restaking token. each lst issuer can have their own default restaking strategy, where they can choose which AVSes the restaked assets can secure, or user can create their own strategies through user strategy manager which can secure any AVSes they want. users/issuer also needs to allocate % shares to a restaking protocol, if issuer wants to only support eigenlayer then they will allocate it 100%, if they want to divide equally between eigenlayer, symbiotic and karak then each protocol's secured AVSes will be allocated 33.33% of the strategy. now everyone has the opportunity to maximise risk, rewards or any other parameter based on their liking. **flow of (re)staking** ```mermaid graph TD Staker SC[Staking Contract] RM[Restaking Module] RS[Restaking Strategy Manager] DS[Default Restaking Strategy] US[User Restaking Strategy] Supported{supported by restaking protocols?} Mint[/Deposits into VMA Pool and mints $VIM/] Staker -->|deposits| SC SC -->|mints LST| Staker Staker -->|deposits| RM RM -->|mints LRT| Staker RM --> Supported Supported -->|yes| RS Supported -->|no| Mint Mint --> RS RS --> DS RS --> US ``` ## roadmap virya's roadmap for the next 6 month involves - development and audits - launching testnet and mainnet - permissionless lst issuer - VMA - (re)staking - gain adoption for $VIM across defi application - help communities launch lsts and lrts ## conclusion virya will help ethereum decentralize stake, encourage home stakers and bring back the community centric approach towards protocols while managing the incentives (wants) of all the parties involved in this process. we are building virya not just because its a very untapped potential market, but to meaningfully decentralize ethereum and bringing back the cypherpunk culture again which ethereum had in it's earlier days.