Web 2.0 DAO — Part I

How I’d (Fail) To Build a DAO in 2010

A historical dramatization of two young entrepreneurs starting a DAO in 2010

Why No DAO in 2010, but DAO in 2016?

I live in an echo chamber of cryptonatives, and post-DeFi summer, also of a new cadre of crypto transplants who are white-knuckled bulls nonetheless (usually for monetary rather than ideological reasons as it used to be, but so it goes).

My bubble was didactically burst the other day when a friend new to the space asked me “Why didn’t decentralized autonomous organizations (DAOs) exist before blockchain? We already had the Internet for people to coordinate in a decentralized way” (he really said that parentheses, acronyms and all 😉).

Spending most of my time in the weeds and compiler errors, I rely on these fresh, foundational questions, unencumbered by assumptions and biases that are by now baked into my brain stem (at least I admit it 🤷🏼‍♂️), to break me out of my herd and remind me that I too, as much as anyone else, am subject to groupthink.

Let’s take this question as seriously as possible to explore the way our modes of collaboration are shaped by the tools available to us.

Why didn’t DAOs emerge in the early 2010s?

After all, the Internet already had near total penetration in developed countries, and people were operating as decentralized teams on everything from open source software to online encyclopedias to file sharing.

To frame the matter more provocatively…were Apache, Napster and Wikipedia the first DAOs (scandal!)?

If not, then what was it about blockchain and cryptocurrency that suddenly spawned this renaissance of online collaboration that DAOs have enabled?

In a previous article, I covered the benefits and drawbacks, as well as the ingredients, of both trust and trustlessness.

Summarizing here, on trust:

Trust is the ability to have confidence in an outcome because of your personal relationship to the actors involved.

Trust is built on extrapolating from past behavior, shared context, and mutual benevolence.

And trustlessness:

Trustlessness is the ability to have confidence in an outcome because of the incorruptibility of the system mediating your collaboration with other actors.

Trustlessness is built on transparency, verifiability and immutability.

To see why DAOs emerged when they did, we will evaluate the three main branches of any modern organization:

1. Tech stack (what the CTO leads)
2. Accounting system (what the CFO+COO lead)
3. Governance system (what the CEO leads)

along the trustlessness criteria outlined in my previous article:

1. Transparency — I can see the internals of the system
2. Verifiability — I can see the inputs and outputs to the system, and confirm that the rules I believe are running the show are indeed the rules running the show
3. Immutability — I know these rules cannot be changed arbitrarily

For each of these three organizational branches and three trustlessness criteria, we will look at what was possible first in 2010, and then in 2022.

I believe this sieve is a fitting framework for filtering out the primary reasons why decentralized autonomous organizations emerged just when they did in 2016, and no earlier.

To see why blockchain was a necessary prerequisite for the emergence of DAOs, let’s try to build a DAO without blockchain.

Welcome to ForexNow 🌎💸 — the world’s first Web 2.0 DAO for currency trading.

We embark!

[Reader teleportation note begin]

I dwell on the “How ForexNow works in Web 2.0” two times longer than I do on “How ForexNow works in Web 3.0”.

This is because there are innumerable articles written on every DeFi solution out there, and I don’t beat dead horses.

If, like me, you came up in Web 3.0, I encourage you to wade through the Web 2.0 quagmire in order to feel second-hand the galvanizing inefficiencies spurring blockchain’s emergence.

If, however, you just want my take on Web 3.0 DAOs, go right to Building Web 3.0 DAO — Part II, and skip my Web 2.0 quagmire.

Pick your adventure my friend.

[Reader teleportation note end]

Building Web 2.0 DAO

The tech, accounting and governance of the 2010’s

Let’s imagine I wanted to rally a squad of devs, creatives and biz dev whizzes to create a currency exchange platform with a trustless and flat organizational structure, ForexNow DAO.

In this organization we want:

• No clear “leader,” e.g. a CEO
• We want value to accrue back to the decentralized community maintaining and using ForexNow
• We want to coordinate our development without relying on top-down management, offices, traditional meetings, stocks, boards of governors, and the like

This organization will need three things to keep members involved, acquire users, and keep the platform moving along:

• A tech stack
• Accounting
• Governance

Let’s build out the Web 2.0 tooling for each of these core areas.

Each of the three organizational branches of tech, accounting and governance will be evaluated along the three spectra transparency, verifiability and immutability, the foundations of trustlessness.

Let us begin with a techno-historical journey into the now-antiquated software of 2010!

Web 2.0 DAO — Tech Stack

To begin with a quote from the venerable Vinay Gupta in 2016:

