[Outdated & Changed] Incognito 2021 (Q3 & 4) timeline

[duc]

Update : this is outdated and has been changed to Q3 initiatives.

Hey folks, as you know, we are re-prioritizing the roadmap to focus on the core tech. The following is a concrete month by month timeline, detailing how and when we will complete the features necessary to release the network safely. We hope this provides some clarity, and we hope you will follow our progress and continue sharing your valuable feedback.

April, 2021

Incognito wallet (mobile app)

Name	Deliverable	Ship date
Bug fixes / Improvements	Fix trade issues that can cause stuck trades and improve shielding UI to mitigate user mistakes (i.e., deposit insufficient amount or after request has timed out)	April 02, 2021
Coin service	Coin service is a backend service for pre-processing Incognito coins to help load balances and create transactions faster, instead of retrieving coins directly from full-node	April 16, 2021
Node monitor	Give node owners more comprehensive information about their node statuses	April 16, 2021

Incognito chain

Name	Deliverable	Ship date
Node monitor	Update the protocol to see a node’s contribution to the network (a.k.a number of votes of a node in an epoch). This information will be displayed on a simple web interface as well as the Incognito mobile app.	April 02, 2021
Dynamic committee size (DCS)	Deploy DCS code to mainnet (prior to staking flow v2 and slashing)	April 16, 2021
New mempool v1	Improve mempool process to increase transaction throughput	April 29, 2021
Highway	Increase Highway robustness regarding streaming and connection	April 29, 2021

May, 2021

Incognito wallet (mobile app)

Name	Deliverable	Ship date
Dynamic committee size (DCS)	Update Staking RPC(s) on the Incognito wallet to upgrade to Staking flow v2	May 02, 2021

Incognito chain

Name	Deliverable	Ship date
Dynamic committee size (DCS)	Enable Staking flow v2 on mainnet	May 02, 2021

June, 2021

Incognito wallet (mobile app)

Name	Deliverable	Ship date
Privacy V2	Upgrade Incognito wallet to Privacy v2. The update also includes coin service - the first version will be released in April to ensure that Privacy v2 does not slow down the wallet	June 15, 2021

Incognito chain

Name	Deliverable	Ship date
Dynamic committee size (DCS)	Enable Slashing and review validators’ votes afterwards	June 01, 2021
Privacy v2	Upgrade to Privacy v2 on mainnet	June 15, 2021
Highway	Mitigate spam to the network	June 30, 2021

July, 2021

Incognito wallet (mobile app)

Name	Deliverable	Ship date
Portal v4 (trustless Bitcoin bridge)	Launch Portal v4 to replace the current trusted bridge	July 01, 2021
Binance Smart Chain (BSC) bridge	Launch BSC bridge	July 30, 2021

Incognito chain

Name	Deliverable	Ship date
Release fixed nodes	Based on data of validator voting after slashing is enabled, a plan will be made regarding the release of fixed nodes	July 01, 2021 - July 15, 2021
Portal v4 (trustless Bitcoin bridge)	Release Portal v4 on mainnet	July 01, 2021
New mempool v2	Update mempool v1 to support Privacy v2	July 07, 2021
Binance Smart Chain (BSC) bridge	Release BSC bridge on mainnet	July 30, 2021

August, 2021

Incognito wallet (mobile app)

Name	Deliverable	Ship date
Liquidity v2	Make the pDEX more sustainable by allowing liquidity providers to add liquidity directly to pDEX and stop Provide	August 01, 2021

Incognito chain

Name	Deliverable	Ship date
Dynamic committee size (DCS)	Deploy staking flow v3 code to mainnet (prior to enabling)	August 30, 2021

September, 2021

Incognito chain

Name	Deliverable	Ship date
Dynamic committee size (DCS)	Enable Staking flow v3 on mainnet	September 30, 2021

The timeline above is short. It focuses on the essentials, as the entire team works towards decentralization for the foundation layer and important features for the application layer. After these features are complete, we will stay flexible, reviewing market trends, collecting user feedback, and planning the next stage of development.

The stages to follow will continue to prioritize decentralization – once technical decentralization has been achieved to a significant level, we will move our attention to the governmental. We hope to have your feedback and support then, so we can collectively determine what the future of Incognito will look like.

In the meantime, please follow development via the proposals linked above, and feel free to reach out to any member of the core team should you have any questions. We’re excited to show you what we’re working on.

[marko]

This is exciting! Thanks so much!

[JoyRaptor]

Keep up the good work!

1. Is there anything we can do to accelerate listing on CMC?

2. Could we interegrate liquidity boost or dex/swap tools from orion to fix our liquidity?

3. Wen duc mode? (Dark mode)

[Ducky]

[DeltaSplit]

Please excuse my unknowing but what exactly does the BSC bridge mean and what are implications/usecases?

Is there a plan in the future to list PRV in CEX like Coinbase/Binance…? Or is that defeating the purpose of the privacy concept?

