Background
Last updated by Tim Delhaes a year agoImportance of decentralization
The present structure of the Internet provides unprecedented power to the companies (i.e. Facebook, Google, Amazon,..) that run the web as we know it. With this power, these companies define the rules, control the data of, and the access to, services that are the online equivalent of water and electricity.
In its current authoritarian structure, the Internet’s users have no voice and no vote as to how their data is stored and used. Excluding users in this manner creates dangerous information asymmetries and power imbalances. The companies that control the data have created complex structures that make it impossible for the average user to understand and impact how the Internet should function as a public good. This allows these same companies, and others like them, to dodge accountability for hoarding, rent-seeking, abusing, and mismanaging our data, contributing significantly to the social dilemma driven by profit seeking[1] .
In short, the current trend of centralization by the few is stymying coordination and eroding freedom, democracy, and economic dynamism. Increasing the degree of decentralization on different layers will counteract and possibly revert this trend.
Decentralization for the public good
With the emergence of blockchain technology and decentralized applications (dApps), it's finally possible to decentralize the data layer. dApps can put users in control of their data. dApps are built using data that is either owned and managed by the global community or is private and controlled by the user.
This “permissionless” architecture allows many products and services built on pluggable datasets and allows users to switch between dApps freely. This is creating wide-scale economic opportunity[2] as more products can compete in a fair and open market, and mechanisms are put in place to incentivize people to contribute to more significant and wider public commons. This new architecture in turn, will foster community-owned organizations, so called Distributed Autonomous Organizations (DAOs), that can be more resilient to failure than individual businesses. For this reason, it is essential to allow developers to build dApps easily - and especially DAOs - on an increasingly decentralized public infrastructure.
Web3 will be inclusive
To describe better the tectonic shift caused by blockchain technology, Gavin Wood[3] coined the term “Web3”[4] and founded the Web3 foundation. While the existing definitions are rather vague, many people agree that the evolution of the web can be defined in three stages:
Web3: Read-Write-Own[5] (since 2016)
A common unfounded expectation is that these stages will be somewhat sequential and that the technologies will simply replace each other. However, many technologies of Web1 - like the Apache Web Server[6] - are still fundamental building blocks of the web we use every day.
Web3 does and will include Web1 and Web2 technologies. Simply not all technologies can and will be decentralized for economical, technological, and practical reasons alike. In the foreseeable future, even DAOs will take advantage of the thousands of available SaaS Applications (Apps) that help them work productively. Apps and dApps will co-exist for a long time to come.
dApps need a better way of integrating
Today, every successful Web2 App has its own marketplace of integrations. Slack lists 257, Hubspot 184, and Salesforce 410. Even smaller Apps like Harvest lists dozens, and a small software company in the UK[7] has about twenty. These companies have provided their users with pre-built integration that can tailor to their specific needs. They have removed developers as their bottleneck and, at the same time, created powerful ecosystems around the software, transforming themselves into platforms[8] .
Those integrations that these Apps don’t provide themselves, are usually delivered through Zapier.
Zapier is the market leader and de-facto standard for low-/no-code integration in Web2. Zapier is an automation tool that lets you easily create workflows that involve common web apps and services. It uses a simple trigger and action for creating commands, akin to "if this happens, then do that." The system boasts over 3,000 integrations, 100,000 customers, and over 5 millions users, $150M annual revenue and a $5B valuation without VC funding beyond a small seed round in 2012. All of this despite Oracle and IBM as the past and current omnipresent gorillas in the traditional integration and middleware market.
Zapier has three main stakeholders. First, there are developers of SaaS software that create connectors (Zapier Apps). Second, these “Apps” can be connected easily with no/little code by end-users. Third, SaaS companies can then create directories of their integrations on their websites, ready for DIY setup by their customers. This way Zapier created an unparalleled ecosystem with a network effect that guarantees its market leadership. In Web2 no other system connects more apps and organizations than Zapier.
Web3 needs a Web3 Zapier.
Challenges of integrations in Web3
Allowing dApps to exchange data with other systems is not a new requirement. As a result, different projects have addressed the different needs. To better explain this, we will use a simple, real-world example:
A Moloch-based DAO wants to allow its members to submit payment requests easily using a Google Form.
Once a month, these requests should be batched and submitted as a single proposal for a vote in the DAO on Gnosis Chain.
Once the proposal has been approved, the members should receive their payments, and an email should be sent out notifying members of the payment.
(4) The DAO payment example
Technically speaking, there are two simple integrations. First, every month a process is triggered that takes a bunch of Google Form submissions (or rows in a Google Sheet) and batches them into one DAO proposal as a smart contract transaction. Second, if a proposal has been approved, data from the submission should be sent to SendGrid.
(5) Create workflow with no code in Zapier
Let’s look at the Google and SendGrid integration.
Exchanging data with Web2
How do you get off-chain data reliably on-chain? This challenge has been critical for Decentralized Finance (DeFi) to succeed: simple data, such as exchange rates, powers today’s decentralized exchanges, swaps, and many other popular DeFi dApps.
The associated challenges of bringing data reliably on-chain were coined the “Oracle Problem”: the inability to confirm the correctness of the data collected from Web2 and the chance of malfunction and deliberate tampering[9] . ChainLink was the first company to successfully address this problem at scale, driving the $LINK token in 2021 to a $10B market cap[10] , making it the most valuable utility token of infrastructure technology. While ChainLink is the clear market leader, competition such as Band Protocol, API3, and WINKlin have emerged to commoditize Oracle services.
(6) Oracles pulling off-chain data
Most of these technologies are ”Inbound Oracles'', and their focus is bringing off-chain data like exchange rates reliably into smart contracts. While ChainLink theoretically offers outbound features, there are hardly any active use cases. Furthermore, ChainLink has increased its focus on incorporating data into smart contracts through what they now label “hybrid smart contracts”.
What does this mean for our DAO example?
ChainLink can connect to a Google Sheet using an External Adaptor. This Adaptor does exist and would have to be programmed, and would only be partially reusable as source code. It would have to hard code the users’ credentials, as well as other parameters (filename, sheet, column matching), as well as the emails of all DAO members into the Adaptor settings. The same process is to be repeated for the SendGrid integration. You would create a time trigger for the first integration and an on-chain event trigger for SendGrid.
Now, since the DAO proposal creation requires gas, a ChainLink Node has to upfront that gas on the Gnosis chain and then try to recover it from you in $LINK tokens on Ethereum. An issue we cover further down in the document.
The result?
To start, the entire system would likely not be decentralized because ChainLink’s External Adaptors usually run on a single node. The setup would require a developer with solid Solidity skills and an excellent understanding of ChainLink. You also might have to run your own node. The better alternative is likely to just create your own custom software or create Zapier Apps for this purpose.
When you now think about a system where end-users of the DAO can configure everything themselves, you will have to add a secure and secret credential storage and some way of storing metadata of integration settings and email addresses of the DAO members that submitted forms.
This example makes it very clear that oracles have succeeded in allowing smart contracts to incorporate off-chain data like sports results or exchange rates. However, they do not provide any actual outbound capabilities, credential management metadata storage, or the ability to do smart contract transactions.
Exchanging data between Smart Contracts
When it comes to integrating smart contracts - not with off-chain data - but rather with data on the same chain - there is an entirely new challenge deeply anchored in general blockchain technology. All blockchains, EVM and WASM alike, suffer from an absolute lack of automation. Two smart contracts need an external party, a middleman, to exchange data.[11] Developers have to resort to building custom integrations on an ad-hoc basis. Again, this development introduces a centralized component that has to be built and maintained. This makes even sophisticated systems, such as large DAOs, prone to problems with severe financial impact[12] .
(7) Automators like Gelato are defined by simple if-then
Overcoming this “laziness” of smart contracts has been the focus of smart contract automators such as Gelato, Keepers, AutonomyNetwork, Keep3r Network, and more recently also by ChainLink’s Keepers. These systems execute smart contract transactions on behalf of the users and are today used by many significant DeFi protocols, including MakerDAO. They save developers time to build smart contract integrations on the same chain, increase security, and help to maintain a more decentralized dApps stack.
How can this be used in our example?
It can not, because it does not have any practical ability to get data from Google or send data to SendGrid, even if one were to program some kind of adaptor. And - like the Oracles - there is no way to store user credentials or meta data.
While they allow - similar to Zapier - for simple if-then statements, their triggers and actions are mostly limited to smart contracts. Their focus is security for DeFi use cases. They are simply not designed to interact with off-chain data.
Token Design, Payment Rails, and the “Whole Tokonomy”
Payments are at the origin and heart of blockchain technology, and for Web3 to succeed, ease of use is still an elusive prerequisite. This becomes evident when looking at the token design, payment rails and the “whole tokonomy” of Oracles and Automators.
Let’s go back to our example.
To automate the process, there are at least two payments to be made: (i) gas for creating the DAO proposal and (ii) the system and node for sending data between systems. In the case of ChainLinks Oracle network, the nodes are paid with $LINK tokens and data feeds are mostly subsidized and free to customers. The ChainLink nodes pay for the end-users’ gas fees and have to recover the gas fees (potentially) cross chain from their users. Gelato lets users deposit gas tokens and requires nodes to be paid in $GEL.
On top of that, while Google Sheets is a free service, SendGrid is not. And because SendGrid does not accept token payments, this service is not available to DAOs directly. When looking at the “Whole Tokonomy” the creation of services is needed to wrap the existing fiat-paid SaaS services and make them available to the Web3 ecosystem. Neither Oracles nor Automators have this truly built in. A system that provides incentives to develop new Apps adaptors would likely create a significant network effect.
(8) ChainLink Tokenonics are broken
No matter what, right now, the customer experience is terrible. It is like having to pay for your cup of tea with a mix of US Dollars, Japanese Yen, and Malawian Kwacha. It’s a customer experience that is doomed for failure.
Conclusions
On-, off- and cross-chain integrations and payments are - evidently - not trivial.
When it comes to smart contract integrations, Automators do the job. However, they can’t interact with off-chain data.
The tokenomics created by Oracles and Automators are complicated for all stakeholders and incentive distribution is suboptimal.
None of the existing systems provide a universal, or even a Zapier-like solution. This would require the combination of Automators and Oracles, leading to even more technical complexity as well as tokenomics disaster.
Web3 needs a universal, composable system that can seamlessly connect on-, off- and cross-chain systems to allow dApps to empower their users to create their own integrations. These interoperable dApps will spawn new ecosystems and provide end-users with an ease of use that has been missing so far in the Web3 ecosystem.
