Update staking programs docs.

Author: RustNinja

solana/staking/README.md

@@ -1,23 +1,50 @@
-# Restaking V2
+# Staking
 
-This program was built to make it easier to keep track of deposits to the restaking vaults and make use of fungible receipt tokens as opposed to using NFTs in previous version which had a few drawbacks for it to be used as an yield for the rollup.
+This program was built to allow stake MANTIS tokens for anyone.
 
-The drawbacks of the previous restaking program
-- The depositors were given an NFT as a receipt token which meant that there were no partial withdrawals.
-- Since the users could choose the validator to which they deposit to, the token deposited to one validator is different from the token deposited to another validator. Which means if the token is restaked and bridged to the rollup, then there would be a token for each validator even if they are same token. 
+# Rewards for staking:
+Admin able to call submit_epoch_rewards_by_admin transaction to deposit funds as rewards for next epoch. Epoch is the timeslot that admin specified during initiation of staking contract.
 
-For example: JitoSOL deposited to validator A and B would be different on rollup even though it is the same token on Solana.
+# Modes:
+- Mode 1. User stake their token into the contract and staking's PDA hold users stake untill user withdraw it.
+- Mode 2. (liquid staking version) User stake MANTIS and recieves back lsMANTIS based on exchange rate lsMANTIS/MANTIS
 
-So the new restaking program was built specifically to support restaking of tokens before bridging to rollup and use fungible receipt tokens.
-These are changes which were introduced in the new version.
-- Users cannot choose which validator they delegate their stake to since their stake is equally divided among the validators specified in the program.
-- If one of the validator gets slashed, the amount is slashed equally among the validators.
-- A fungible receipt token is issued instead of a non fungible one.
-- There is no unbonding period since all the validators get slashed equally.
-- Allow deposits of tokens other than LSTs with the use of oracles.
+Admin can turn of/on any of this modes anytime.
+
+Vesting/Staking connection:
+Only staking mode1 (non liquid staking version) communicates with vesting contract to notify via CPI user's stake/unstake amounts.
+
+# EpochsAccount
+
+EpochsAccount is the PDA that correspond to specific epoch, so epochs changed each X time depends on admin settings. When admin submits rewards for each next epoch then admin also create EpochsAccount to store:
+- how many rewards should be distributed to stakers of that epoch
+- amount of tokens that will join as an active stakes in next epoch
+
+
+# Claim rewards:
+
+- Mode 1 (non liquid staking version) user should manually call claim_reward_mode_1 instruction to claim reward for all epochs in past that they participates as an active stakers.
+
+- Mode 2 (liquid staking version) where 2 tokens participate in the process lsMantis and Mantis. initial lsMantis:Mantis ration is 1:1. Once Admin submit rewards for epoch the price of lsMantis going up compared to Mantis because lsMantis contains accomulative rewards for all prev epochs.
+
+# Unstaking
+
+- Unstaking in mode 1 (non liquid staking). User call unbond to usntake and then wait unstaking period(specified by admin during initialization process). After unstaking period user can call withdraw unbonding to recieve Mantis back.
+
+- Mode 2 (liquid staking). User executes unbond_staking_mode_2 to burn lsMantis and only after usntaking period will be able to executues withdraw_staking_mode_2 to recieve back Mantis back.
+
+
+# CPI call to vesting contract
+
+Only mode 1 (non liquid staking) stake and unstake instractuction call update_stake CPI on vesting contract to update stake/unstake position of user. 
+
+Stake/unstake has 2 versions:
+
+- the version that executes CPI update_stake to notify vesting contract 
+
+- the version that NOT executes CPI update_stake
+
+Because some users does not participate in vesting schedules they do not need to notify vesting contact and UI are not forced to pass list of accounts of vesting contract for that user and able to call stake/unstake version that not related to vesting contract at all.
 
-This program can only be called by the bridge contract. If people just want to restake directly and dont want to bridge, they can do it via restaking-v1 program.
 
-## Oracles
 
-For tokens others than LSTs which have a different value than SOL, we need to use oracle to get their current price and then update the stake. But since the stake is recorded in lamports in the guest chain, everytime the price changes we would need to update the stake. To do this, we store the delegations of the particular token locally and get the price on every interval set during initialization. Every time the price is updated, we calculate the difference and update the price on the guest chain. This would make sure that the stake on guest chain is always up to date. Whenever new deposits are made, it would use the stored price rather than from the oracle. But if the price is stale then the deposit would be rejected. This is a better way of updating the stake using oracle where we need to update it once for all the deposits for a particular token during an interval.