On-ledger, Recurring Developer Revenue. Incentives to Buidl.

Radix Pioneers self-sustaining, on-ledger distribution of Developer Revenue via Component Marketplace

The world runs on open source code. Collectively, that code represents one of humanity’s greatest accomplishments — a way in which we have self organised and done incredible feats of engineering together.

However, there has often been a conflict between contributing to open source and benefiting from the use of that open source code — especially if you are an individual developer coming up with a great idea for a library or snippet, but not wanting to build an entire commercial application.

With the birth of Radix, we saw that there was now a new path — one where the individual developer, as well as the dApp builder and company, can be incentivised to contribute to an ecosystem, but in a way that is market and community driven. One where versioning and payment is baked into the very fabric of how you can build and operate on ledger, while preserving transparency and the spirit of open source.

We are therefore pleased to announce a major feature of the Radix network — the Developer Royalties System. This unique system creates a new decentralised, on-ledger way for developers to generate on-going revenue for their contributions to the Radix ecosystem, while also accelerating the ability for others to build on top of this core functionality.

In this article, we are going to explain how the Radix developer royalty system works, what Radix “Components” are, and why they will be a revolution in building secure decentralised applications quickly and efficiently.

Why Self-incentivisation is Critical

One of the key innovations of blockchain technology was creating a way that a network could be self-incentivizing. For example, crypto currency mining created a permissionless marketplace for providing computing power to a network without centralised coordination. — . Feedback loops like these are incredibly powerful for growth, because once started they develop an independent life of their own

With the Radix developer royalties system, we are aiming to create a decentralised, self-incentivized system for DeFi code development as a core part of the Radix network. Royalty payments are set by developers, paid automatically on-ledger, and are designed to benefit from similar network effects as Mining.

Combining our self-incentivizing network with our self-incentivizing developer ecosystem, Radix is focusing on the key drivers of growth for decentralised platforms and the creation of the applications that drive their adoption.

Through these systems Radix is creating additional opportunities for both the first developers who contribute to the network, as well as providing longer-term incentives as the system grows in complexity and scope.

Unlike with a traditional development fund or allocation which is finite and decreases over time, the Radix developer royalties provide on-going revenue that grows with the ecosystem and is baked into the decentralised network protocol itself.

Radix Components and the Component Catalog

Components are Radix’s replacement of smart contracts and they make the Radix Royalties system possible.

Like typical smart contracts, Components allow a developer to build powerful logic that is deployed and run trustlessly on the network, but there are important differences. Rather than being built as a “black box” of code, Components are built using finite state machine (FSM) logic, in a language we call Scrypto, where their behaviour is defined by Actions that directly translate a discrete existing “input” (or “before”) state to an “output” (or “after”) state. More concretely, this means that components are defined by what it is possible for that component to do via its Actions. By defining components by their Actions in this way, components can behave more intuitively like physical assets or other finance building-block “primitives”.

We will be releasing more details in the near future about the details of components and the many benefits that we believe they offer over a traditional smart contract. But for now, to understand how the Royalties system works, there are a few key Component concepts to understand.

First, rather than being deployed to the network and immediately becoming active for use, components are first deployed as a kind of template to an on-ledger repository we call the Component Catalog. Components in the catalog can be instantiated (by simple API call) many times, each time configured for the user’s specific needs, into active Instantiated Components that users (and other instantiated components) can interact with. And within the Catalog, existing template components can be imported so that new code can be layered on top of existing, proven functionality without having to copy or re-implement it.

Second, components are inherently modular, able to be developed individually and then combined together in various ways. We’ve seen how importing within the Catalog provides one form of modularity. But they may also be modularly combined within each transaction by “referred” use, providing the basis for frictionless composability of DeFi applications on Radix.

For example, actions on multiple token components — such as “send”, “mint”, and “burn” — can be accessed within a single transaction to perform atomic swaps. Or a transaction using a DeFi application component may itself in turn make referred use of multiple actions of other components (including tokens and more complex ones). In these cases, all of the included components in the transaction mesh together like gears in a gearbox; as long as they can all successfully agree on what should happen, the full transaction is successful in one step. If they can’t, the transaction safely and correctly fails.

