Vesting system

[damip]

EDITED BY AURELIEN:

Solution designed by @damip

The goal is to have a simple system that answers this points :

• Be able to have coins locked since the start of the network
• Coins should be able to be unlocked through the time running
• Be able to stake or not with this coins

Define the staking initialization file

The vesting will be able to be set only at the initialization of the network not when the network runs.
Possible format:

{
  “Address”: [
    {
      “Slot”: {
        “Period”: 0,
        “Thread”: 0
      },
      “min_balance”: 10000,
      “max_rolls”: 100 // If 0 then staking is forbidden
    },
    {
      “Slot”: {
        “Period”: 100,
        “Thread”: 0
      },
      “min_balance”: 1000,
      “max_rolls”: 10 // If 0 then staking is forbidden
    }
  ]
}

This file must be included in the source code and therefore be the same in other nodes.

Releasing process

The releasing is represented by the fact that the minimum balance lower through the time and so the address is able to use more of his balance.

Minimum balance representation

min_balance = (rolls * roll_price) + balance + deferred_credits

Notes

The coins vested can be staked and are sensitive to slashing
The rewards of staking aren’t stake

[AurelienFT]

My thoughts and proposition on this:

Making it as an autonomous SC

Proposition

We could write a smart contract that use our autonomous SC system to release the funds at a specific slot. We could add a method to add funds, an address as a recipient and a slot to release.

Problem

If the SC autonomous pool is full and the fee not high not enough it's possible that the message isn't executed and the money is never released.

Making a vesting system usable at any time

Proposition

We could add a flag on a transaction to setup at slot on which slot the recipient receive the money.

Problem

It's the same behaviour as the SC autonomous and so it needs the same requirements (pool, fees, ...) and so there is no difference than using our autonomous SC system

Save it in initial ledger

Proposition

We should have the addresses with the coins locked and the slot of release in the initial config file. They should be saved in the ledger if the slot is superior to the current_slot. We could save the these datas in the ledger and also use it to compute the ledger hash. It's not necessary to transfer futur vesting in the bootstrap because if they modify the config file to not have the same as their peers they will have a bad hash and so not the same PoS draw.

[qdrn]

What SCs do usually (for instance on DeFi platforms) is that you emit an operation to redeem what you are owed. If you want to redeem every slot then you'll pay a lot of gas, otherwise you can redeem whenever you want.

Saving it in the initial ledger allows people to stake with locked coins (if we add this possibility), with SCs it's probably impossible.

[AurelienFT]

Yes the solution I keep is the last one I just showed the different options I tried and the problems I found

[modship]

#3510