You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Unvoting/undelegating should be free in a rate limited way
Introduce a new dispatchable force_unlock, a new config item FreeForceUnlockRate: BlockNumber and a new storage item LastFreeForceUnlock: map AccountId -> BlockNumber. force_unlock should go through all voting over all classes, remove votes/delegations with zero conviction then unlock as much of the account's funds as possible. A fee is not charged for the transaction if this happens more than FreeForceUnlockRate blocks after the current value of LastFreeForceUnlock - in this case LastFreeForceUnlock is updated to now.
Voting which does not replace any previous vote should be free
Introduce a new storage item FreeVotes: map AccountId -> (u32, BlockNumber) and a new config item FreeVoteAmountAndDecay: (u32, BlockNumber). When voting, if now - FreeVoteAmountAndDecay.1 >= FreeVotes.1 then FreeVotes.0 is halved and FreeVotes.1 becomes now. Voting is free as long as FreeVotes.0 < FreeVoteAmountAndDecay.0 and there was no previous vote for the given proposal.
Delegating which does not replace any previous delegation should be free
Introduce a new variant into Voting: Consent(Delegation<...>). This is essentially the same as the Delegating variant except that no upstream votes have been altered. Introduce a new dispatchable consent, similar to delegate in all respects except that it uses the variant Consent instead of Delegating and does not alter any vote counts. It is always free to call as long as the account/class is not already voting, delegating or consenting.
Introduce a new dispatchable activate_consent callable by the target of a Consent vote. This is paid as standard, and results in the vote becoming a standard Delegating vote as well as all associated bookkeeping happening.
Once done wallets should be pushed to integrate a standard
With these changes, voting and delegating should now be free to perform. Wallets should retain voting/delegating preferences and enact them as soon as it is both free to do so and free to call the corresponding force_unlock immediately afterwards. Though the latter may not be needed, it's possible it would be should the user decide to transfer funds shortly afterwards.
Fund transferal should use force_unlock unless there are already enough unlocked funds in the account. This should be batched with the transfer in order to make the operation similarly trivial to a normal transfer.
A special option should always be given for abstention.
The text was updated successfully, but these errors were encountered:
gavofyork
changed the title
Make referenda free to participate in
OpenGov: Make referenda free to participate in
Dec 10, 2022
* Sketch out how to support different bridge pallet instances
* Create a common interface for using pallet instances
* Start introducing generic instance parameter
Attemps to make the compiler happy, but I'm having second thoughts about
this approach. Commiting now as a way to have a checkpoint, but I think
I'm going to need to re-consider my approach here.
Ideally I want a change which introduces minimal changes, but this seems
to be propagating around the codebase in ways I don't want.
* Use trait objects instead of generics
* Implement traits for Boxed trait objects
This is done in order to statisfy trait bounds by types
which use these new trait objects
* Remove Clone usage for sync parameters
* Remove implementation of Default for sync params
* Require that BridgeInstance implements Debug
* Ensure that BridgeInstance trait implements Send/Sync
* Add documentation related to instances
* Rust Fmt
* Remove needless format
* Make instance CLI option case insensitive
* Replace `with_*` constructors with `new`
* Clean up usage of instance structs
* Enforce a default instance in the CLI params
* Build sync params as we process input from CLI
* Remove case insensitivity from sub-tx-mode
I think this should happen, but maybe as part of a different PR
* Process default Eth contract deployment config in CLI
* Build EthereumExchangeParams in CLI
* Process EthereumExchangeSubmitParams params in CLI
Unvoting/undelegating should be free in a rate limited way
Introduce a new dispatchable
force_unlock
, a new config itemFreeForceUnlockRate: BlockNumber
and a new storage itemLastFreeForceUnlock: map AccountId -> BlockNumber
.force_unlock
should go through all voting over all classes, remove votes/delegations with zero conviction then unlock as much of the account's funds as possible. A fee is not charged for the transaction if this happens more thanFreeForceUnlockRate
blocks after the current value ofLastFreeForceUnlock
- in this caseLastFreeForceUnlock
is updated tonow
.Voting which does not replace any previous vote should be free
Introduce a new storage item
FreeVotes: map AccountId -> (u32, BlockNumber)
and a new config itemFreeVoteAmountAndDecay: (u32, BlockNumber)
. When voting, ifnow - FreeVoteAmountAndDecay.1 >= FreeVotes.1
thenFreeVotes.0
is halved andFreeVotes.1
becomesnow
. Voting is free as long asFreeVotes.0 < FreeVoteAmountAndDecay.0
and there was no previous vote for the given proposal.Delegating which does not replace any previous delegation should be free
Introduce a new variant into
Voting
:Consent(Delegation<...>)
. This is essentially the same as theDelegating
variant except that no upstream votes have been altered. Introduce a new dispatchableconsent
, similar todelegate
in all respects except that it uses the variantConsent
instead ofDelegating
and does not alter any vote counts. It is always free to call as long as the account/class is not already voting, delegating or consenting.Introduce a new dispatchable
activate_consent
callable by the target of aConsent
vote. This is paid as standard, and results in the vote becoming a standardDelegating
vote as well as all associated bookkeeping happening.Once done wallets should be pushed to integrate a standard
With these changes, voting and delegating should now be free to perform. Wallets should retain voting/delegating preferences and enact them as soon as it is both free to do so and free to call the corresponding
force_unlock
immediately afterwards. Though the latter may not be needed, it's possible it would be should the user decide to transfer funds shortly afterwards.Fund transferal should use
force_unlock
unless there are already enough unlocked funds in the account. This should be batched with thetransfer
in order to make the operation similarly trivial to a normaltransfer
.A special option should always be given for abstention.
The text was updated successfully, but these errors were encountered: