Build DeFi dApps Faster on Radix
In a previous post, we described how Radix provides a new, purpose-built development environment for builders of decentralized finance applications – the Radix Engine. Building on that foundation, Radix has designed the Component Catalog. The Catalog offers low-code access to common asset issuance and financial primitives, and a decentralized on-ledger hub for developers to create, share, extend, and combine modular tools to accelerate dApp builds. Together these tools make Radix the most buildable and interoperable platform for DeFi.
The Power of an On-ledger Developer’s Hub
A truly useful development platform includes libraries, frameworks, and other tools that allow developers to build simple, common things quickly with a minimum learning curve. These same tools also accelerate more complex builds by providing reliable, pre-built solutions for parts of the problem that other developers have encountered and solved well already. Having good standards and off-the-shelf solutions also strongly encourages interoperability between dApps that is particularly important for a DeFi ecosystem.
In DeFi, common chunks of finance-oriented functionality recur across many applications: assets (fungible or unique), shares, accounts, multi-party control, liquidity pools, swaps, purchases, and data oracles just to list a few examples. These are prime candidates for pieces of functionality that developers would like to see pre-existing, proven, well-maintained solutions.
Traditional open source methods and community collaboration are certainly good places to start to encourage these builds. Package managers often assist in the process of discovering and using pre-existing tools. But the Radix Engine gives us an exciting new possibility: putting community collaboration and package manager-like functionality directly on-ledger.
An on-ledger mechanism for Components to be modularly used, leveraged, updated, versioned, extended, and combined is a powerful tool for developers. Components deployed on-ledger in this way don’t just contribute to the developer ecosystem; they directly extend the effective functionality of the Radix platform.
A developer need not build a fully-functional standalone dAapp Component to usefully contribute. Components that do one thing very well, and are built to be easily reused or combined with other Components, can become standards of the platform that accelerate builds and encourage interoperability for everyone.
The idea of “writing programs to do one thing well” and “writing programs to work together” was the guiding philosophy of the creators of UNIX in the 1970s. The result created the foundation of open source development and the spectacularly successful family tree of UNIX-based operating systems and applications since then. We believe that rebuilding the financial systems of the world around a decentralized platform suggests a similar philosophy, maximizing interoperability, modularity, and potential for anyone to make meaningful contributions both large and small.
We have integrated this philosophy deeply into the way Components are deployed and used on Radix with a platform feature we call the Component Catalog.
How the Radix Component Catalog Works
With typical smart contract DLTs, a developer writes some code (Solidity in the case of Ethereum) and then pushes it to the network where it becomes an active smart contract for users of the network to interact with. The Component Catalog changes this model.
When a Component’s Scrypto code is pushed to the network, it is first added automatically to an on-ledger registry called the Component Catalog. Components in the Catalog are like inactive templates or blueprints that anyone may use to create multiple active Components patterned after the original in the Catalog.
To make a Component from the Catalog active for use, a developer instantiates it, creating his own Instantiated Component from the blueprint template. An Instantiated Component has its own unique identity on the Radix network, and its Actions become available for use by users (or other Components, as we saw previously). This means that one Component in the Catalog can be used an unlimited number of times as the template for instantiated Components that all behave in the same basic way.
New Components start life as Scrypto code that is deployed into the Component Catalog on the Radix Network itself, where they can be easily configured and instantiated – or imported into other new Components.
Instantiation is simple, done via API, and requires no Scrypto code. Most Components in the catalog will include configuration parameters allowing customization of the instantiated Component. For example, the “Token Definition” Component described earlier would let anyone instantiate their own Token Definition with its own unique name, symbol, maximum supply, etc. – and then begin minting their own tokens.
By instantiating Components from a universal on-ledger Catalog in this way, Radix makes it very quick, easy, and safe for any developer to issue assets and access other simple functionality created by others, without having to learn and write Scrypto code.
Another way of making use of Components in the Catalog is to import them. A developer may want to make use of the functionality of an existing Component in the Catalog – but add to it or customize what it can do. This is done by creating a new Component that includes an import command for the Component that provides the core functionality desired. The additional functionality is then implemented in the developer’s own Scrypto code.
Importing is not copying the Scrypto code of the original component; it is an on-ledger link to the original Component (and its version). An example of this (shown above) might be a Price Oracle component that a developer wishes to customize by adding a calculation of a moving price average (and Action to access it). The developer could create their own Special Price Oracle Component, import the original Price Oracle Component by reference to its ID in the Catalog, and add the additional Scrypto code for the price average calculation.
Both Catalog Components and Instantiated Components have their own unique Component ID, and are associated with the creator’s own unique developer ID. Components are versioned, with each new deployed update requiring a revision bump. Updating a Component does not automatically force an update onto other Components making use of it; previous revisions remain immutably available on ledger and existing Components will continue to have access to the previous revision. A developer may choose to adopt a new revision by making their own update to the Component that uses it.
Standard Platform Components
The Radix Foundation is committed to filling the Catalog with useful Components that model common elements and behaviors of DeFi as standard features of the platform. This includes things like assets (fungible or non-fungible tokens) and accounts (including multi-sig control) and will expand to include functions desired by the community that could include higher-level DeFi primitives like liquidity pools, swapping systems, purchasable assets, data oracles, and more. Each of the standard Catalog Components developed by the Radix Foundation can be instantiated as-is (for example creating a supply of custom tokens via API call) or, as we saw above, they can be modularly combined in various ways to create more complex functionality.
Using these standard Catalog Components, developers can skip reimplementing common functionality themselves, accelerating development time or reducing it to zero for very simple things like issuing a token. Catalog Components created by third parties can also become standardized features of the Radix network in exactly the same way. Whoever creates them, on-ledger Catalog Components create natural composability and interoperability for the DeFi ecosystem.
Foundation-provided Components aren’t the end of the story. The Radix Developer Royalties system provides protocol-level incentives for anyone to contribute Components – large or small – that can become “standards” of the platform.