In the past few decades, our trust in institutions has begun to erode:

• When government officials lied about invading Iraq, we lost trust in our representatives.
• When banks lied about the creditworthiness of mortgage backed securities, we lost trust in our financial institutions.
• When news outlets began to report false information, we lost our ability to trust credible news media.

Trust is the cornerstone of any organized society, from student clubs to governments. If we cannot be assured that our peers will follow the same rules we operate from, we hamper our ability to cooperate with one another.

And so we attempt to codify trust. We create charters and constitutions to set fundamental rules for the game. Laws help further elucidate the nuances of these rules and we employ physical and financial force to create a cost to not playing fair. In doing so, we create a strong system of assurances that you and I will respect the rules of the game through codification, cultural norms, and consequences.

For most of human history, these structural guidelines existed at the social layer. They required humans to create, disseminate, and enact these rules, which ended up being fraught with operational error, human biases, or limitations on available resources. As an example - we say the law is blind and applies indiscriminately, but because we rely on humans to enact laws, we run into biases around race, gender, socioeconomic status, and other demographics.

However, we live in the 21st century, surrounded by rapid innovations in technology with deep implications for how we organize and trust one another. We are able to encode rules into our technologies and minimize reliance on humans as intermediaries, though even encoded rules have biases.

In doing so, we begin to shift organizations from purely socialware to those aided by trustware.

Trustware vs. Socialware

Contracts, laws, charters, constitutions, and other such agreements are mechanisms that organizations use to set rules between agents in a system in order to assure certain behaviors. This assurance can come from two places:

• Socialware - Mechanisms that create assurances through human relationships, incuring a high social coordination cost
• Trustware - Mechanisms that create assurances through technology, incurring a low social coordination cost

Take, for example, a simple lemonade stand. You could set up your stand and sit there for a few hours, waiting for people to come by and purchase your delicious drink. But the assurance that people will pay is enforced at the social layer - no one will steal or underpay for a drink if you are standing there, monitoring each transaction. Though this method produces high assurance, it comes at the cost of your time. This is socialware.

A form of trustware would be a vending machine. It serves the same purpose as a lemonade stand, but the machine itself produces the assurances through technology. It’s much harder to steal or underpay when the rules are codified into a physical machine that dispenses lemony goodness.

Take another example: Protecting your valuables. You could lock your belongings away  (trustware) or rely on the legal system to protect them (socialware).

In theory, both assure that your property will be protected. The lock provides assurance through its physical presence while the law provides assurance through consequences with decades of precedent. However, in actuality, socialware is only respected when the outcome is enforced through coordination between lawyers, judges, and law enforcement whereas the lock’s enforcement is embedded into its function.

Furthermore, the social cost of the law is high. Setting up contracts involves lawyers, money, time, and knowledge of the legal system. The social cost of a lock is low - it’s easy to install a lock and distribute keys to trusted key holders, all of whom understand how keys and locks work.

Socialware and Trustware in DAOs

Blockchain and smart contracts are a massive technological level-up for trustware. Through code, we are able to create strong assurances that members of a given system will behave as the system permits them. They cannot lie, cheat, steal, or manipulate by breaking or bending the rules.

By using blockchains as our underlying assurance mechanism, we can codify organizational governance through code and not purely documented principles that rely on humans to coordinate around. In doing so, we foster greater trust between parties by minimizing trust in people and maximizing trust in technology.

This is the great “promise” of DAOs - code at the center, humans at the periphery. This is the idealistic model that allows us to maintain flat organizations that rely on consensus because we can outsource the execution of decisions to code. DAOs were envisioned as mostly trustware.

However, anyone that has worked within a DAO in the past year knows this is rarely the case. In reality, many DAOs operate using socialware, relying on documented practices and hoping there is sufficient human attention and coordination to follow these written rules.

Socialware in DAOs

