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 benefitting 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.
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.
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 reimplement 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.
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:
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.
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:
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.
Are you a developer interested in developing on Radix? We'd love to let you know when early beta releases are ready, and keep you informed of our progression. If that sounds good to you, please sign up here: Dev Sign Up