Good roadmap else looks ambitious! Hope the project goes well even without the former teamlead!

[abduraman]

@DeltaSplit

BSC bridge

Binance Smart Chain => low shielding/unshielding fees

• If implemented, private smart contracts over BSC will be unique.

[duc]

Hey @JoyRaptor, let me answer your three questions here:

1. Listing is a thing we considered several times in the past but nothing has been finalized yet, and we’re now only focusing development towards Incognito’s fundamentals first - a privacy blockchain.

2. Regarding liquidity in general and AMM exchange based in particular, we’re figuring a new mechanism to improve and solve the known problems (i.e., price slippage, impermanent loss, capital inefficiency). That being said, we keep looking for a solution and really happy to hear your thoughts.

3. Dark mode is “nice to have” so we can always revisit it later.

[duc]

Hi @DeltaSplit, BSC bridge may a rescue for the Ethereum bridge due to insanely high fees. But I guess you had a very good question about the usecases apart from fees and that’s also a thing we’re thinking of, it may be Binance’s ecosystem utilization or revisiting pBSC by using the same mechanism as pEthereum Specifications.
For the listing, please see my comment earlier.

[fitz_fiat]

Hi @duc,
When you say “release fixed nodes” but then say “Based on data of validator voting after slashing is enabled, a plan will be made regarding the release of fixed nodes”

It doesn’t sound like you are releasing the nodes but figuring out how to market the delay of this event further.

Can you provide us assurance that the fixed nodes will in fact be released in July?

[Thriftinkid]

Same question here @duc,

Originally the plan was to start releasing them in June. I just want it to be made crystal clear they will be getting released in July. Not, “start making a plan” on when to release them. That should be getting done now with a plan that the validators all pass expectations of slashing in June.

[duc]

Hey, let me clarify the slashing mechanism a bit so that you can have a better understanding of our “plan”. A node will be slashed at the end of an epoch if it does not contribute a sufficient number of votes (a vote representing the node’s agreement on a newly created block) as expected when it’s in a shard committee. So the fixed node release plan means after slashing is enabled for a period of time (say 1 month) we will look into the collected data to see how many nodes contributing to the block creation process stably in each epoch alongside the fixed nodes. For example, if there are such X nodes doing their job perfectly every epoch then we would confident to release X slots to the community since it’s required at least 22 out of 32 nodes to be able to keep the network (or a shard for more correctly) operational.

In the worst-case scenario, if some of the X nodes in a shard have issues and cannot contribute to the block creation process then the shard might be stopped and have to wait for these nodes to be swapped out of the committee and replaced with other “healthy” nodes as a way to make the network back up again. At that point, it’s the responsibility of node owners from the whole community to monitor and make sure their nodes work well. And the node monitor tool will be released next week which can help node owners with the task.

Additionally, once the core team does not keep a majority of slots in a shard committee (22 for now) by releasing the X slots as mentioned above, it will be a significant step towards decentralization as community validators can reject a proposing block (so transactions) in case they feel that it’s invalid.

[Thriftinkid]

Thanks for the reply @duc. I think the million dollar question is what is the period of time you guys are looking to wait to see how the nodes do after slashing, and how many slots are getting released if everything looks good? Are we looking at a month and then all of them are getting released? Or two weeks and then a slow release over a couple months? I think everyone is worried we are waiting for July just to have this pushed off another couple months since this has been the normal result in the past. I think everyones patience is wearing a little thin as more nodes come online. The incog teams nodes alone should be able to make a 2/3rds vote pretty solid right now. From what @aaron said, that’s around 1k of the current 2800+ currently running. Unless everyones nodes are imploding when this happens.

[Mike_Despo]

@duc

|Dynamic committee size (DCS) |Enable Slashing and review validators’ votes afterwards|June 01, 2021

Is there an updated status or a new ETA on this? How’s it going for you guys? @duc

[duc]

Hey, like I’ve mentioned in the last weekly update, since there are still pNodes having issues (vNodes look better probably because most vNode owners have full control on their nodes as well as technical skills so that they can solve problems more quickly) we need to delay the slashing a bit for both core devs and pNode owners to work together on the issues, apparently, we cannot leave them alone or let issues unresolved. The new tentative ETA is end of June.

Please note that the code of slashing was done and deployed on mainnet a few months ago, in other words, it’s ready to go once the community is ready.

[abduraman]

@duc

as well as technical skills so that they can solve problems more quickly

Yes, as a senior developer I always restart the docker containers when a shard stall occurs or the nodes go offline. This is my advanced technical skill

[duc]

Hi @abduraman, just a quick check in, your nodes run just fine now, correct? and are they pulling the new docker tag automatically?

[abduraman]

Hi @duc, yes, they are pulling the latest docker. What I wrote above is for the versions before 20210614_1. Up to now, there is no stall or offline event after 20210614_1.