🌏Roadmap: towards stability
The beta testing phase resulted in quite some useful feedback and insight. Some of it already known before going into it, some new.
Laying the foundations for a DAO as a central entity is difficult. It is important to involve the community soon, but completely doing so from the beginning isn’t viable. So, what needs to be tackled before handing over control, and what can be handled by the future DAO? In other words, what feedback needs addressing before we go on as a collective?
Most feedback received highlighted the importance of either:
1. Decentralization
and
2. Usability
So, let’s look at these specific categories, the points they consist of and the timeline we propose to implement them in, while staying true to our vision of launching in a fast and safe manner.
The timelines we propose fall into one of two categories:
1. Before launch: this point is essential to enabling proper and safe use of the Stabilis protocol and should be addressed before Mainnet launch.
2. After launch: while extremely beneficial, this point can be addressed as a collective, and isn’t necessary to enable proper and safe use of the Stabilis protocol.
1. Decentralization
1a. Enable decentralized governance of the protocol
To fully trust the protocol, control over it needs to be decentralized. Reaching this point requires an on-ledger governance system, and an easily accessible front-end that makes it possible to interact with this governance system.
Proposed timeline: before launch
1b. Enable decentralized access to the protocol
For Stabilis to claim it operates in a truly decentralized manner, interaction with the protocol should be decentralized as well. All interfaces and documentation should be accessible in a decentralized manner (IPFS).
Proposed timeline: before launch
1c. Fairly distribute $ILIS, the Stabilis Protocol’s governance token
For governance to work like it should, the $ILIS token needs to be distributed in a fair way. Ideally, people interested in getting involved in the Stabilis ecosystem are targeted. The feedback reward program is a good start. But, to also ensure sufficient liquidity, an IDO or Liquidity Bootstrapping Pool could be considered.
Proposed timeline: before launch
1d. Delegate responsibilities to DAO members
We want to enable the DAO to move forward without relying on a single (centralized) entity. An environment needs to be created where the DAO’s members are incentivized to contribute.
Proposed timeline: after launch
1e. Open source everything
The user needs to know what exactly they are interacting with. But more importantly, for every DAO member to be able to contribute, an environment where everything is open source needs to be created. Before going open source, it is important to have done sufficient auditing.
Proposed timeline: before (or at) launch
2. Useability
2a. Ensure the front-end is sufficiently useable
Interacting with the protocol should be as simple as possible. The current front-end has its faults. This needs to be improved until (at least) the point where all basic functionality of the Stabilis protocol is readily available.
Proposed timeline: before launch
2b. Design a new front-end
While the current front-end should be sufficient for the protocol to operate, its UI isn’t the most intuitive and its design is rather uninspired. This isn’t just fixed by some small changes, and an entire new front-end would do the protocol a lot of good.
Proposed timeline: after launch
2c. Creating a brand identity
Tying into the previous point, currently, anything Stabilis feels very neutral and uninspired. A pleasing front-end requires a clear brand identity.
Proposed timeline: after launch
2d. Incentivize behavior positive for the protocol’s useability
For the Stabilis protocol to function, it relies on its users. For example, STAB and ILIS need sufficient liquidity, liquidations need to be carried out and ensuring STAB trades at its peg relies on arbitragers. Mechanisms to incentivize this behavior need to be in place.
Proposed timeline: before launch
Last updated