Introduction

Immediate apologies to those expecting spiritual commentary regarding “the flow of The Way”; the DAO that I’m going to talk about here is the Decentralised Autonomous Organisation, a relatively new concept in organisational structure with a heavy technological underpinning. I’m going to look at what I have learned from running a software company that develops (in part) workflow software and see how the fledgling DAO could, in my opinion, massively level-up its utility and adoption by leveraging some concepts that us old-timers have been working with for years. I will illustrate these concepts using screenshots from Alemba’s software but only because I’m lazy and it is accessible to me. This article is about workflow and DAOs in general and is tool-agnostic.

Background What is a DAO and Why You Should Care

DAOs have been making headlines as “the next big thing” for a few years now. They take the promise of decentralisation, as evidenced successfully by Bitcoin, and apply it to a governing a collective. I use the term “collective” very neutrally for reasons that will be come clear later on. For now it just means a gathering of people who have come together for some reason and want to play by some kind of rules.

Historically at this point they would be faced immediately faced with a number of business and legal questions: how is the collective to be manifested? Private company, charity, co-op, public company, partnership, informal group that has no legal entity but still wants agreed rules of engagement? Depending on the option chosen there is then likely to be another round of contract/paperwork preparation often requiring expensive legal services. Shareholders agreements, Memoranda and Articles of Association, Directors’ agreements, loan agreements, contractor agreements, and so on.

What the DAO does, at a simple level, is to take all that corporate/legal paperwork and distil it into a series of software rules.  The further magic is that once those rules are established the DAO sits and whirs away forever impartially and objectively adhering to the rules that have been agreed. There are two exceptions to this: (1) if the software is hacked (and this has happened although DAO software has progressed significantly and in the case of the notorious “the DAO” hack it wasn’t the underlying DAO software that was hacked anyway); (2) if, by the previously agreed voting mechanisms, the DAO members agree to change the way the rules work.

Bad news for my legal/corporate administration friends – I see a massive reduction in this kind of fee-work, already started by the internet “company in a box” type services. The good news is that I predict there will be a burgeoning industry of turning shareholders agreements into DAO rules!

So think of the DAO as a corporate machine: set it up, tell it the rules it operates by, and release it – tamper-proof and resistant to coercion forever.

