eosDAC is successfully maintaining a position as a top-21 producer, by being a well-respected and safeguarded BP on-chain. eosDAC workers are also preparing to launch voting for Custodians rapidly, and are working on this at full speed. Multiple members of the team are working 50-70 hour weeks to code and create the workflows including company and legal pre-requisites for this transition. It’s great to have the support and help of our colleagues from across the EOS community - developers from other projects are reviewing our code; lawyers in multiple jurisdictions are looking at our legal contracts; ecosystem veterans are probing our governance.

From the inside it feels like a team sprinting toward a finish-line push.

But parts of the community don’t see it that way, particularly some Korean tokenholders, who are angry that our previously articulated timelines have not been met - not by a long shot. After all, DAC workers said in July that Custodian Elections would happen sometime that very month. When that didn’t happen, DAC workers said later in July that the DAC would be on track for a handover in Q3. Within the last month, we created a set of ‘criteria to turn on voting’, and recently added a couple of items to that list.

Those community members who recently put their name to a set of demands are seeing Custodian voting and handover as a goal that continuously shifts further away, and are now claiming to be worried that there are sinister motives behind this pattern of receding deadlines.

Background from my perspective
I joined the project toward the end of May. At that time there was a palpable sense that we would imminently be handing over to elected Custodians. My initial main role was as Managing Director of the entity eosDAC Ltd, and I was told that my formal engagement should be in place before 1 June because on that date we might ‘hand over’ (to elected Custodians) and we needed certain systems (such as payment facilities) to be in place by then.

Looking back it seems incredible that there could have been an active sense within the senior team that handover could be happening straight away. But there was. So - why did a handover to Custodians seem so close then, when, fast forwarding to November, that handover is still being prepared for?

It is a vast undertaking to code and create a legal, on-chain DAC
eosDAC is aiming to be a fully on-chain, mainly programmatic DAC whose activities will be decided by weekly elected Custodians. It’s not easy to create EOS code to describe every step of that - especially when code changes will be harder to effect after the handover.

Relevant resource is scarce
Sometimes we see ads “EOS developer required: minimum 3 years’ experience” and chuckle. The EOS.IO software was only launched a few months ago. We're glad that feedback on our code from those who worked to produce it with Block.One is that we’re industry leaders. We attract some of the best talent because they are passionate about DACs, they enjoy working with each other and they value being treated - and treating each other - with appreciation.

Not only coding; no one has yet created the legal and company structures that adhere to principles of decentralisation - which we passionately believe in - and at the same time protect members from disproportionate liability. I personally have been working on legal and company structuring at some of the world’s best firms since the mid-2000s, and have never come across many issues we are now contending with. Lawyers and accountants equipped to work within blockchain are rare - and again, in high demand.

Nobody knew how long it would take
Just because no one has ever done this, does that really mean time estimates should be nigh-on impossible to make accurately, when time estimates are routinely made for many complex projects like construction, public works, and other software projects?

From what I can deduce, the answer lies in two factors: 1) the proportion of known to unknown unknowns and 2) the possibility of throwing more resource at the project if things turn out harder than expected.

Let’s look at these in turn:

1) Proportion of known-to-unknown unknowns:

When you scope out the timeline of a project, you are estimating the time it will take to complete:

• the known knowns: the things you know you have to do that you already know how to do. And

• the known unknowns: the things you know you have to do but don’t yet know how to do. Already these are hard to budget time for, but may be possible to give a range.

For projects like construction, transport, health-care systems, or even software projects older than a few months, the known knowns and known unknowns may make up the majority of the total work.

In our space, there has turned out to be a very high proportion of

• unknown unknowns: the items that are on the critical path that you didn’t even know existed, and that you also have no idea how to do until you figure it out.

These were all the the things we could only have discovered were actually crucial to be coded or created in the legal/corporate sphere once the build+design process was already underway. Things like proper permissions systems and finding a service provider that could fulfil certain specific functions. Things that it would be irresponsible to ignore once we realised how crucial they were. Things we had to learn how to do, and which often required external input or checking.

2) The possibility of throwing more resource at the problem

In other industries like construction or transport, a project experiencing a high volume of unknown unknowns might be considered an emergency case. And managers would throw additional contingency resource (probably contractors) at it - at double- or triple-time rates.

