Reducing the unbonding period

[leobragaz]

Introduction

The last friday me and @kwunyeung had a conversation about the current 21 days unbonding period of cosmos network and how this has empowered the exchanges that offer the possibility to stake tokens without the burden of waiting 21 days to undelegate them.
Actually, these exchanges share an incisive amount of voting power but they're not actively partecipating by voting or partecipating at the testnets.

Talking about Desmos, even if now no exchange bought our tokens, we cannot prevent them to obtain some large amounts in the future and if we don't reduce the unbonding period probably a very similar situation to one describe above would happen sooner or later.

Feature description

This make us think about reducing the unbonding period from 21 days to something less like 7 or 5 days.
We can easilly achieve this by making a proposal to change the current DefaultUnbondingTime
of the staking module.
Even though this solution is good, I think it only partially solve the problem.
Having an unbonding period will always penalize a validator compared to an exchange's validator.

Implementation proposal

Probably a good solution could be the use of the DSM as a collateral when users stake tokens.
E.g:

• Alice stake 10 DSM

• The network open a Collateral Debt Position and returns to Alice 5 udaric (or whatever name we choose).

• Alice has now bonded her tokens but she has something she can use in return.

Now; I've made a very simplified explanation of something that could probably be very complicated.
Some questions pop in my mind like:
How many udaric we give to users? Based on which conversion factor? The Current DSM value?
And who provides us the value? Oracles? Exchanges (lol)?.
Moreover, a system like this goes through very frequent changes and probably need constant edits (at least in the early stages) that could be very annoying if we manage to do this directly on chain with a module that takes care of it.
What we could do instead is using cosmWASM and let a contract to handle this.
In this way, we can easily edit, test and deploy the code without the need to update the chain itself.

@kwunyeung @RiccardoM what do you guys think about this?
I'm also curious to hear @terencesflam opinion on this.