[Prior to blockchain] Software exists inside of a given organization or inside of a given individual’s property. Even if it’s running in the cloud, it’s running in a piece of cloud that you rent, therefore it’s your cloud. The result is that the software always has the agency of the person that is paying for the software to exist…As a result software doesn’t change the trust architecture that exists in the world.

What Vinay is saying here is that no matter how distributed the organizational players, the keys to the kingdom are clear — it’s the server admin, the one with push access, the one with release permissions.

Let’s see what this looks like in the actual technology available at the time, as we build along the “bleeding 2010 edge” to see if we can mirror current day levels for decentralization for ForexNow DAO (hint: we can’t).

The Basic Stack

ForexNow would have a frontend client running in the browser and hosted on a content delivery network (CDN). We’d have a backend API and a database. hosted on either rented rack space or on-premise in a DAO members’ house (good luck finding Linux admins 😉).

Coordinating Development

For coordinating development, there would be an open source GitHub repository where devs can watch other devs work. Perhaps we’d have a mailing list with admins using the official admin@forexnow.com domain name.

P2P Filesharing
Actually, in 2010, distributed storage (not memory — think hard drives, not RAM) was already quite well developed. Peer-to-peer (P2P) filesharing had blossomed in the early 2000’s, in part as a response to the imposition of digital rights management (DRM) restrictions on content. Napster, Kazaa (early project from the creator of Skype), eMule, and many other P2P networks you’ve likely never heard of were innovating faster than music label lawyers could file lawsuits against these groups non-existent leaders.

So ForexNow could store its documents in such a way that they are trackable by all, though there would be no real way to determine the canonical copy besides the official mailing list from admin@forexnow.com, which itself would be sent from a likely centralized account.

Runtime
Things break down when it comes time to deploy ForexNow in a decentralized way.

Like Vinay elucidated above, non-admin members of the ForexNow DAO could not confirm that what they saw in the open source GitHub was indeed what was running in production. The ForexNow admins could secretly inject code that siphons off small amounts of trading fees to their own bank accounts, a la Office Space, and there would be no way for non-admins to see this without deeper analytics.

Lack of decentralized and transparent compute platforms is a primary shortcoming in Web 2.0. This is a death sentence to any DAO trying to run in 2010, as decentralized and transparent compute is the primary way in which blockchain opened up new avenues for trustless collaboration.

As decentralized as it gets?
I believe the following is the most decentralized one’s tech stack could be in 2010 without major sacrifices to usability. Correct me in the comments if I’m missing something and I’ll add it, promise — as I was born in that terrible netherspace of millenial/zoomer and had just started coding in 2010:

• A frontend running in the browser and served from rented rack space, or self-hosted
• A database cluster in a master-slave arrangement, replicated across the globe for quick reads, but with only certain replicas having write access (Distributed, but not decentralized).
• P2P file storage (yay! This is a definite “almost as good as what we have today” decentralized solution)
• Decentralized version control with Git, semi-decentralized collaboration on GitHub
• Some schedule of who is hosting our servers and when, allowing for a ring of admins rather than a single admin. This is what Wikipedia used to do.
• A centralized and censorable DNS root resolving our forexnow.com domain name

Trustlessness Assessment

Let’s assess this arrangement based on our three trustlessness criteria of transparency, verifiability and immutability.

Transparency
The code is transparent and work is auditable on GitHub. We could distribute ForexNow’s critical documents on a P2P filesharing network and have a canonical copy communicated in our mailing list, pinning the “true” source as designated by admin@forexnow.com.

This is fairly transparent. But can you be sure that what you read is really what you’re getting when you trade currency on ForexNow?

Verifiability
There are three different kinds of verifiability for software:

• source code
• binary
• runtime

Source code verifiability comes from being able to see the code. This is a long solved problem, and is at the core of what the open source software movement is all about. For example, if you have an Android, you can read the source code here for your particular operating system release. Done.

Binary verifiability comes from being able to determine if a compiled binary (tech speak for the thing actually running on a device) did indeed originate from the same human readable source code you saw on GitHub in the transparency step.

How do you do this? You can verify a binary by compiling the source code you read, and running the output binary through a checksum. If the checksum matches the checksum you see on your device under some well-hidden Settings page, you can be reasonably sure it is the same thing. But still, not 100%…

Runtime verifiability means that when you send a request to a binary, you know exactly which binary is running, not through trusting any checksum or screen display, but because you can verify the code running AT THAT ENDPOINT. By endpoint I simply mean the binary you are sending input to — a transaction, a message, a sexy image, what have you.

Web 2.0 really falls short in runtime verifiability.

Even if I can see the source code and verify the checksum of the latest release, I am still unable to guarantee that what I see in GitHub is in reality the code which will be deployed to production servers and executed in the real world. The binary could be switched out at the last moment, and a false checksum published to users!

