Home » Sector Topics » Financial Services AI

DeFi platforms: What dumb data and dumb code have in common

  • Alan Morrison 
Programmer hacker robot AI computer cybersecurity cyber crime ha

Quite a few decentralized autonomous organizations (DAOs) have crashed and burned since 2015 when Ethereum was launched and “smart” contracts (self-executing agreements in code devised by crypto lawyers) were born. If you’d like a detailed look at the largest DAO crash and burn to date, take a look at Laura Shin’s February 22 piece in Forbes on the $11 billion DAO heist in 2016 by what seems to have been an Austrian programmer and ex-crypto CEO.

More than five years later, DAOs still tend to be vulnerable to attack because smart contracts and the system surrounding blockchains aren’t as smart as they need to be. The root cause of dumb contracts, as well as dumb data, is poor organizational design, system design, strategy, refinement, and a lack of due diligence. 

In other words, there’s plenty of blame to go around. Many of those responsible were in too much of a hurry or too short-sighted to build workable platforms and apply the right level of automation in the right way. More on this later.

Autonomy and risk in 2022’s DeFi self-executing contracts

From a risk perspective, far too many decentralized finance (DeFi) startups are trying to run before they can walk, or even crawl. Build.Finance, based on a DAO like many DeFi startups are, is the most recent (February 2022) example. Build.Finance devised a DAO (a bundle of self-executing rules or “smart” contracts designed with a “decentralized ledger” to interoperate without intermediaries) to encourage new projects by rewarding builders with Build tokens. As builders started to use the tokens, demand for the tokens would grow.

Crypto-word-cloud-free

Tim Copeland, a News Editor at The Block, described what happened to Build.Finance’s venture funding DAO. I’ve distilled the step-by-step description he gave:

  1. Culprit asked the DAO collective to be able to mint tokens unilaterally. 
  2. Moderator advised the collective to vote against doing so. Proposal failed.
  3. Culprit asked a second time using a second wallet, and got past a bot intended to handle proposals.
  4. Proposal passed.
  5. Culprit minted 1.1 million Build tokens, then:
    • Emptied the liquidity assets controlled by smart contracts at two decentralized exchanges–Balancer and Uniswap.
    • Took 130,000 METRIC tokens from Build’s treasury and sold them.
    • Minted another 1 billion Build tokens.
    • Transferred funds to Tornado Cash and used the mixing service to change the public keys of the tokens as a privacy measure.
  6. Resulting Ether amounted to $470,000 in funds the culprit absconded with.

It’s unfortunate that a whole generation of DeFi startups has been launched just recently using what still seems to be an inherently flawed architecture and governance framework. DAOs or at least quasi-DAOs could be successful during this decade if the startup community went back to first principles and started from scratch in a sufficiently informed and methodical way. (By first principles, I mean the data-centric architecture principles that Dave McComb has articulated in books such as Software Wasteland, as well as in many talks available on YouTube.)

But instead, it looks like we’ll be in the Gartner Hype Cycle’s Trough of Disillusionment phase soon, and that phase could be a lengthy one, considering that regulatory agencies such as the US Securities and Exchange Commission (SEC) seem poised to weigh in before things get any more ugly than they already are.

How do you crawl and walk before running with “smart” contracts?

In 2015, I plotted the types of smart contracts that could be written and implemented along a continuum. On the left end of the continuum are the simplest smart contracts. On the right end are the DAOs, Decentralized Autonomous Governments (DAGs), and the Decentralized Autonomous Societies (DASes) that the idealists in the blockchain/”web3” community yearn for.

DeFi platforms: What dumb data and dumb code have in common

Back then, there was quite a bit of activity around simple smart contracts. Car rental agencies, for example, built prototypes to allow renters to jump in a car of their choice, sign a contract online and drive away. Or as in the diagram above, a property owner’s smart contract could remotely lock a non-paying tenant out of an apartment autonomously. 

Many simpler use cases abound, and simpler smart contracts are now commonplace. This doesn’t necessarily imply that it’s simple to scale the governance of smart contract-based platforms.

A few less well-known“digital” governance shortfalls