But that isn’t a possibility here, or if it is, I don’t know how. Where do you find more high quality, error-free EOS coders who can immediately slot into our team? Where do you find blockchain lawyers sitting idle?

In crypto delays are the rule, not the exception
The above are the reasons why most if not all blockchain projects repeatedly run behind schedule. Examples abound; you would be hard-pressed to find counterexamples (anyone want to throw some out there?).

A couple of instances of delayed project timelines: the June EOS.IO release by Block.One included a fraction of the features promised at launch, and many are still now underway five months later. Ethereum’s move to PoS is taking longer than anticipated. Lisk has experienced well-reported delays despite a huge team.

These aren’t criticisms; our colleagues at other projects are working just as fast as they can.

It’s simply hard to gauge timelines when you’re stepping into the unknown.

We haven’t been great at communicating this
Given this, we obviously should never have articulated timelines, and it might be good for us to learn how to better communicate our progress - which is well-appreciated by the broader EOS community, as evidenced by our top-21 ranking.

Maybe it’s a personality thing, that highly capable people attracted to working within a DAC tend to put their heads down and do their work, rather than report progress all the time.

We’ve been aware of trying to optimise our communication, so for some months now we have been meeting at least 3 times per week (2 evenings at 9.30pm UK time and Saturday afternoon), and we also have other regularly scheduled calls. We also continuously communicate on Discord and other channels, and have also started meeting in person where possible.

The importance of seamless, consistent and reliable communication cannot be underestimated for a DAC, and it’s something we’re still learning.

We’re not hierarchical so enforcing ‘timelines’ is hard
One or two DAC workers making a timeline doesn’t mean much in terms of ‘enforcing’ that timeline across the entire team whose efforts will be needed to turn it into reality. When there’s no boss, who can set a deadline?

These are issues we’re figuring out.

The importance of momentum and creating a culture which encourages a steady pace from the team, is something we’ll need to consider especially as we receive interest from so many part-time workers.

Why is the anger happening in the Korean community but not the English-speaking, Chinese, Russian, Japanese or Spanish communities?
I’m not entirely sure why this is. I do know that when DAC workers previously expressed timelines, those timelines were presented (in English) in a nuanced way with qualifications. Subsequently, it appeared some of the discussion in the Korean chat rooms had lost this nuance and may have been being presented as hard-and-fast promises.

eosDAC chose to support more language communities than many other projects. There is a lot to learn about how to manage multi-language communities and ensure accurate and consistent messaging.

Where are we now? The current situation
Specifically with respect to the subject of this post - handover of the affairs of the DAC to elected Custodians - as of 7 November 2018, the most immediate state of play is:

• Substantial, innovative work with respect to permissions has been recently completed

  • This work was created by Michael Yeates and is critical to the smooth functioning of the DAC once it is in the control of Custodians. Complex multisignatory functions and permission levels had to be created and aligned with eosDAC’s Constitution. For example, permissions functions on the main Custodian multisig account have to allow payments to be sanctioned by the correct number of Custodians, and prevent funds from being dispatched if too few Custodians agree. Those Custodians change weekly.
  • These workflows will proceed programmatically once the governance of the DAC is given to Custodians - so if they don’t work properly, we may all be exposed. The area of permissions is crucial for the success of the handover.

• Permissions coding is being reviewed by external parties. This takes time and we cannot simply demand that external third parties, who are themselves a highly scarce resource drop everything and prioritise our workstreams over all their other work.

• We are rapidly finalising the off-chain contracts and governance structures necessary to allow a DAC to exist in the real world. As has been discussed with the community, the previous attempts to manage risk through the company structure of eosDAC Ltd didn’t work because banking and insurance weren’t available on that Caribbean entity. Subsequent to that, we also explored the viability of operating in accordance with how we actually see ourselves - as a loose collection of workers with a shared goal but without a defined legal structure. There is a vast swathe of opinion on the ethics and practical possibility of decentralisation itself being the force that mitigates risk in collectives such as ours. We had to investigate, fact-find and then assess the relative merits and demerits of different routes to organising ourselves, our agreements and our affairs. We epect that we will very soon finalise these solutions.

So - when are we going to launch elections?
We are working as hard as possible, we are focussed entirely on this goal, and we are committed to launching elections extremely rapidly. We want elected Custodians and all the new unknown unknowns they will bring!