Facebook can publish the checksum for the APIs running on their servers, but can you really know that this is where your embarrassing messages are being processed?

Runtime verifiability is the core problem that blockchain solved, as we’ll see later.

Without runtime verifiability, you can never be 100% sure that what you read is what you get.

Immutability
Code in Web 2.0 is fully mutable.

Code on a central server can change however the admins choose. Code can be added or deleted from the release, causing it to differ from that shown on GitHub.

Even though our documents can be published on a P2P network, we can’t stop people from changing them and re-releasing, casting doubt onto which is the canonical copy.

So all in all, besides some aspects of file sharing, 2010 would have been a rough time to coordinate software deployments that can be fully trusted by strangers who have never met, especially once money gets involved.

At any rate, verifiable or not, it is time for ForexNow to make some money.

We turn now to Web 2.0 DAO accounting 💰.

Web 2.0 DAO — Accounting

ForexNow has three streams of currency to manage:

Escrow: ForexNow must secure large sums of currencies in several denominations across several international bank accounts to provide liquidity across trading pairs

Trading Fees: ForexNow must meter trade volumes to siphon appropriate trading fees as our primary income stream

Payroll: ForexNow must have a a payroll to incentivize our decentralized team of devs, marketers and business developers

The centralization of accounting in Web 2.0 DAO is blatantly obvious and gyroscoped around two points of unilateral control — banks and admins.

First, the banks! (I suspect most readers will drop off here to spare themselves the cryptobro launching into the by-now trite diatribes against Wall Street. Hang tight, I won’t!).

Banks are great, but I have no idea how I would set up a programmable escrow, how I would do so across borders, and how I would programmatically access the escrow when users made withdrawals from ForexNow. I’m sure someone knows, and we could hire them. But if it requires a hire, then it’s non-trivial.

Even once you did manage to establish a transnational programmable escrow, there is still the matter of administering it securely. Whitelisting certain organization members on the account is an option, but who maintains that whitelist. Another admin.

It’s admins all the way down.

For metering trading fees, I assume this might be some batched process at the end of the day, week, month where we take our cut from a pool of transactions. I personally don’t know, but given Plaid, Venmo, Coinbase and any other centralized, transaction fee reliant organization employs a large army of developers to meter trades, I assume it’s a non-trivial task as well.

For payroll, we’d likely have the good ole’ 1099s for contract workers invoicing us, and W2’s for salaried employees. From ForexNow’s bank account to theirs, money flows through our banks. The COO oversees all of this, as will a large HR department. In payroll, the buck here stops with the labor courts — if we screw over a contractor, they can take us to court. Same with employees.

Trustlessness Assessment

Transparency
There is very limited realtime transparency for ForexNow DAO members, save perhaps for quarterly reports distributed and subject to SEC regulation.

As a non-admin member of Web 2.0 DAO, I can’t really know for sure how the flow of capital is without gaining a lot of permissions in our bank accounts and asking a lot of questions.

Verifiability
The enforcement of verifiability of accounting for centralized organizations typically falls on the shoulders of a governing body. In the case of securities in the US, that’s the SEC.

This is done through a subpoena to produce documents and demanding an audit — essentially, if you don’t let us see your documents, we kick down the door and take the documents ourselves.

Immutability
Let’s interpret immutability of accounting as meaning that no one is “cooking the books,” i.e. manipulating the ledger in such a way that enriches a privileged cohort in the organization or covers up financial malfeasance.

Mutability of centralized financial records is as old as time, and the reason we require groups like the SEC to protect consumers and investors against this form of financial abuse. If a person or colluding group with admin banking privileges wanted to cook the books, it’s possible to do so without most other ForexNow contributor’s knowing — that is, if it’s done well 😏.

Web 2.0 DAO — Governance

“Why do you think voter turnout is getting lower and lower?” asked the smart-ass.

“I think” says [the parliamentary tour guide], “that the current government successfully addressed this problem when we decided to stop publishing voter turnout numbers. The next logical step, by the way — keeping the election results secret as well — is currently a hot topic of debate behind closed doors.”
- QualityLand, by Marc-Uwe Kling

Governance is composed of three interrelated steps:

1. Distribution of votes
2. Tallying of votes
3. Enforcement of decisions

First, we decide who gets to decide.

Then, we decide.

Then, we do.

This is governance.

In the case of DAOs, what we are deciding on is typically the future of a software platform, how to deploy treasury funds, and who gets the privileges to decide on the previous two.

Whether or not voting is an actual democratic reflection of the group’s desires depends on two things:
- vote distribution
- vote tallying

Distributing Votes
Who has the right to issue votes? Who has the right to cast votes?

When distributing votes, the distributor has the power to decide who gets to decide.

One vote matters — dictatorship

