DeFi Interactions— Composition of Objects and Actions
An introduction to interactions between DeFi primitives
“A map is not the territory it represents, but, if correct, it has a similar structure to the territory, which accounts for its usefulness.” — Alfred Korzybski
Learning about the DeFi space can be fun and rewarding, but also frustrating due to the signal to noise ratio. A good way to improve fidelity is to build a useful mental map of the territory.
One such map is a list of projects organized by financial and technical categories:
There are a few things one can nitpick about this type of categorization scheme, but overall, it provides a good starting point for exploration.
Today I’d like to share an alternative map which I’ve found to be more helpful for exploring the potential interactions between DeFi projects. Let me first explain the basic setup, then we can dive into the more interesting dynamics at play.
Objects and Actions
Roughly speaking, DeFi projects either try to be a thing(object) or an action. Primitives of the first type are nouns: a token, a cat, a prediction, a basket. Those of the second type are verbs: to exchange, to borrow, etc. Object-primitives are things people want to own, and action-primitives are stuff people want to do.
To be clear, I’m not saying that object-primitives are simple static data structures. Most of them have domain specific actions. A portfolio primitive will come with a rebalance action, and a prediction primitive will need to provide some action to settleResultOfBet.
What makes action-primitives different is that they focus on functions which are applicable across a large variety of assets. They typically work directly with high-level interfaces(i.e “to borrow any ERC20 token”).
More interestingly, DeFi projects can be composed together to form higher order entities. Since we are sorting by two buckets, it follows that there are three types of composition: object-object, object-action, and action-action. Let’s go through each one:
Object-Action Composition
This is the most straightforward pairing. An example would be a decentralized exchange(DEX) and a stablecoin. At its core, a DEX is simply an exchange function that swaps two tokens. A stablecoin is a token that is pegged to the value of something else, often the US dollar. As long as a stablecoin provide a faithful implementation of the token interface, a DEX can interoperate with the stablecoin with no additional effort.
This collaboration is simple and mutually beneficial. Stablecoins allow DEXs to provide more intuitive trading pairs and improve liquidity. In return, DEXs provide the mechanisms for arbitrage and liquidation, critical processes in keeping the stablecoin, well, stable.
Object-Object Composition
Objects can be composed to create new objects. One important category of financial primitive is derivatives: an entity which derives its value from another underlying entity.
An example is SetProtocol, which can be used to model both static baskets or dynamic portfolios.
Action-Action Composition
This last combination is rarely discussed, but perhaps the most interesting. One example of an action to action composition at work is decentralized margin trading.
When you open a margin position, you are performing two actions: borrow and trade(Margin trading literally means to trade with borrowed funds). Since there are already plenty of trading and lending DeFi projects, this is a perfect scenario for putting composition to work.
Here’s some pseudo-code to drive home the point:
One example is opyn, a decentralized margin exchange built by composing the uniswap exchange and the compound lending pool.
This pairing is both elegant and practical. Lending enables margin trading, and in return, margin traders generate the majority of borrowing demand on decentralized lending platforms today.
Further Exploration
Up to this point, our map only contains projects that are exclusively objects or actions, and utilizes composition as the primary method of achieving interoperability. As always, the whole story is a bit more complicated.
Augur is a framework for building decentralized prediction markets. At its core, Augur provides an ERC20 token(an object) which represents a bet on a certain outcome. However, Augur also comes with a full implementation of exchange functionality(action). In other words, Augur bundles all the necessarily ingredients for its relayers.
It gets more interesting. Since smart contracts are open-source and interoperable, an Augur relayer can choose to use only the part they like, and alter or ignore the rest. The unbundling leads to new possibilities, and also potential conflict of interests.
As for composition, the aforementioned margin exchange projects based on existing lending pools is the exception rather than the rule. In practice, the leading margin trading platforms almost always choose to re-implement their own lending pools from scratch.
For any specific scenario, we can only speculate on the rationale behind a particular decisions. But in general, the tradeoffs between assimilation and composition involve multiple factors: technical feasibility, control, responsibility, and perhaps most importantly, incentives.
A full exploration of these topics would be its own post. For now, these examples give clues to how, in addition to approximating the landscape of today, we can make predictions on the various interactions between DeFi projects tomorrow.