Much of the organizational structure and governance in most DAOs exist at the social layer. Through codified documentation and processes that live on Notion and Discourse, we set rules about quorum, term limits, voting thresholds, etc then proceed to vote on Snapshot, and rely on a multisig to execute the terms of the snapshot vote as per the rules we set.

I’ve had a lot of these experiences at BanklessDAO. We spent dozens of hours working to set proper rules, such as the Project Proposal Framework, Governance Rules, Seasonal Specification, and Writers Guild Governance document.

Although we had systemized our rules, we still relied heavily on human coordination. These rules only mattered if we had the awareness to follow them. And because humans are prone to error and forgetfulness, there were many times we did not abide by our own standards.

The high social coordination cost of socialware often results in a gap between how a system is supposed to operate vs how it actually operates.

Trustware in DAOs

Trustware in DAOs means bringing rules on-chain. Using blockchain and smart contracts, rules defined at the social layer can be brought on-chain and enforced without reliance on human coordination.

There are a number of examples of trustware in DAOs - Juicebox, Moloch, Governor, and Pods to name a few. These tools allow humans to make decisions at the periphery and rely on code to execute the consequences of their decisions, as defined by the rules of the governing smart contracts.

This type of technology is different from simply digitization. Digitization takes something analog and makes it digital, including all sorts of redundant human tasks. Trustware is a subset of digitization that focuses specifically on trust agreements that incur a social cost through coordination. Digitization often reduces social coordination costs, but it doesn’t focus specifically on trust. We cannot digitize trust until we have sybil and censorship resistance - both qualities of blockchains.

Take, for example, the Governor contract. As mentioned above, many DAOs use a combination of Snapshot and multisig, including BanklessDAO and Yearn. In these cases, token holders vote on Snapshot, but rely on coordination between multisig signers to execute their decision - a form of socialware. The governor contract automates this step, automatically executing a transaction as soon as a vote reaches certain governance parameters, like quorum or submission thresholds. The governor contract provides equal assurances as the Snapshot + multisig combination with less social coordination. In other words, trustware.

The trust-minimized environment that trustware creates is what allows strangers to raise $40 million to buy a copy of the Constitution. Such outcomes would likely not be feasible if relying on legal assurances and not smart contract assurances.

Trustware as a Spectrum

One important caveat to note is that trustware and socialware exist on a spectrum. The definitions above are relative to one another, they are not absolute.

Multisigs are a great example. At Orca, we had a weeks-long debate on whether multisigs are trustware or socialware. After all, having a treasury managed by multiple signatories reduces the harm of any one bad actor relative to a single address controlling all funds. But at the same time… have you tried wrangling multi-sig signers? It still requires quite a bit of social coordination.

We settled on the fact that multisigs are closer to trustware than a single EOA account, but closer to socialware than something like the Governor contract or even pods.

Balancing Trustware & Socialware

Trustware is not the end-all-be-all for DAOs. DAOs are inherently human organizations that will require systems that adapt to how humans relate and behave, not robots. But successful DAOs will have a combination of socialware and trustware, each with its own healthy balance depending on the needs of the DAOs.

As of now, most DAOs orient heavily towards socialware, for apparent reasons:

• Socialware is flexible and can adapt to changing circumstances much faster than trustware
• Socialware is easier to implement, requiring less technical knowledge and execution
• Trustware can leave a DAO susceptible to governance attack vectors
• Trustware is still underdeveloped and cannot adapt to the granular needs of human governance

At Orca, our view is that the assurances provided by blockchain unlocks a new paradigm of trustware technology that is relatively underexplored. One that could potentially reduce the friction and operational overhead that slows down companies and creates unfavorable working environments. Traditional organizations over index on socialware precisely because they have only a smattering of trustware at their disposal whereas in the web3 world, we’re still only scratching the surface of what organizations operating on trustware look like.

Over time, we expect DAOs to transition elements of socialware into trustware and expand the code-at-the-center of their organization, but this will take time, technological advancements, trial and error, and continued mistakes and iterations.

We’re grateful to be a part of that process.