project-serum / stake Goto Github PK

This message appears when trying to stake locked tokens or unstake unlocked tokens:

Error staking: Please collect your reward before otherwise using the program.

Note: All rewards appear to have been collected via the GUI

please tell me how i will pass payer

Immediately calculate the spill amount and send back to the reward funder. There's no need to wait for the expiry.

Create time window where, for the first 24 hours of the lockup account being created, the creator can cancel it and get back the funds. This would be useful in the event the creator creates the account with bad params.

One should be able to close a vesting account once it's been fully depleted to get the rent exemption SOL back.

The locked token reward vendor should be generalized to allow for dropping arbitrary program accounts as rewards onto stakers.

On the staking UI home page would be great:

• Show the accumulated amount locked balances received

On the Stake page:

• Make it more easier to stake locked balances when accumulate over 500 locked SRM for more pool tokens.

There is some demand for the ability to transfer the beneficiary of a vesting account to a new account. https://discord.com/channels/739225212658122886/739236663926063145/823206958206812166.

One challenge here is that lockups have an optional "realizer" that determines if the lockup withdrawal can be executed. So when transferring locked token accounts, the realizer condition needs to be respected. For stake rewards, for example, the realizer is the condition that the user has zero stake pool tokens. So when transferring locked tokens, even if the user's wallet is the same, the stake amount might be different, which would be undesireable if it means the user can unstake less tokens than the reward for which is supposed to be dependent on the stake tokens. One potential solution would be to just allow the transfer if the user has at least as much stake tokens in the new stake account as the user has in the old stake account.

Currently, the stake token is held by the program and used as an accounting metric. If we instead minted to the user, the stake token could be used for things like

• dex fee discounts
• governance rights

We might want to issue two tokens: one for utilities like those listed above and another for reward accounting (as is done now).

Registry:

Instead of having two versions of balances, locked and unlocked, for a given member account, one can consolidate these two with the following scheme:

When depositing into the stake program, the program can create a redeemable "deposit token" that represents a claim on the assets in the stake account (separate from the pool token, which is just used as an accounting measurement for rewards). For locked tokens, the locked token program would send funds to the stake program, and the stake program would mint these "deposit tokens" to the lockup program. To withdraw, one would provide these "deposit tokens" to the stake program, which would burn them and return the corresponding number of assets.

Lockup

Any app can then facilitate the use of locked tokens by implementing an additional deposit_locked method that takes in a Vesting account and mints these "deposit tokens" to an account with an owner being program derived address with the vesting account as one of the seeds. Withdrawals would not need to be special cased. Any transaction signed by an owner of a "deposit token" would be able to withdrawal.

Pros

• Cuts the number of required accounts for a Member account in half
• Easier to reason about the locked property being maintained. A program has to just prove two things: 1) all tokens coming into and out of the program are through the deposit_* and withdraw instructions and 2) deposit_locked only mints "deposit tokens" to token accounts owned by vesting accounts.

All stake accounts should be created with associated stake accounts.

Currently this is done as a convention by the client (using create with seed), but it should be enforced by the program.

Use the new #[associated] attributes in Anchor 0.4.3.

This is convenient for stakers that want to transfer stake to a new wallet without incurring the unbonding timelock

I wanted to build the project and try.
When I ran command <anchor build --verifiable> as indicated in the README, it showed the following error.

Using image "projectserum/build:v0.18.2"
Run docker image
Unable to find image 'projectserum/build:v0.18.2' locally
docker: Error response from daemon: manifest for projectserum/build:v0.18.2 not found: manifest unknown: manifest unknown.
See 'docker run --help'.

I have no idea why this is happening.
FYI, I installed docker and all solana dev environment as indicated in the solana dev documentation.
Please give me a clue.

Instead of using an event queue for clients to keep track of available rewards, we can use deterministic addresses. Specifically, we can

• Add a global reward vendor counter to the Registrar account
• Use program derived addresses (owned by the program) for each reward vendor, using seeds as `[registrar.key.as_ref(), &"reward".as_le_bytes(), &[bump]].
• Pass in the next reward available on stake and unstake to perform reward eligibility checks (instead of passing in the reward queue account as is done now)