No staking at beta launch: Confirmed by Fabio Canesin on Twitter

1 Like

Staking income would be basically zero at the early stages. So obviously this makes sense.

I have a query regarding revenue distribution. If Nash distributes 75% of its revenue, will the remaining 25% be sufficient for operational expenses and future capital expeditures?

It is up to 75%, on a 2 year stake. No way all holders will stake 24 months all the time. Plus, lots of coins will be unstaked so the fees collected by Nash will be way more than 25%

1 Like

Like Nick said, in reality they will always receive more than 25% as not every token will be staked for two years. They have enough funds currently to operate for two or three years, if I’m not mistaken. Fabio mentioned the figure of ~$1B monthly volume being needed to break-even


That is correct, there was no reason to expect different.

Let me expand on the reasoning: the Nash platform is not based on a single or private blockchain that we control nodes to launch “a testnet”. So how do we test it ? We do a soft launch, in a controlled beta roll-out. The controlled beta goes both for access and features!

Our goals are:

(1) Have a broader set of users testing the integration of all the systems that form Nash, probably first weeks will not be settled on-chain. Instead we will capture the outputs analyze and run it on private networks to see the results. I am fairly certain we will see users trying to craft special serializations with the SDKs and I am eager to see what people start to build with the APIs.

(2) To validate the user experience, when you design and implement interfaces you make several assumptions about how people will interpret and use features. As more users enter the testing we want to see what kind of patterns of usage emerge, so that we can discover new assumptions on users using the beta. That is a never ending task, so we bounded internally to two iterations on the interface, meaning we will do two revisions of the UI while in beta to supply solutions for pains not previously mapped by our team.

After (1) and (2) have run and the results of (1) is that we have a stable and secure integration of the systems and of (2) that the interface is efficient on solving the usability issues and provides a pleasant experience we will open to the public.

One may ask why not do just (1) in closed doors and have (2) done in the market with public access ?

When doing (1) with the community we can have a much bigger pool of users hitting all points of the system, there is only so much you can do with QA and automation. Every new protocol will go through this phase - soft launch / private beta / beta … each project will call on their own form.

Iteration based methods like lean startup where you put something simple out and just keep improving it on the open market doesn’t work for our type of product. Those methods main goal is not to deliver products but to find market needs and test if your solution resonate with the need you mapped in the users you were able to reach. That is not the market we are, applying the iteration method is a misunderstanding of it and there are fundamental reasons why those projects trying this approach have failed to attract users.
With (2) Nash validates its implementations and hypothesis, to the degree needed before reaching the broad market.