Chainlink in 2023, Monetisation Model

An explainer of the past, my idea for its future and why I'm excited for it.

These views are nothing but my own, have no bearing on what may or may not happen in the future and aren’t formed with any knowledge outside of what’s already known in the public domain.

It’s a well known point within the Chainlink community that the world of DeFi and its explosion throughout 2019 and 2020 was largely in part due to Chainlink’s mainnet launch and the security that its data feeds provided. Without them and as seen in cases throughout the years, projects would have rolled their own oracles or used less-reliable variants that would lead to significant losses for users. Chainlink solved this problem, allowing app developers to focus on doing the thing they set out to do: building apps not infrastructure.

I lead with this point as over the years its always surprised me how many smart and avid DeFi users don’t know it. The point that vast swaths of critical infrastructure within DeFi rely on Chainlink as its oracle, and how Chainlink enabled an entire ecosystem to thrive.

---

Context

The Chainlink Network is now in a significant era of its time, sustainable value capture and advancements of its protocol named Economics 2.0. It started last year with the first launch of its staking system, but now is expanding and being detailed in a significant way as per this blogpost. To explain why I’m excited for the development and rollout of Economics 2.0 initiatives, it’ll help to explain the history of node operation and the Chainlink Network’s bootstrapping phase.

There’s been many iterations of the data feeds over the years: from the first aggregator model; to the flux monitor variant and now the currently used OCR model. The technical differences aren’t important in the context of network economics, rather their payment models. Prior to OCR, the data feeds worked on a simple flat fee per response model. The first aggregator model used to be pay on request whereas the flux monitor approach paid on receipt of data.

OCR introduced a large improvement to the prior model that significantly cut down operational costs while making the payment model more intelligent and beneficial to the node operators on their given feeds. Since only one node is writing a response on-chain vs them all, it introduced two payment types: the transmitter and the observer.

The observer payment is similar to before, a flat fee that’s significantly smaller than the transmitter payment. Paid upon receipt of data if your node was one of the nodes in the network providing that data. The transmitter payment is more complicated, it would be paid based on the gas price and gas used from the transaction, with typically a larger reward on top for being the node that got selected and managed to get the transaction on-chain first. There’s more parameters around that, a node would only be paid gas up to the point of a “fair gas” threshold and receive a bonus if it came in dramatically lower than the threshold. This ensured that node operators couldn’t game the system deliberately sending transactions with a high gas price to receive more revenue but reward them for being smarter.

All of the payments to the node operators are made in LINK, including the amount spent on gas to send transactions. This results in the dynamic that every node operator across every network has to handle its native token balances (ETH, MATIC, BNB etc) and top-up nodes accordingly based on their own defined balance thresholds.

Operationally, this isn’t much of a problem once process and alerts are defined. A node operator would simply swap its LINK to the native token each time and then fan out that token to the nodes it runs on each network. Although, a risk is the management of the LINK/native pair for each network. General good practise is swapping X amount of LINK to the native asset of receipt at certain intervals to remove any upside/downside, but can prove a problem on large gas spikes or large volatility moments in which the LINK/native pair drops over the period since you’ve received rewards resulting in spending more LINK for gas than what was received prior. There’s then the other side to that coin, where you spend far less LINK to pay for the same amount of gas on the upside. Although as an outfit that pays its bills based on on-chain services provided, stability of revenue and COGS is paramount, leading to as much de-risking as possible.

In-terms of tokenomics, this dynamic resulted in the constant need for node operators to swap their LINK into the native gas asset to keep funding their nodes operation. The idea here is a simple one, the apps paying for the price feeds would exceed the amount of LINK that was being spent operating the network.

The current problem is that the existing data feeds are designed for bootstrapping and gaining significant market share, a plan that without a shadow of doubt worked. Although in terms of their economics, their usage is free resulting in a system in which apps that pull in sizable revenues all due to security provided by those feeds while not as much value is returned back in exchange.

This is why Economics 2.0 is important and why what was outlined in the recently published blog post will serve as a catalyst to a new wave of oracle economics which solves the problem of value capture and long-term adoption.

Economic Future

One of the sections of economics blog post that caused controversary was the section on “Enhancing the Chainlink Network Payment Model”; as it’s seen as a walk back on the previous whitepapers or understanding that all use of the Chainlink Network will be paid in its native token: LINK.

Throughout this section, there will be a focus on this area of the economics blog post and its other initiatives, why I see it as a huge net benefit to the network and solving some of the problems I’ve outlined around tokenomics.

First and most importantly: I do not ever see a situation where the actual payment for oracle services is done in any token outside of LINK. I can see a situation where node operators are reimbursed for gas in the native token they spent for gas, but I always see node operators receiving reward and payment for their services in LINK. It’s the token of the network after all.

Instead, the debate here isn’t what app token is used for oracle service payment, rather what tokens will be used to compensate the network proportionately for the value that it secures across every network. As the intro, without Chainlink DeFi wouldn’t be what it is today and without DeFi fees earned within blockchain apps would be significantly smaller. The exception to that rule is DEXs which can operate as their own oracles rather than rely on them, but that’s outside scope of this and has significant problems that are well documented.