What’s exasperating to those who’ve toiled for decades to improve information automation and systems interoperation is that “smart” contract designers overlooked or soft-pedaled the importance of advances that have been made. Designers could have harnessed these advances, and in the process, sidestepped or at least moderated the impact of the trial and error of a string of failures that now seems inevitable.

In 2018, I was giving a talk on the blockchain, smart contracts, etc. to a tech-savvy audience of IIT MBA alums, and during the Q&A, several of the more technical folks were mystified by why smart contracts seemed to be just another way to encode rules and one that seemed to be rather atavistic as well.

The smart contract writer’s philosophy then was to write a “smart” contract in code that a judge could read so that the agreement would be both machine and judge-readable. Not many judges know how to code. So lawyers with some coding background were crafting the smart contracts.

But lawyers likely weren’t versed in the latest coding and certainly not semantics tech advances. What’s happened is that the resulting code has been not only kludgy, it isn’t very smart. And the computer science grads coming out of college and eager to work in the crypto field haven’t been habitually trained in technologies that would help to build intelligence-rich computing environments. Nor do most of them feel the need.

Which is a sad state of affairs, given that the effectiveness of “smart” contracts hinges on entities and relationships being logically consistent and comparable to one another–a foundational requirement in intelligent systems. Otherwise, contracts can’t be interoperable. Lawyers have done disambiguation and abstraction in human language for humans, but not so much for machines.

How does all this relate to dumb data?

Rather than blending and harnessing the best available techniques, smart contracts and the intermediaries that use them as they currently stand seem to be a step backward, rather than forwards. The anecdotal evidence regarding smart contracts in a DAO context hasn’t seemed to improve since TNO’s extensive report on smart contract vulnerabilities was published back in 2018.

What’s missing from DAOs otherwise? Context, such as the context necessary to adequately assess risk and seek remedy after catastrophes like the one that Build.Finance and its users experienced. 

Machines don’t build context on their own. Humans have to be in the loop so machines can continually learn from them. And system designers need to harness the power of semantic graphs to weave contexts together. Otherwise, context that’s just siloed and underdescribed can’t be discovered or evolved and refined.

Financial institutions and regulators both yearn for more transparency. And decentralized ledgers do offer more visibility–of the transactions themselves. But, as Emeka Okoya points out, blockchain records are only as good as the input data. Blockchains store errors just as easily as they do clean transactions, and malicious behavior thrives in an identity impoverished and opaque world. 

Know Your Customer (KYC) policies for large traditional banks are designed to enhance compliance with anti-money laundering (AML) regulations. Some of the larger banks spend as much as $1 billion annually on AML compliance. 

In the current DeFi environment, the default seems to be the opposite of KYC–Camouflage Your Customer. Obfuscation is the rule, the direct opposite of intelligence, the enemy of compliance and customer trust. 

The term “trustless” has been used in reference to blockchains since the 2010s. It’s a confusing use of the term that tries to describe a means of full automation without the need for humans in the loop.

But what we’ve discovered since 2015 is that humans have got to be in the loop–quite a bit. Blockchains were supposed to dispense with intermediaries. In 2022, the market is chock full of intermediaries. And there’s no way to know which intermediaries are trustworthy and which are not. 

What’s the alternative to a “trustless” architecture that seems to myopically harness only 1980s-style logic and 2000s-era storage? Data that’s designed to be smart. Logic that describes and models the business and the process that’s smarter because it lives evolves and interacts with instance data, as semantic graph model data. Model-driven development, data federation, and the duplication elimination that results are the updated approaches that should be used in “web3”.

An intelligent web that builds on what we’ve done right and extends it, in other words. Not just a transactional and self-executing agreement environment.

Intelligence depends on logical, dynamic connections. Scaling, in turn, depends on consistently shared intelligence and shared resources. 

DeFi startups live in an ecosystem that needs considerable enrichment in order to thrive, a well-conceived, fleshed out, and designed marketplace instead of cryptic means of transaction, agreement and exchange. DAO architecture needs to factor in data-centric architecture and embrace the creation of web semantics and decentralized identity alongside the ledgers and cryptography that are still a focus of obsession with what the public at large knows of “web3.”