# Osmosis Feature Idea Log
## 1. Variable Staking Withdrawl Lengths (VSWL)
### Glossary
- Rewards to Distribute (RTD)
- For Osmosis, this occurs each Epoch
- A constant amount that is currently distributed amongst validators according to their stake
### Current Approach
- Osmosis staking's withdrawl length is currently 28 days
- Such a long staking period increases the barrier for entry of users who would potentially be comfortable staking for 14 days, for example.
- Superfluid staking secures the network but only involves a 14 day bonding
- The percentage reward rates are less for superfluid stakes securing the network
- The 14 day bonding sets precident that Osmosis accepts securing the network for shorter than 28 day bondings for a reduced rate
### Proposed Changes
- Add VSWL with minimum and maximum withdrawl lengths
- Min length: 14 days
- Max length: 56 days
- RTD would be exponetially proportional to the distribution of withdrawl lengths according to their total amount staked.
- Votes would have to reflect their value relative to the composition of potentiall diffenet staked amounts at potentially diffent lengths
### Comments
Osmosis currently has a pretty long withdraw length of 28 days.
- Is there interest for this length to be decreased if the rewards are accordingly decreased?
- Superfluid precident
- Would there be adoption of a longer withdraw length?
- Personally I would use a longer length if the rewards reflected the additionally accepted risk
### v1: Any Staking Length Between Min/Max Bounds
- Max and min staking lengths are defined as bounds
- Rewards increase exponentially from min to max
- Any staking length between max/min is available and would be appropriately compensated according to an exponential curve between the min/max lengths
#### Pros
- User freedom to choose any length between min/max to reflect their personal confidence level for staking
- Staking rewards reflect confidence levels
#### Cons
- Complex problem from a math and structural perspective
- Math
- Multivariable equation to solve each distr
- Structure
- How are we distributing to validators?
- Are validators considered according to each length or as their total stake (as is)?
- According to Validator Stake by length - but length is essentially continuous
- length_x validator list:
0: Alpha Validator: 10 stake
...
n: Gamma Validator: 50 stake
- Distribute to lengths, lengths distribute to validators
- Implement as layer above validators
- Would impact vote weight
- Computationally expensive
- Is a discrete set of staking lengths better if it still gives users a sense of self determination of their confidence?
- Explored as v2
### v2: n Predetermined Staking Lengths
- n different staking lengths are defined
- Implement in such a way that future governance proposals could add/remove new/old staking lengths
- Longer staking lengths are rewarded exponentially* more than shorter lengths
#### Pros
- v1 Pros
- Limiting the number of staking lengths decreases the complexity of the problem and computation needed as compared to v1
#### Cons
### Comparing Versions
#### v1
- Curve is adjusted by the constant number of RTD
- A minimum percentage of the RTD is set for the min and max lengths
- The remaining amount of RTD is increasingly distributed to the staking lengths between the min and max
#### v2
- Curve would still be determined by max/min in v2 like v1
- A known n number of staking lengths decreases the computation needed compared to v1
- Sacrifices v1's essentially continuous range for faster computation
- Simplifies implementation implications of v1 by making lengths distrete like pool gauges
## 2. Re-Pool Rewards
### Proposed Changes
- Add option to automatically re-bond pool bonding rewards distributed each epoch at the gauge that distributed them

## 3. Dexmos-like Breakdown of Rewards on Pool Page
## 4. Pay Tx Fee With Stake Claim Amount - Not Osmosis Specific
## 5. Pay Tx Fee With Exit/Remove Amount Out From Pool
## 6. Pay Tx Fee With