This problem stems from thinking that these two payment types are the same: oracle payments and security payments. The oracle payment is the one provided to the node operator upon completion of its services, the other is a revenue share style payment that directs app fees back to service providers and stakers in exchange for app security.

Think on that point, especially when the market conditions and sentiment isn’t like it is now. If blockchain applications that are profitable and earn sizable fees in which part is then directed back to Chainlink stakers, there’s an infinite ceiling of growth that aligns with overall adoption of this industry.

You could make the argument that the protocols themselves should simply be paying more LINK for the oracle services, in-which those payments go back to the stakers and the node operators. Although, that doesn’t make practical sense and adds significant friction to each app, as mentioned in the blog post:

 This improved and low-friction payment model will ideally result in larger amounts of total user fees being paid to Chainlink service providers over time, including LINK stakers once user fee rewards for Chainlink Staking is implemented.

Apps needing to manage this themselves would add complexity in ways of needing to perform token swaps, manage LINK balances and risk the option of needing to top-up on-chain feed subscriptions which ultimately is a centralising factor to any deployed application.

If protocols implement a simple fee-sharing model, there’s no friction and no burden placed onto the developers or its DAO to keep it functioning. Fees scale as app usage scales, due to security guaranteed provided by Chainlink. Think to the future to when fees significantly increase due to increased adoption. Chainlink Network participants would not just benefit from increased market share and TVL enforcing market leading position, rather benefit directly from significant fee intake from various applications that rely directly on Chainlink for its operational security.

If implemented like this, it’d result in a treasury style system within the Chainlink Network. A treasury that receives inflows of fees in all forms of assets, assets that could be converted back to LINK or native gas assets that pay for the network’s operational costs for all participants. Significant amounts of sell pressure would be removed and significant buy pressure added, especially if there was native asset re-imbursement for node operators gas costs: app tokens would be swapped for LINK & native gas assets; node operators wouldn’t need to swap LINK back to native gas assets; treasury assets swapped to LINK for rewards.

Economics 2.0 Initiatives

This then leads onto the new initiatives: BUILD and SCALE programmes. These can be thought about similar to the section above but at different parts of an network or apps lifecycle. BUILD provides incentives back to Chainlink participants in return for security in their upcoming application and SCALE provides incentives back in return for application security in their upcoming network.

Both of these initiatives provide incentive back to Chainlink users for value to be added to what they’re building, whereas the new monetisation model provides value back to Chainlink service providers (stakers, node operators) in exchange for the security and success each application sees. Some people will be familiar with the dynamic in which throughout the L1 craze: once Chainlink was live on a new network, it brought with it DeFi and its incentives which ushered in a huge wave of usage. These initiatives are rightly designed to encourage Chainlink service providers to deploy and support any new network or application, rightly rewarding them for the massive value created by its go-live.

These are all flavours of the same concept: rewarding the most secure decentralised oracle network for the security it provides, it’s just at different parts within their lifecycles.

Threat to Dominance

One thinking point that has subsidised over the recent years was the point that Chainlink was one type of oracle and to get the most security in your application, you should use multiple oracles as then that’s a multiplier of security. Everyone knows the saying: you’re only as strong as your weakest link.

Chainlink isn’t a product, it’s a decentralised oracle network protocol. A protocol that allows you to design different types of data requests, feeds in anyway as technically possible. The amount of ways oracles can be crafted keeps growing, and will explode dramatically once CCIP (Cross Chain Interoperability Protocol), OCR on-demand and low-latency oracles are launched. These network services allow developers to utilise the most secure oracle network in ways that have never been before: bridging, production ready custom data requests and cheap near zero latency data.

There’s one salient point: if the amount of value being directed back to Chainlink significantly increases, won’t that open up room for other oracle networks to arise and do the same services for significantly cheaper?

My simple answer to that is no, because there’s no way to do it for cheaper. Chainlink Labs has some of the best researchers in the world, and its engineering calibre is second to none. I won’t rely on that trust-related point as a reason why there won’t be no competition, but in the theme of an advancement such as low-latency oracles there are near-zero ways to make a competing network for cheaper. The gas cost in that system to provide data on-chain is zero. The only price lever is market economy of node operators that keep the same amount of operational excellence but with lower costs, an economy that exists within the confines of the Chainlink Network.

Why build a new oracle protocol when there’s already a system that facilitates the vast majority of use-cases and has performed exceptionally through every black swan event?

Every alternative oracle network I see is a variation of what the Chainlink Network already does great: data feeds and VRF. You could argue that Chainlink Labs are slow to release new features, but its easy to argue the case of network security. Move fast and break things is a sure fire way to ensure that no app would use a given oracle network.

To say the use of more oracle networks to decentralise is like saying you need to use more L1s for decentralisation. Further oracle decentralisation is achieved by more participants getting involved in the Chainlink Network, akin to more validators running within Ethereum. You wouldn’t say you’re decentralising blockchains by cloning an L1, and the same is true for a decentralised oracle network.