restaking-v2: added restaking program with tests

Anchor.toml

@@ -5,10 +5,12 @@ skip-lint = false
 [programs.devnet]
 restaking = "8n3FHwYxFgQCQc2FNFkwDUf9mcqupxXcCvgfHbApMLv3"
 solana_ibc = "2HLLVco5HvwWriNbUhmVwA2pCetRkpgrqwnjcsZdyTKT"
+restaking_v2 = "BtegF7pQSriyP7gSkDpAkPDMvTS8wfajHJSmvcVoC7kg"
 
 [programs.localnet]
 restaking = "8n3FHwYxFgQCQc2FNFkwDUf9mcqupxXcCvgfHbApMLv3"
 solana_ibc = "2HLLVco5HvwWriNbUhmVwA2pCetRkpgrqwnjcsZdyTKT"
+restaking_v2 = "BtegF7pQSriyP7gSkDpAkPDMvTS8wfajHJSmvcVoC7kg"
 
 [registry]
 url = "https://api.apr.dev"
@@ -20,7 +22,8 @@ wallet = "~/.config/solana/id.json"
 [workspace]
 members = [
   "solana/restaking/programs/restaking",
-  "solana/solana-ibc/programs/solana-ibc"
+  "solana/solana-ibc/programs/solana-ibc",
+  "solana/restaking-v2/programs/restaking-v2"
 ]
 
 [scripts]

Cargo.toml