Adding in Royalties, Allowing Developers to Generate Income

When a developer creates or instantiates a Component on the Radix network, they are able to set a royalty fee that is due any time their component is used. Royalty fees are paid as a part of each transaction in exactly the same way as node-runner fees. This payment (and the Component itself) is on-ledger and as a result, Radix connects the royalty definition (set by the developer) to the royalty distribution (facilitated by the Radix protocol) and therefore creates an open marketplace for developers to generate an income from their contributions.

In this marketplace, royalty payments on a per-transaction-use basis are automatic and guaranteed by the same consensus mechanisms that guarantee Radix network security.

As Components can be used in a number of different ways, Radix provides developers with the tools to participate in this on-ledger marketplace however they see fit. This starts by allowing the developer to set the royalty for each of the different ways a Component can be used once it has been added to the Component Catalog. These possible uses are:

1. DIRECT INSTANCE USE — This is when a user transaction directly accesses an Action of an instantiated Component. For example, this might be the interface to a DeFi application like a CFMM, even if this Component uses other Components “behind the scenes”.
2. REFERRED INSTANCE USE — When a Component is used directly, as in #1, it may specify that multiple other instantiated Components must be included in the Action for the transaction. This is “referred” instance use. For example, a DeFi application might use an instantiated oracle Component to get access to its data by reference for a certain transaction.
3. CATALOG USE — Each instantiated Component is associated with an original Component in the Catalog; this refers to that form of usage of that original. Remember that a developer does not pay for instantiation, but rather when an instantiated Component is used (as in #1 and #2), the original Catalog Component behind it is also being used in this way.
4. IMPORTED USE — This refers to the usage when a developer “imports” an existing Catalog Component into his own new Catalog Component. As in #3, the importing itself is not paid, but rather the imported Component is considered used when the instantiated new Component is used in a transaction.

By setting the royalty fee for each use type, Radix empowers developers to engage in the marketplace how they see fit. Each time their component is used in a transaction, they will receive their royalty payment as per the rates they set.

In a single transaction, there may be multiple components used in multiple ways. Below is an example of how a single transaction could call multiple Components in different ways. It also demonstrates how initial “basic” components act as “lego-blocks” that can be combined together to enable more complex transactions/applications. More on that in a future post though.

Supercharging Radix Ecosystem Development

Building a full DeFi ecosystem on Radix as quickly and effectively as possible is critical for the network to grow. We believe the combination of the Component Catalog and Royalty payments being decentralised and on-ledger will maximise the growth opportunity for three main reasons:

1. Components themselves can range in complexity and are not required to be fully functioning applications. As a result, initial community development can be focused on creating components that have broad use across a range of applications on the Radix network. For Component developers, this allows them to focus on building specific functionality, without the need for building whole products and front-end applications.
2. Having a on-ledger Component Catalog allows application developers to leverage a wide range of functionality which allows them to develop secure applications quickly, while still maintaining composability and standardisation in some of their functionality. By creating more applications, the network also generates more transactions on each of the components being used.
3. As the Component developer can set a royalty rate for a range of uses of their Component each time they are used in a transaction, the Component marketplace encourages developers to build functionality that will be in-demand and, in doing so, generate income for their efforts. A developer could choose to work on making a standardised “simple” component that has a wide range of uses and offer it at a very low royalty fee, or they could create a highly specialised but valuable Component that won’t have a high volume of use, but which they could charge a higher royalty fee for.

More on the Radix Engine, Components, and Developer Royalties

This announcement is just the tip of the iceberg on what we have planned for development on Radix. In the next few days, we will be releasing a DeFi Whitelitepaper including more details on the Radix Engine, as well as further details on how these systems will benefit the Radix network.

There are also other initiatives that we will be bringing in to help incentivise the growth of the ecosystem, such as additional subsidies for the royalties in the early stages, development-focused challenges in our Radvocates program, and more.