If all of that sounds like hard work to manage the membership and treasury of your local bridge club then the good news is that there is out-of-the-box software to help you get this up and running. For example Aragaon (https://aragon.org/ ) and DAOHaus (https://daohaus.club/ ). It is to the custodians and planners of such companies that my later “Lessons” sections are addressed although my colleagues in the world of existing workflow solutions will enjoy several “I told you so” moments.

The Evolution of DAOs – DAO as Legal Entity

Before we get to that though there is one final development that is critically important in the rise of the DAOs and that is the creation of the BBLLC. In the introduction section I’ve talked about governance and operations being managed autonomously by the DAO software. This doesn’t cater for the creation of an actual legal entity, though, and there was an uneasy overlap between traditional legal structures and the day-to-day working of the DAO. As an example, a group of crypto-interested mates and I looked at a DAO as a crypto-investment vehicle. At first glance it looked perfect. We could easily set up voting rules around who could apply to join the investment club and how they would get voted in. We could then equally easily set up rules for lodging proposals for buying/selling crypto coins or tokens. And finally the distribution of profits would be trivial based on the ledger nature of the DAO transactions.  However, what would the actual entity be? How would it be based in a jurisdiction and how would you manage things like capital gains tax? It was this disjoint that finally dissuaded us from the project.

However, legislators in Vermont and Wyoming have created a completely new legal entity – the Blockchain-Based Limited Liability Company. Now you can have your DAO (which is blockchain based) as itself the legal entity. With all the benefits that limited liability offers as well as clarity about its legal status and ensured peaceful existence within known corporate and legal structures.

Lesson from Workflow 1 – Structure and Graphical Canvas

And so armed with your new BBLLC and the DAO software you can begin to coordinate effectively with your colleagues. However, for someone steeped in the world of workflow there are some shortcomings that will quickly become apparent and in this and the following sections I’ll draw these out. Not being a blockchain developer, I don’t know the exact limitations of the underlying technology and smart contracts but…how hard can it be, right?

Firstly there needs to be a slightly more sophisticated structure than currently exists (if I’m wrong on this, DAO developers please let me know). There needs to be the overall container of the proposal or workflow itself. This entity would have attributes that could be visualised/maintained as a form. Ideally extensible so DAO members could add their own custom fields (this is important later). Then the actual workflow elements would be their own entities but linked to the parent proposal/workflow. There should be dependency links between these so that, for example, workflow element B doesn’t get released before workflow element A is completed.

Doing anything like this in text or grid form is tricky. We have got used to nice visual canvases and for the corporate DAO I would expect that its users would demand this.

Lastly, having created a workflow to embody the particular DAO rules that I want, I would expect to be able to save this as a template and then make that template available as a “canned” proposal type with built-in workflow. So I have two user stories, as a workflow designer I need the canvas and ability to stitch together a workflow. As a DAO member I simply need to see the list of available proposal/workflow types available to me, select one and fill in the form details before submitting.

Taking the first use case, imagine that I want to create a simple template for the most basic proposal: “Please give this SEEDS account holder x SEEDS because they are going to do the following….”

In my screen designer I create the fields that I need then drop them onto the form.

Graphical user interface, application

Description automatically generated

Lesson from Workflow 2 – Decision-Making Workflow Elements

The container and form are only the first part, though. When this workflow is kicked off I want it to do things. Again for simplicity I want it to go out to the DAO members to vote on. Then I need some kind of rule to determine whether enough votes have been cast in favour of the proposal. In ASM and many workflow tools such workflow elements exist. Typically an email is sent from the system that allows an Approve/Reject be sent directly via email or else you can go to a webform to view the detail of the proposal and then vote.

Behind the form my workflow could look like this:

Chart, radar chart

Description automatically generated

In this DAO we only have five members but the principle remains the same and the system (and most workflow systems) can dynamically multiply the number of approvals based on rules (i.e. all the members of the DAO, so no hardcoding needed). You may spot other workflow elements in the top toolbar that can be dragged onto the canvas. We will just look at two more of these.

The next is the enumerator control which contains rules to say whether the number of votes is enough to pass the proposal. Let’s say that for our DAO we just need a simple majority (not a good idea in real life!)  First I drop in the new workflow element:

Diagram, radar chart

Description automatically generated

Behind that Enumeration element (drill down on the graphic to get at the form behind it) we set up the activation score. As mentioned if three if the five votes come back as yes (indicated by the green lines on the diagram above) then we pass the proposal. By default every vote gets a score of 1 but this could be modified to weight some votes more than others if the DAO rules allow it.

Graphical user interface, text, application

Description automatically generated

Lesson from Workflow 3 – Integration for Doing

Lastly all this decision-making workflow is great but it would be even better if no human has to manually action the proposal if it is passed. This is where the integration platform comes in. As we already know the account that we will be depositing into and we know how much is to be deposited we could simply make an API call (assuming a SEEDS API exists) to robotically deposit the SEEDS into the account.

Diagram, radar chart

Description automatically generated

Again we drop out the workflow element onto the canvas, link it up and then drill down to get at the form that sits behind it. In the case we simply add the URL to call. The beauty of this task is that we can also pass through parameters that come from the parent workflow form. So here the values in the fields “SEEDS Account” and “No SEEDS Required” get passed directly into the command/URL being fired off.

For error handling we can trap a fail event (for whatever reason) and we can send an email to a human to say that the transaction has failed. Maybe we can also send an email on successful completion (a different email template for good news!) and wrap up the workflow at this point which will automatically shut itself down.

Chart, radar chart

Description automatically generated

This template building is only done once. As I user I simply select the template from a list of choices and then fill out the very simple form:

Graphical user interface, text, application, email

Description automatically generated

All the workflow actions happen automatically in the background.

It would be nice if you could look at the approvals at any moment in time and see how the votes are going and who has voted and who hasn’t.

Conclusion

There is a lot more that you could do but hopefully this example triggers some thoughts about how the underlying DAO software could be made even more powerful by introducing modern workflow concepts and a graphical UI for from and workflow design. DAOs are an exciting new development in terms of ogranisational entities and making the control software as easy to use and as powerful as possible can only speed up their adoption by the mainstream.