@@ -9,6 +9,7 @@ members = [
     "common/*",
     "solana/allocator",
     "solana/restaking/programs/*",
+    "solana/restaking-v2/programs/*",
     "solana/signature-verifier",
     "solana/solana-ibc/programs/*",
     "solana/trie",

solana-test.sh

@@ -10,5 +10,6 @@ cd ../..
 solana program deploy target/deploy/write.so
 solana program deploy target/deploy/sigverify.so
 cargo test  --lib -- --nocapture --include-ignored ::anchor
+cargo test  --lib -- --nocapture --include-ignored ::restaking
 find solana/restaking/tests/ -name '*.ts' \
      -exec yarn run ts-mocha -p ./tsconfig.json -t 1000000 {} +

solana/restaking-v2/README.md

@@ -0,0 +1,140 @@
+# Restaking
+
+The high level flow of the program is given in the image below.
+
+![Flow of restaking](./restaking-flow.png)
+
+## Accounts
+
+- Vaults: The vaults are created for each whitelisted token. Vaults
+  are token accounts. The authority of the account is a PDA which
+  means the program controls the vault and any debit from the vault
+  has to go through the smart contract.
+
+- Receipt Token Mint: The receipt token mint is a NFT which is the
+  seed for the PDA storing information about stake amout, validator
+  and rewards. For more information, refer:
+  https://docs.composable.finance/technology/solana-restaking/vaults/#receipt-token
+
+- Staking Params: This is a PDA which stores the staking parameters
+  and also is the authority to `Receipt Token Mint` and `Vaults`.
+
+- Vault Params: PDA which stores the vault params which are stake time
+  and service for which it is staked along with when rewards were
+  claimed.
+
+## Instructions
+
+When the contract is deployed, the `initialize` method is called where
+the whitelisted tokens, admin key and the rewards
+token mint is set. Initially the `guest_chain_initialization` is set to
+false. Any update to the staking paramters can only be
+done by the admin key. A token account is also created for the
+rewards token mint which would distribute the rewards. Since the
+authority is PDA, any debit from the account will happen only through
+the contract (only in `claim` method for now). After that the users
+can start staking.
+
+- `Deposit`: User can stake any of the whitelisted token. The tokens
+  are stored in the vault and receipt tokens are minted for the user.
+  A CPI (cross program invocation) call is made to the guest chain
+  program where the stake is updated for the validator specified.
+
+- `Withdrawal Request`: Users can request for withdrawal and after the
+  unbonding period gets over, the tokens would be withdrawn. In this method,
+  the receipt NFT would be transferred to an escrow account and the receipt
+  NFT token account would be closed. All the pending rewards are transferred
+  in this method and users wont be eligible for rewards during the unbonding
+  period.
+
+- `Cancel Withdrawal Request`: Withdrawal request set by the user can be 
+  cancelled as long at they are under unbonding period or if the withdraw 
+  has not been executed yet. They would get back their receipt token and 
+  withdrawal request would be cancelled.
+
+- `Withdraw`: Users can only withdraw their tokens after the unbonding
+  period ends. When user wants to withdraw the tokens, final stake amount
+  is fetched from the guest chain. The receipt token is burnt. A CPI call
+  is made to the guest chain to update the stake accordingly.
+
+- `Claim Rewards`: Users can claim rewards without withdrawing their
+  stake. They would have to have to own the non fungible receipt
+  token to be eligible for claiming rewards.
+
+- `Set Service`: Once the bridge is live, users who had deposited before
+  can call this method to delegate their stake to the validator. Users
+  cannot withdraw or claim any rewards until they delegate their stake
+  to the validator. But this method wont be needed after the bridge is
+  live and would panic if called otherwise.
+
+- `Update Guest chain Initialization`: The admin would call this method
+  when the bridge is up and running. This would set `guest_chain_program_id`
+  with the specified program ID which would allow to make CPI calls during
+  deposit and set stake to validator.
+
+- `Update token Whitelist`: The admin can update the token whitelist.
+  Only callable by admin set during `initialize` method.
+
+- `Withdraw Reward Funds`: This method is only callable by admin to
+  withdraw all the funds from the reward token account. This is a
+  safety measure so it should be called only during emergency.
+
+- `Change admin Proposal`: A proposal set by the current admin for 
+  changing the admin. A new admin is proposed by the existing admin
+  and the until the new admin approves it in `accept_admin_change`,
+  the admin wont be changed.
+
+- `Accept admin change`: The new admin set by the existing admin is
+  exepected to call this method. When the new admin calls this method,
+  the admin is changed.
+
+- `Update Staking Cap`: Method which sets the staking cap which limits
+  how much total stake can be set in the contract. This method expects
+  the staking cap to be higher than previous to execute successfully.
+
+## Verifying the code
+
+First, compile the programs code from the `emulated-light-client` Github
+repository to get its bytecode.
+
+    git clone https://github.com/ComposableFi/emulated-light-client.git
+    anchor build
+
+Now, install the [Ellipsis Labs verifiable
+build](https://crates.io/crates/solana-verify) crate.
+
+    cargo install solana-verify
+
+Get the executable hash of the bytecode from the Restaking program that was
+compiled
+
+    solana-verify get-executable-hash target/deploy/restaking.so
+
+Get the hash from the bytecode of the on-chain restaking program that you want
+to verify
+
+    solana-verify get-program-hash -u <cluster url> \
+        8n3FHwYxFgQCQc2FNFkwDUf9mcqupxXcCvgfHbApMLv3
+
+**Note for multisig members:** If you want to verify the upgrade program buffer,
+then you need to get the bytecode from the buffer account using the below
+command. You can get the buffer account address from the squads.
+
+    solana-verify get-buffer-hash -u <cluster url> <buffer address>
+
+If the hash outputs of those two commands match, the code in the
+repository matches the on-chain programs code.
+
+## Note
+
+- Since the rewards are not implemented yet on the Guest Chain, a nil value is
+  returned for now.
+
+- Oracle interface is yet to be added to fetch the current price of staked
+  tokens as well as the governance token in the Guest Chain.
+
+- Users who have deposited before the Guest Chain is initialized can choose the
+  validator in one of three ways(Yet to be implemented):
+  - choose a validator randomly,
+  - choose a validator from the list of top 10 validators chosen by us or
+  - choose a particular validator.

solana/restaking-v2/migrations/deploy.ts

@@ -0,0 +1,12 @@
+// Migrations are an early feature. Currently, they're nothing more than this
+// single deploy script that's invoked from the CLI, injecting a provider
+// configured from the workspace's Anchor.toml.
+
+const anchor = require("@coral-xyz/anchor");
+
+module.exports = async function (provider) {
+  // Configure client to use the provider.
+  anchor.setProvider(provider);
+
+  // Add your deploy script here.
+};

solana/restaking-v2/programs/restaking-v2/Cargo.toml

@@ -0,0 +1,31 @@
+[package]
+name = "restaking_v2"
+version = "0.1.0"
+description = "Created with Anchor"
+edition = "2021"
+
+[lib]
+crate-type = ["cdylib", "lib"]
+name = "restaking_v2"
+
+[features]
+# added so that we can compile this along with `solana-ibc` with mocks features. Currently unused.
+mocks = []
+no-entrypoint = []
+no-idl = []
+no-log-ix-name = []
+cpi = ["no-entrypoint"]
+default = []
+
+[dependencies]
+anchor-lang = { workspace = true, features = ["init-if-needed"] }
+anchor-spl = { workspace = true, features = ["metadata"] }
+solana-ibc = { workspace = true, features = ["cpi"] }
+solana-program.workspace = true
+solana-signature-verifier.workspace = true
+
+[dev-dependencies]
+anchor-client.workspace = true
+anyhow.workspace = true
+spl-associated-token-account.workspace = true
+spl-token.workspace = true

solana/restaking-v2/programs/restaking-v2/Xargo.toml

@@ -0,0 +1,2 @@
+[target.bpfel-unknown-unknown.dependencies.std]
+features = []