Yada, yada, yada

YADA: Yet Another DeFi Application


In the summer of 1994, a simple fact about the World Wide Web blew my mind.

You see, the web has this idea of a “webpage”, a term in which the “page” is skeumorphically misleading. The word “page” makes one believe that the content of a webpage should look like pages in the real world, like a magazine, or a newspaper. And this concept of a page was reinforced by HTML, the language used to render these pages: not only did webpages look and feel like a pages in real life, even the back-end was very page-like. In 1994, almost every webpage was static. Yahoo was static. So were IMDB and Wired magazine. The famous “dynamic” websites of the 1990s, where you engaged in transactions (like Amazon and Ebay), didn’t exist yet.

When playing with my own web server one day, I was experimenting with something called the Common Gateway Interface (or CGI). CGI is designed to allow certain types of programs to run in the background on a web server. On a lark, I put a C executable (a.out) at the back end of the web server, and it ran! What blew my mind that day was the realization that the content of a webpage could be generated from anything that can be computed. Your web server can run any code, and the output of the code could be rendered (as HTML) on someone’s browser.

So a webpage wasn’t really like a page in real life at all. You could run any computation, search any database, engage in any transaction, and as long as the output was HTML, it would work. Based on this, dynamic websites like Amazon could allow you to buy something and show you the output as a webpage, and Fedex could let you search their database for a tracking number and show you the result as a webpage.

So this was my mind-blowing realization: A webpage isn’t just HTML that is sent by a web server and rendered by a browser far away. A webpage is a Turing-complete, blank canvas that can be accessed by anyone on the network.


Fast forward to 2009. I was running my AI startup, happily working with images and video, when a friend sent me the Nakamoto paper describing bitcoin. I was fascinated with the idea of a peer-to-peer network for trustless transactions. After an abortive attempt at mining using my home computer, I went out and bought some bitcoin (from a shady guy in Queens, NY — but that’s a story for another day).

Since then, the world of blockchain has evolved. We have several dozen blockchain ecosystems with smart contracts. Each of these ecosystems has a native token, which is ownable and fungible, so behaves like a cryptocurrency. And each ecosystem has developed tools to allow investors in their tokens to maximize returns: there are decentralized exchanges, bridges, lending and borrowing sites, among many, many other Decentralized Finance (DeFi) apps.

Whenever one mentions a blockchain network, the first point of salience is their native token. “Have you seen that SOL? It’s on a tear lately!” “The ALGO token is about to take off!” “That TEZOS treasury is massive!” Even DeFi apps have their own tokens, with their own stories. “I think SUSHI is a good value for money nowadays.” “Whatever happened to CFG?”

Because there is a native token in each project, and the founding team keeps some (or a large) amount of these tokens for themselves, each team is strongly incentivised to promote their own project or ecosystem. They are all competing for investors, and for developers who can build DeFi apps to attract more investors.

Ultimately, these ecosystems are all competing with one another. They are competing for more investors, which depends on more users, which depends on more usage, which depends on more DeFi apps. All DeFi apps have the same ultimate goal: to allow investors to generate more returns, by fractionalizing their tokens, by staking, by lending, by borrowing, by leveraging. And the competition between ecosystems is fierce: they compete on speed and scalability (“our network can do a million transactions per second!”), on low fees (“our fees are so low that we give you money back!“), on funkiness of consensus mechanisms (“proof of history”, “pure proof of stake”, “partial proof of differential historical behavior”). I was once on a call with a blockchain network founder who said, in all seriousness, that his consensus mechanism was the most important thing to happen in computer science since the Nakamoto bitcoin paper. In his defence, he does own a lot of his own tokens.


Every blockchain network has a DeFi ecosystem sitting on top of it, allowing investors to generate good returns, and allowing founders and early investors to generate giant fortunes.

But all of this focus on DeFi has obscured the really important analogy of these tokens to webpages: that ultimately, a blockchain token is a Turing-complete, blank canvas that can be OWNED by anyone on the network. And this ownership can be established without any trusted third parties.

Let me restate that in another way: You can own anything that can be computed.

Anything. That. Can. Be. Computed.

But we’re barely scratching the surface of ownership. Today (March 2022), you can own fungible tokens (cryptocurrencies and such), or you can own non-fungible tokens (NFTs). But the world of NFTs is very shallow: the majority of them are digital objects that look (and behave) like objects that we already own in the real world. You can own digital art, or digital music, or some other skeumorphic objects in the metaverse.

When you looked at webpages in 1994, you could imagine the services where computation was simple: you could imagine that NY Times would publish their content, or you could imagine that FedEx would let you search their database. But you couldn’t imagine what more complex computations could generate on the webpage; you couldn’t imagine services like Facebook or Uber.