A group of privileged votes matter — consortium

All votes matter — direct democracy

An elected official votes on behalf of constituents who elected them to decide for a certain period — term-limited representative democracy

The tried and true way voting distribution was achieved in Web 2.0 was through traditional corporate structures like foundations, corporations and sole proprietorships. Voting shares and board seats decided both how votes were distributed and how tallying was performed.

Those with preferred voting shares could vote, those with common stock could not.

But we’re trying to build a DAO in 2010! Of course we could elect a board, but let’s get creative and see how we could use the tech of the era to make our own votes.

So, if I wanted to get creative and avoid the obvious centralized route of shareholders and board meetings, maybe I could build my own vote distribution and polling system. Kind of like that time Mountain Dew let us vote on a new name.

I create a database with two tables — one called Users and one called Votes. Next to the users is a number representing how many votes they get. The total number votes is limited by a totalSupply field in the Votes table.

I might have a PayPal where people pay into an international ForexNow bank account to pay for me to raise the number of votes next to their name in the ledger.

That database might have multi-signature cryptographic access controls, maybe a password-protected updates which is the hash of 3 out of 5 admins passwords, thereby only allowing certain operations to be done if multiple people sign off. Something like:

Input: sha3(adminPassword1 + adminPassword2 + adminPassword3)
Output: 94682732ce37176e9b96f83ad1ae7c1e1e377e078c0f745402199d3b1b92bfeb

And repeat the above for all 60 permutations of admin passwords. Not bad. But still — most databases have superadmins that can change admins…ignoring that for now 🙃.

Again, it’s admins all the way down. Nothing is autonomous in Web 2.0.

To really decentralize things, I make replicas of this database and distribute it to several other people in ForexNow who I know.

Well, since I know these people, I could always collude with them to make unilateral writes to the database. Sure you could do some acrobatics to become increasingly decentralized, but the potential for collusion is always there.

With these obvious difficulties, it’s likely we would eventually just settle on a traditional corporate entity and let the buck stop in the courts.

And all of that is only for vote distribution — we haven’t even tallied them yet.

Tallying Votes
How are the votes tallied? How is the outcome verified and trustworthy?

Well…this is a tough one. Remember that I control the database. And there is no runtime verifiability in Web 2.0. It’s very possible that either the tallying script or the database could be modified by admins.

Enough said. We get the point. We come up once again against the duo of trustless destruction in Web 2.0 — lack of runtime verifiability, and admins all the way down.

Enforcement

Enforcement without voting is dictatorship.
Voting without enforcement leads to voter apathy.

Once a proposal passes, what is the enforcement mechanism for ForexNow to execute the results of that proposal?

In a Web 2.0 world, the board can always sue the CEO for negligence if they fail to enforce board decisions. This is essentially the enforcement mechanism for actioning decisions. The buck stops in the courts, as usual.

But if there isn’t a CEO who is legally beholden to shareholders to follow through on their decision, then where does the buck stop? I guess on the next ForexNow board election for our “not CEO but still leads the show”?

All of this taken together — vote distribution based on shares, tallying occurring in board meetings, and enforcement falling on the CEO — is what many in the DAO space refer to as paper governance. The very name paper governance hints towards how well this is about to do in terms of our decentralized criteria of transparency, verifiability and immutability.

Trustlessness Assessment

Transparency
Paper governance is somewhat transparent. The minutes of a board meeting can be published and voting outcomes shared.

In terms of our vote distribution and vote tallying tech stack, I’d give this a near zero. There are so many points at which ForexNow admins could collude to misrepresent shareholder amounts and the outcomes of elections — in the database, in the UI where users watch proposals, in the vote tallying script. Endless opportunities for scams.

Verifiability
The verifiability really breaks down in the tallying. I suppose one could run the tallying script locally and see if they get the same result, but there are still ample opportunities for those behind the scenes to collude on the raw vote data before you as a lowly ForexNow contributor get to run your script locally.

Immutability
It is the ForexNow admins with replicas of the voting database that can execute writes to the database together. Votes are immutable insofaras you trust your custodians not to collude. There’s really no way for you to confirm.

That was a lift…

Yeah. So a lot just happened in 2010. Operationally this sounds like quite a lift without having a requisite increase in trust to justify foregoing a traditional closed, shareholder based organization.

At the risk of falling into the infomercial grift of strawmanning current solutions only to Messiah in the new solution (comedic relief as a reward for reading this far), let’s see what it looks like to build a relatively transparent, verifiable and immutable DAO in 2022.

In Part II, we do all the same things we did in 2010 — tech stack, accounting and governance— but with all the might of decentralized tech in 2022.

Continue the show, if you dare, by clicking [here in the near future. Will be released once I’m done editing…].

See you soon space cowboy…