We are not financially incentivised to keep stringing this along. DAC developers are charging the DAC very reasonable rates given the supply and demand dynamics discussed. I personally, and our lawyers, are charging significantly sub-market rates. Because we love this project and we believe in the impact it could have on the world.

We hear you that some of you are upset, angry and now doubt our motives.

The truth is, we couldn’t be putting more fire power into innovating the brand-new solutions we’re creating, which we hope will be used by DACs for a long time to come. We are happy to be part of disrupting existing structures that entrench vested interests and serve a few incumbents. We are willing to risk, try and fail as we break new ground. We’re working very hard.

We invite you to find ways to contribute and to stay tuned for upcoming announcements.

Thank you.

CAUTIONARY NOTE ON FORWARD-LOOKING STATEMENTS

All statements contained on this website, statements made in press releases or in any place accessible by the public and oral statements that may be made by eosDAC or its respective Custodians, executive officers, advisers, community members or anyone acting on behalf of eosDAC, that are not statements of historical fact, constitute “forward- looking statements”.
Some of these statements can be identified by forward-looking terms such as “aim”, “target”, “anticipate”, “believe”, “could”, “estimate”, “expect”, “if”, “intend”, “may”, “plan”, “possible”, “probable”, “project”, “should”, “would”, “will” or other similar terms. However, these terms are not the exclusive means of identifying forward-looking statements.

All statements regarding eosDAC’s financial position, business strategies, plans and prospects and the future prospects of the industry which eosDAC is in are forward-looking statements.
These forward-looking statements, including but not limited to statements as to eosDAC’s revenue and profitability, prospects, future plans, other expected industry trends and other matters discussed here regarding eosDAC are matters that are not historic facts, but only predictions.

These forward-looking statements involve known and unknown risks, uncertainties and other factors that may cause the actual future results, performance or achievements of eosDAC to be materially different from any future results, performance or achievements expected, expressed or implied by such forward-looking statements. These factors include, amongst others:
(a) changes in political, social, economic and stock or cryptocurrency market conditions, and the regulatory environment in the countries in which eosDAC conducts its respective businesses and operations;
(b) the risk that eosDAC may be unable or execute or implement their respective strategies and future plans;
(c) changes in interest rates and exchange rates of fiat currencies and cryptocurrencies;
(d) changes in the anticipated growth strategies and expected internal growth of eosDAC;
(e) changes in the availability and fees payable to eosDAC in connection with their respective operations;
(f) changes in the availability and salaries of workers who are required by eosDAC to operate and build their respective businesses and operations;
(g) changes in preferences those with whom eosDAC interacts;
(h) changes in market conditions under which eosDAC, and the ability of eosDAC to operate under such conditions;
(i) changes in the future capital needs of eosDAC;
(j) war or acts of international or domestic terrorism;
(k) occurrences of catastrophic events, natural disasters and acts of God that affect the businesses and/or operations of eosDAC;
(l) other factors beyond the control of eosDAC; and
(m) any risk and uncertainties associated with eosDAC.

All forward-looking statements made by or attributable to eosDAC or persons acting on behalf of eosDAC are expressly qualified in their entirety by such factors. Given that risks and uncertainties that may cause the actual future results, performance or achievements of eosDAC to be materially different from that expected, expressed or implied by the forward-looking statements on this website, undue reliance must not be placed on these statements.

Neither eosDAC, nor any other person represents, warrants and/or undertakes that the actual future results, performance or achievements of eosDAC will be as discussed in those forward-looking statements. The actual results, performance or achievements of eosDAC may differ materially from those anticipated in these forward- looking statements.

Nothing contained on this website is or may be relied upon as a promise, representation or undertaking as to the future performance or policies of eosDAC.

Further, eosDAC disclaims any responsibility to update any of those forward-looking statements or publicly announce any revisions to those forward-looking statements to reflect future developments, events or circumstances, even if new information becomes available or other events occur in the future.

-Saro

Please vote for eosdacserver

Join our newsletter to stay informed and follow us on your favorite social media platform:

_{Steemit | Discord | Telegram | Facebook | Twitter | Google-plus | Github | Instagram | Linkedin | Medium | Reddit | YouTube | Weibo| VK| Bihu}