In March 2022, we find it difficult to imagine what can be owned. Because we have an ownership network, we think that the people who have historically created stuff, the “makers”, will do a lot better. Maybe they will, but I think it is reasonable to also expect a new class of things that get created that can only be computed, or can be represented by a computation.

I don’t know what that looks like. But I can hardly wait.


In the 1990s, on the TV sitcom Seinfeld, there was a character who used to say “Yada yada yada” to describe things that she didn’t want to talk about; things that she wanted to skip.

My vote: let’s leave DeFi to the traders. As technical people, we should bering our focus back to the blockchain, and back to ownership. Time to do something bigger, bolder. Like Seinfeld, DeFi apps are so Yada yada yada.

YOU get a token, YOU get a token…

Each layer 1 (L1) blockchain presents an ecosystem, which is available for us to use as a substrate to build our projects. In that sense, each blockchain network (such as Ethereum or Solana) is like a programming language, which offers a bunch of features (such as functional programming primitives, or recursion). And it’s up to a developer who is building a project to decide which ecosystem to pick for their application.

This analogy to programming languages becomes more interesting when you factor in the fact that each L1 ecosystem is potentially a lot “richer” than a programming language: other than offering you features, it also comes with it’s own token or currency, and the value of the currency represents the value of the ecosystem in the eyes of its users. (It also comes with a built-in runtime environment and a shared database capturing a “state of the world” that everyone agrees upon.)

Imagine that in the year 2000, if the dominant programming languages of that time acted in this way. They would all have their own native tokens. There would be Fortran, with its coin (FORT). It was the OG coin: it had been around for a long time, but wasn’t being used all that much anymore. It’s value was way low, but there were a bunch of old-timey developers who were HODLing FORT because they were sure it was going to come back. Then there was Cobol, with its coin (BOL). The ecosystem was cumbersome to use, but BOL had a massive treasury which was largely being held by banks and other financial institutions, where Cobol was in heavy use. And then there was java, and java’s currency (JCOIN) was valued the highest, because it was the dominant ecosystem of the time, and most of the software development community expected it to perform the best in the future. To take the analogy one step further, java (and the other languages) would be offering their native currency to the developers of important projects who chose java: “Pick java for your web socket development, and get some JCOIN!” And then the web socket developers could launch their own coin in that ecosystem. And then they would offer their own coins to the people who used those projects. “Are you using our web socket software? Great! We will airdrop you some SOCKCOIN!”

Everybody gets a coin!!

Layers of network effects

These kinds of incentives create interesting confluences of network effects:

  • Supercycles for investors. People keep buying JCOIN because they see developers flocking to java, and they think other people will buy JCOIN, thereby inflating the price of JCOIN even more.
  • Supernetwork effects for developers. You keep using java even though it’s clear that java is a perverse, repugnant language that’s not right for your project, because JCOIN price is going up, and you’re earning more of it all the time. The competitor (python) is an elegant language, with a great syntax and rich libraries, but the price of PYCOIN is very low, it’s not clear where it’s going. So you stick to java as your ecosystem, thereby continuing to drive up the price of JCOIN.
Token rewards create ever growing incentives.

But this also creates increased volatility for ecosystem choices:

  • False greener pastures. You’re happy with your choice of python ecosystem for your project, but PYCOIN isn’t doing too well, and you don’t want to miss the rising tide of JCOIN, even though you know it’s the wrong ecosystem choice for your project.
  • Market coupling. Something (non-programmatic, maybe market driven) causes the price of JCOIN to crash, and now you want to switch your entire project to another ecosystem because you want to ride the wave of some other ecosystem coin. Or maybe you still don’t want to switch ecosystems because you want to catch THIS bull run of JCOIN as it recovers.

What do we do?

We want to build a new project (say, a file server), and need to choose an ecosystem.

Approach 1: Make projects portable

Projects should be able to switch ecosystems with minimal effort. To do this, several things must be true:

  • As much as possible, the ecosystem layer must be abstracted away from the core project functionality.
  • There needs to be a middleware that allows a project to switch between different ecosystems.

This also prepares us for approach 2…

Approach 2: Make projects inherently multi-platform

Our file server is available on multiple platforms: you (the user) can deploy our file server on java (and earn JCOIN or our FileServerJCOIN), or you can deploy our file server on python (and earn PYCOIN or PythonFileServerCoin).

Of course, this is easier said than done. Java is an object oriented language, where every primitive is a factory, and compiles to a bytecode that runs on a jvm, whereas python is an interpreted language which need not be object oriented, support functional concepts and is not compiled at all. It will not be easy (or sometimes even possible) to make multi-platform versions of projects.


For either approach mentioned above, the project team must have developers who are familiar with multiple ecosystems, their pluses and minuses, and be able to guide transitions.