The Radix Blueprint Catalog 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 Blueprint Catalog changes this model. When Scrypto code is deployed to the network, it starts its life as a Blueprint that is added to an on-network registry called the Blueprint Catalog. As described earlier, to instantiate a Blueprint from the Catalog into an active Component for use, a developer calls a function defined in the Blueprint that brings a new Component (or multiple Components and/or resources) into existence, often using specified parameters to customize that instance. Multiple Components can be instantiated from a single Blueprint in this way. By instantiating Components from a universal on-network Catalog, Radix makes it very quick, easy, and safe

Rather than just importing some code that seems 20 useful, a developer can see that a given Blueprint has actually been instantiated by others and see how the corresponding Components are working. A developer may even not need to learn any Scrypto to access some simple pieces of functionality. Weve already seen how tokens can be created simply by requesting a customized resource from the platform, which can be done even within a transaction without Scrypto code. Similarly, Blueprints may be customized and instantiated

Another way of making use of Blueprints in the Catalog is to instantiate them programmatically from other Blueprints or Components to modularly construct a dApps functionality. For example, Bob might create a Lender dApp Blueprint that requires use of a custom CFMM (constant function market maker DEX) to swap between assets the Lender dApp supports. If there is an existing CFMM Blueprint that serves Bobs needs, his Lender Blueprint could be written to instantiate the CFMM Blueprint (including configuring it) within its own instantiator function. In this way, the developer can directly include proven third-

Blueprints have their own unique address, and are associated with the creators own unique address. Blueprints are intended to offer versioning, with each new deployed update requiring a revision bump. Updating a Blueprint does not automatically force an update onto other Components or Blueprints making use of it however; previous revisions remain immutably available on-network and existing Components or Blueprints will continue to have access to the previous revision. A developer may choose to adopt a new revision by making their own update. More work remains on the specifics of versioning and updating. 21 3. Self-incentivizing