100M DAO compromise

I decided to bring an important upcoming issue to the community’s attention. The Lisk team completely overhauled the tokenomics during the migration, and without going into details, let’s set aside the fact that holders received half the proportion they had in the network before the migration. Now, we will discuss the upcoming vote on whether to keep or burn the 100M DAO tokens, which could ultimately increase the dilution to around 62%. Currently, it is almost 50%, to be precise, 49%. You can read my discussion with Dominic here and with Shuse2 here and draw your own conclusions. Let me briefly describe my idea.

Remember Elon Musk and Tesla? He received his compensation in the form of shares based on the stock price they achieved. We can do the same for the DAO. If the price reaches $5 and it holds for 1 month, 10 million tokens out of the 100 million will be unlocked and transferred to the DAO account. If the price reaches $7.5 and holds for 1 month, another 10 million tokens will be transferred to the DAO. This will continue in increments of $2.5 up to $27.5 per token. This way, token holders will be assured that they will get the token price; those who want to sell at that level can do so, or earlier, but everyone will have incentives.

New investors will be motivated to invest in the token, and the team will be driven to develop the product so that the token price increases over time, rather than just printing new tokens. Only then, and only under such conditions, will I believe in the sincerity of the Onchain Foundation regarding these DAO tokens. This is one compromise option for retaining these 100M tokens.

We should have a vote like this:

What should be done with the 100M DAO tokens?
1. Burn the tokens
2. Keep the tokens with unlocking linked to the price**

Price to unlock next 10M DAO tokens, USD Time to unlock tokens not early than, even if price was reached
5 01 Jan 2027
7.5 01 Jul 2027
10 01 Jan 2028
12.5 01 Jul 2028
15 01 Jan 2029
17.5 01 Jul 2029
20 01 Jan 2030
22.5 01 Jul 2030
25 01 Jan 2031
27.5 01 Jul 2031

** If the price is reached and then drops, the tokens at that price will be unlocked when the time is reached.

Example 1: If the token price is currently $4, the current date is July 10, 2030, and the price increases to $22.5 and holds there for a month, then 80 million tokens will be unlocked immediately.
Example 2: If the token price is currently $30, and the current date is October 10, 2026, tokens will be unlocked over time.

2 Likes

Sounds reasonable, I would support that. This would create a long-term motivation for the community to support the ecosystem and to research and create new tools to increase ecosystem internal value. Especially considering the alternative as burning or simple vesting.

2 Likes

Good idea. A release schedule tied to unlocking helps to align incentives and avoid situations like Polkadot recently spending almost $100 million in 6 months on marketing.

Since you mentioned Elon Musk, remember that his his compensation was blocked / delayed. If option 2 was agreed upon how would be funds be escrowed?

Not sure how safe a contract connected to an oracle service would be. Maybe Redstone has the solution but if not?

1 Like

I think it’s not a problem; they are escrowed now somehow, and will be escrowed later. It’s not an issue. Everything can be solved, maybe not easily, but it can be done. That’s why we need to focus on how we want it to be now.

Regarding compensation blocking, my idea gives investors a chance to sell the tokens, and it’s honest (those who want to sell can do so) because the price must be at that level for at least one month. Don’t worry now about how it will be written in the contract; it’s possible to do with oracles as you noticed. For example, every day you can set the price in this contract or get it from the local DEX.

1 Like

Hey @grumlin ,

thank you, imho it is an interesting suggestion to unlock the tokens linked to the price!
But if we include it, there would be actually three options for the community to decide:

  1. Burn the tokens
  2. Keep tokens and do not lock them
  3. Keep the tokens and lock them, with unlocking linked to the price

This means we cannot do it in one proposal, as every proposal can only be approved or rejected by the community. Instead, I would suggest that you do a second proposal, following the 100M proposal.

If the community decides to keep the tokens in the first proposal, you can create a new proposal directly afterwards, that proposes to lock the 100M linked to a specific price, which the community can accept or reject. And if the community decides to burn the tokens, there would be no need for the second proposal anyway.

Hi, Mona,

We need to conduct a vote with three options at once. Alternatively, we can have two options but immediately decide between linking or burning. If the team refuses this option, I propose holding a preliminary vote to clarify the final question, which would be fairer. For example, we would first conduct a vote: “Should the token retention be linked to the price, as proposed by Grumlin, or without price linkage, as proposed by the team?”

Why is this fairer? Because those who want to retain tokens with a price linkage will have the opportunity to ensure it will be linked to the price; otherwise, they will vote for burning. For all other options, the sequence does not matter.

And it should not be the team determining the voting sequence, to be honest, but the DAO, i.e., the community.

2 Likes

We need to conduct a vote with three options at once.

I don’t think this is currently possible.

And it should not be the team determining the voting sequence, to be honest, but the DAO, i.e., the community.

Sure, you are right, there is also no way the team could determine it, in the end the community is free to make any kind of proposals already before the 100M proposal.

Why is this fairer? Because those who want to retain tokens with a price linkage will have the opportunity to ensure it will be linked to the price; otherwise, they will vote for burning. For all other options, the sequence does not matter.

Good point, and actually it might help when we have a few “smaller” proposals before the big 100M proposal in September, so people can get familiar with the voting system.

2 Likes

You don’t have to use oracle, having DEX on Lisk L2 is enough, then you could write a contract that would be linked to a liquidity pool and only allow tokens to be claimed if the token price was above a certain mark within a certain timeframe. Yes, it would require someone to call a public function once a day and store the current price in the counter, but I think when it comes to big value, this wouldn’t be a problem

1 Like