* stake-pool: Add depositor key on init, required on deposit
Some stake pools need to be private, and not allow outside depositors.
Enhance the existing deposit authority in the stake pool be configurable
on initialization, and then require its signature on deposit.
The existing deposit authority is a program address, making deposits
permissionless. This allows a pool creator to set their own deposit_authority on
initialization. In a great turn of events, almost everything else works
the same way!
Here's the current workflow for deposit, where the user calls
stake_program::authorize and stake_pool::deposit in the same
transaction:
* stake_program::authorize assigns staker and withdraw authority to the
stake pool deposit authority
* stake_pool::deposit
- uses the deposit authority to assign authority on the deposited
stake account to the stake pool withdraw authority
- uses the withdraw authority to merge the deposited stake into the validator stake
The deposit authority must "sign" the transaction in order to reassign
authority to the withdraw authority. Currently, as a program address, it
can just do that. With this change, if the deposit authority is set
during initialization, then that deposit authority must sign the
instruction.
There's also a little update for ease-of-use to always do the
stake_program::authorize in the same transaction as stake_pool::deposit.
This way, in case someone tries to deposit into a forbidden stake pool, the
whole transaction will bail and their stake will stay as theirs.
* Address review feedback
* Fix rebase issues
* Add check for transient stake account activation on removal
* Add proper merging logic during update
* Format + clippy
* Add max possible validators
* Disallow removal for any transient stake state
* Reduce number of accounts for BPF instruction usage
* stake-pool: Separate manager from owner
* Add manager pubkey to stake pool
* Differentiate manager functions from owner functions
* Include a `set_manager` function to be used by the owner
* Change the term `owner` to `authority` in the CLI for clarity
* Rename manager -> staker and owner -> manager
* Split staker, manager, and token owner in CLI
* "Do not disturb the boss"
* lending: Update JS tests to solana-test-validator
* Add solana tools install
* Fix oopsie on the path
* Move where deployed programs go
* stake-pool: Add borsh support and size on creation
We can't specify the size in the instruction unfortunately, since we'd
only have 10kb max for the validator list. At roughly 50 bytes per
validator, that only gives us 200 validators.
On the flip side, using Borsh means we can allow the validator stake list
to be any size!
* Add AccountType enum
* Remove V1 everywhere
* Add max validators as parameter and get_instance_packed_len
* Add test for adding too many validators
* Clippy
* stake-pool: Use checked_ceil_div for withdraw calc
When a stake account is totally removed from a stake pool by the
manager, there's a chance that the operation would not take enough of
the manager's pool tokens by 1 due to truncation.
Do a ceiling division instead, and refactor ceiling division into the
math library.
* Use new function name on CLI
* Cargo fmt
* stake-pool-cli: Fix update command, add verbosity
The update command in the stake pool CLI was passing the validator vote
account instead of the associated stake account from the pool, causing
it to fail. Additionally, add more verbose logging, and a dry-run mode
to get simulate transaction information, useful for debugging CLI
failures.
* Run cargo fmt
* stake-pool: Validator stake account initialized with 1 SOL
A validator stake account only has 1 lamport, which means that it will
gain very few rewards per epoch. Its credits_observed is not
be reset each epoch, which makes it practically impossible to merge
into. Get around this by instantiating them with more stake.
* Cargo fmt + fix tests
Jon Cinque
Michael Vines
Jack May
Yuriy Savchenko
dependabot[bot]