While going back through the docs, I ended up doing a lot of the stake
pool CLI items:
* Deposit / withdraw command: Use associated token account by default
* Create command: Allow passing the stake pool and mint keypair (useful
for testing)
* Create command: Split the transaction for pool creation (required to get under the
transaction size limit)
* Add / remove validator command: take a validator vote account rather than stake
account, which makes integration from outside tools a lot simpler
* Update command: add a `--force` flag to force the update
* Update command: add a `--no-merge` flag to not merge while updating
(useful to allow the pool to work, even if the transient stake
accounts are unmergeable)
* Withdraw: Add `--use-reserve` flag to withdraw from reserve
* Withdraw: Add `--vote-account` arg to specify which validator to
withdraw from
The stake pool expects pool tokens to be delegated to the withdraw
authority before performing a withdrawal. If a user delegates too many
tokens to the withdraw authority, anyone else can take the rest of their
tokens by doing their own withdrawal.
Delegate pool tokens to an ephemeral keypair and sign with that.
* 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
Michael Vines
Jon Cinque
jordansexton
Trent Nelson
Jack May
Yuriy Savchenko