Since anchor doesn't upload the full source tree but does not seem to
rewrite the list of workspace members, "anchor publish" fails on the
"cli" workspace member.
This is useful for other programs that may want to make decisions purely
based on the amount of weight generated from guaranteed-to-be-locked
tokens at a specific time.
"unlocked_scaled_factor" was a confusing name because the value is
also used when computing vote weight for locked deposits. Rename to
"baseline_vote_weight_scaled_factor" and generally change "unlocked"
to "baseline" in several places.
Also rename "lockup_scaled_factor" to
"max_extra_lockup_vote_weight_scaled_factor" to highlight that it's just
the maximum contribution and that it's "extra" - on top of baseline.
* use solana version on ci, same as local, same as in cargo.toml in dev
Signed-off-by: microwavedcola1 <microwavedcola@gmail.com>
* run soteria scan and tests on all branches, so that devs can detect problems early
Signed-off-by: microwavedcola1 <microwavedcola@gmail.com>
* maybe this works to match all branches
Signed-off-by: microwavedcola1 <microwavedcola@gmail.com>
* try stable
Signed-off-by: microwavedcola1 <microwavedcola@gmail.com>
This is done to allow governance proposals to grant to a voter from
arbitrary token accounts, as long as it's the voter themselves who
executes the proposal once the vote has succeeded.
- withdrawable -> unlocked
"withdrawable" was a bad name, since these funds - while unlocked -
are not necessarily withdrawable if the voter is currently engaged in
a vote.
- only_deposit -> only_unlocked
Locked funds are technically also deposited. Make it clearer that this
is talking about the unlocked parts of the funds on the account.
Rename internal_transfer -> internal_transfer_locked
The new instruction can move only unlocked funds and is useful to avoid
needing to withdraw funds if they should be re-locked in a different
deposit entry.
Withdrawing can be impossible when a voter is engaged in proposals.
The vote power computation was broken for lockups that start very far
in the future.
- Fix the underflow itself
- Disallow lockups that start more than 100 years in the future
- Error if the lockup-scaled voting power is bigger than the maximum
lockup voting power
Christian Kamm
microwavedcola1
microwavedcola1
Sebastian Bor
silas