Launching in 2 parts: First Hatch + Dandelion, then Vote to add ABC & CV

Griff · November 19, 2020, 1:23am

In short, when we launch, we will first only deploy the Hatch and Dandelion DAO. There will still be a Hatch Tribute, so the funds collected would still be split between two Pools: The Non-Redeemable Pool which is dedicated to supporting TE Projects and TEC Operations, and the Redeemable Pool, dedicated to creating an economic system for the DAO.

But the Augmented Bonding Curve and Conviction Voting apps would be added by a vote of the TEC Token Holders.

For a detailed explanation of the change, see my 5 minute explanation in the Soft Gov Call:

The Pro’s

The complicated and critical apps that make up the ABC and CV, which will control the funds of the DAO will have more time for code review, and the 1hive Gardens Swarm can better focus efforts with a staggered launch.
Because we are able to initialize as a Moloch style charity DAO, where people donate and it loses money. Legal gets MUCH easier, we are likely to be able to avoid KYC, and MIGHT even be able to allow Americans to play, under the argument that we are “sufficiently decentralized”
We will have a stronger filter for the Hatchers as they will have to care more about participating in the governance of the Commons and it will be more obvious that this is a project with the intention to fund TE Public Goods over funding token speculation.

Con’s

The conversation for Onboarding and Comms becomes a bit harder. We add in this extra step and we can no longer promise that they will receive a token that is worth more than they contributed. That is dependent on a vote.
There is a likely hood that we will have a smaller Hatch because of this uncertainty, and the Hatchers will be able to remove their
We will start out with a real test of our social governance structures. We will need to organize well to inform the Hatchers what they will be voting on and what it means.

What do you think should we launch in 2 parts?

JessicaZartler · November 24, 2020, 12:34am

VOTE EXPLAINER: I am blocking the vote – not because I am against launching in two parts, I am in favor, based on the legal and other positive aspects of this decision to launch in two parts. What I am concerned about however, is the following:

-1. Wanting to ensure a fair, inclusive and successful hatch - we do not have any KPIs or definition of our goal. I would like to see an inclusive and diverse hatch if this is, in essence, a kind of “pre-sale” and another governance layer and make sure we do not have a technocracy… what defines diverse? How many people would we want to have this governance power? What is the maximum or goal we would like to raise? If we only get one shot and we don’t succeed, that is not good.

-2. If we don’t meet that goal, and it is not “successful” based on those KPIs could we have a second hatch before launching the bonding curve to further increase the diversity of our governance and Trusted Seed?

-3. The lack of clarity surrounding the CSTK token’s involvement in the hatch and how that will play into the hatch. I believe we need this information to make the best decision on how to proceed.

-4. Pending updates to the Commons Stack Trusted Seed – I think we need to give some time to harness this dormant energy, which is currently in progress to revive a lack of engagement.

-5. Unclear timelines - the talk was to push for this hatch in December, today I heard different information, it is still not clear how much runway we will have for Onboarding/Communications to organize around the plans, would like to have a little more concrete timeline for the ramp up.

Moving forward:
I would be happy to support launching in two parts if we can have dialogue around some of these issues and have clarity, especially some discussion around #2 and also, not sure if this vote is just to signal to move in this direction, and that we will hold other votes on some of these other issues, and if so, which ones?

I believe more dialogue is needed before voting on this decision and look forward to setting time for a discussion, or continuing a-sync on this thread. Thank you to everyone for sharing your feedback and participation in the process

sem · November 24, 2020, 1:25pm

Thank you for sharing your concerns, Jess! I also share them, and I hope we can solve them soon. Here are my thoughts on each of them:

Successful hatch: On one side, we need to define the parameters together, but we are not having much participation in the deep dives that are already posted. We may need change the strategy (Jake is beginning this week, but he will take on that). On the other side, technical parameters doesn’t define what is good or bad for the community, and we may need other KPIs to see how we are doing. It sounds like the oboarding wg can take care of it? maybe with the help of comms, because you work directly with the people who is reached?
Second hatch: That’s an interesting question. Until now, we were only taking into account the money fundraised to define a successful/non-successful hatch. If we take into account other KPI, we should make sure we check them all before we launch the hatch DAO. If we meet all the KPI we define, and we don’t receive enough funds in the hatch, the money will be refunded, and we can repeat it in a later time with another hatch DAO, but let’s pull out all the stops in the first time
CSTK: This is what tec wg want to show in the next demo regarding the “improved hatch”. It will follow a naïve implementation of the original Commons Stack design: people can contribute to Commons hatches in proportion on how much CSTK tokens they have. We can discuss other mechanisms in the forum, for example, do we want to add a min or max cap per account? We are still iterating.
Trusted seed: I totally agree, we need them engaged before we launch the hatch.
Timelines: I think Tamara is who may be in the best position to understand the progress of the different working groups and help them reach consensus in the timelines. From the tec wg, we would be ready to launch on mid December, this is why we proposed to split the launch in two, so we could make it on time and don’t block the progress of the rest of wg. That being said, there is no need to rush, and maybe we need more time to engage the trusted seed (see #4). We would also appreciate having more time to do last retouches in the code.

Let’s improve the coordination between the different wg, Thursday calls are great but they are not enough. Zenhub and this forum are probably the best tools for that (plus cross-pollination between the wg calls)!

Griff · November 24, 2020, 3:58pm

This is something we have to be careful about.

We are not aiming for an inclusive Hatch. We need to be explicitly excluding speculators from the Hatch, and only including people that can be trusted to care about the actual VALUE of Public Goods in the Token Engineering space.

We definitely need to get to work on the onboarding group and find all the awesome Token Engineers working hard building projects in the space that would benefit from our work.

We also need to be careful not to allow people with a green frog as their twitter pic to have a lot of governance power in the TEC.

Quality over quantity for sure. This is more akin to starting a nonprofit, than doing an ICO. We want to make sure we stack the deck with awesome people that want to advance the state of Token Engineering and be careful not to let in people who only care about “Number go up”

For the rest… I pretty much just agree with what Sem said, we need to be okay with not having some of these issues totally clear before picking this path. We will always have to make some decisions first before making the rest. They can’t all be made at the same time.

After the next rehearsal this week, everyone will have a much clearer understanding of the process, and with that foundation we can start to understand the parameters and their influence… We want an informed dialog not just dialog.

Tamara · November 24, 2020, 9:49pm

Some thoughts about what’s been written.

I saw this vote more in the light which you, Jess, touch upon at the end of your post. For me, it is just a matter of changing direction, with timing to be hardened. For the reasons that were discussed, importantly those which pertain to reducing legal grey area, I voted yes. I don’t think there is very clear timeline yet, right? Maybe there are some soft targets.

If we look at concerns 1, 2 and 4, they’re actually all solvable within some timeframe. The question is: what is a reasonable timeframe to complete the critical path work. Which begets the next question of what are the critical path pieces of work?

Jess’s concerns have legs. It surfaces the known risks and maybe there are more. And it also affords clarification on specific strategic thought, like the comments from Griff about criteria for success around Hatch participation.

My proposal on the call today was for each working group lead to add the label “Hatch Critical Path” to all issues within their group that are blocking launching the Hatch. We can address them and see what timeline is feasible.