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 Blueprint Catalog. The Catalog offers off-the-shelf 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.

With the Radix Engine v2, builders can create virtually unlimited DeFi dApp functionality as "Components" – Radix's unique form of smart contracts, written in a custom programming language called Scrypto. But if all Components must be built from scratch, we lack the useful standards and off-the-shelf functionality that an excellent development platform needs. We need a way to allow developers to access common functionality easily, and allow other developers to build and share useful and commonly-desired functionality.

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 dapp 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 Blueprint Catalog.

How the Radix Blueprint 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. Blueprints provide a powerful alternative.  Blueprints, like Components, are written in Scrypto. But instead of describing a specific piece of "smart contract" functionality directly, it describes a sort of template that can be used as the basis for many similar Components, when configured with some parameters.

When a Blueprint's Scrypto code is deployed to the network by the developer, it is added automatically to an on-ledger registry called the Blueprint Catalog. Blueprints in the Catalog are available for anyone to create multiple active Components patterned after that Blueprint. To use a Blueprint from the Catalog, a developer instantiates it, generating a new "Instantiated" Component from the Blueprint's template. This Component has its own unique identity on the Radix network, and its Actions become available for use by users (or other Components).

Blueprints start life as Scrypto code that is deployed into the Blueprint Catalog on the Radix Network itself, where they can be easily configured and instantiated into new Components – or imported into other Blueprints.

Instantiation is simple, done via API, and requires no Scrypto code. Most Blueprints will include configuration parameters allowing customization of the instantiated Component. For example, a “Token Definition” Blueprint would let anyone instantiate their own unique Token Definition (a supply of real tokens that users can interact with) 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 Blueprints is to import them. A developer may want to make use of the functionality of an existing Blueprint – but add to it or customize what it can do. This is done by creating a new Blueprint that includes an import command for the Blueprint that provides the functionality desired for inclusion. Any additional custom functionality to be layered on top is then implemented in the developer’s own Scrypto code.

It should be noted that neither instantiating nor importing are copying the Scrypto code of the original Blueprint; it is an on-ledger link to the original Blueprint (and its version). An example of this (shown above) of importing might be a Price Oracle Blueprint 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 Blueprint, import the original Price Oracle Blueprint by reference to its ID in the Catalog, and add the additional Scrypto code for the price average calculation.

Both Blueprints and Instantiated Components have their own unique ID, and are associated with a creator’s developer ID. Blueprints and Components are versioned, with each new deployed update requiring a revision bump. Updating a Blueprint does not automatically force an update onto other Components or Blueprints referencing 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 Blueprints

The Radix Foundation is committed to filling the Catalog with useful Blueprints 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 Blueprints 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 Blueprints, developers can skip reimplementing common functionality themselves, accelerating development time or reducing it to zero for very simple things like issuing a token. Blueprints created by third parties can also become standardized features of the Radix network in exactly the same way.

Whoever creates them, on-ledger Blueprints create natural composability and interoperability for the DeFi ecosystem.Foundation-provided Blueprints aren’t the end of the story. The Radix Developer Royalties system provides protocol-level incentives for anyone to contribute Blueprints or Components – large or small – that can become “standards” of the platform.To learn more about how Radix technology solves the problems holding back DeFi at every level, head over to our DeFi Whitepaper.