.svg){kind=small}
.svg){kind=small}
On Radix, the concept of smart contacts is split into two: blueprints and components.
Blueprints
A blueprint is how a Radix smart contract starts life. It is an on-ledger template of smart contract functionality that can be instantiated into “components.” Blueprints are deployed to the Radix Network in what are called Packages, which may contain multiple Blueprints.
Smart contracts are split like this on Radix because Web3 development on other platforms often involves manually copying and pasting code, which is not only slow and cumbersome, but can expose new errors & vulnerabilities if changes are made.
This copying and pasting also results in a huge amount of bloat. Imagine how often the same basic token functionality in an ERC20 contract has been copied and redeployed to Ethereum.
To make Web3 and DeFi development easier, safer, more reliable, and quicker; and to encourage on-ledger standards and reuse of others’ work, Radix’s Scrypto programming language splits the concept of a smart contract into two.
You can think of a Blueprint as like the engineering drawings needed to build a car (a template), and a component as an actual car driving down the road (an instance). At the point of manufacture (instantiation), the car can potentially even be customized with options such as color, engine, or seating arrangements if the creator of the Blueprint included this customization.
More technically, Blueprints are similar to classes in object-oriented programming. Each blueprint contains declarations of state structure, functions, and methods a component can have.
As templates, blueprints contain no internal state and can hold no resources (tokens).
Components
On the other hand, components are the live instantiation of a blueprint. Components are created as “instances” of blueprints, and can be configured at point of instantiation based upon the definition of the blueprint.
Unlike a blueprint, a component can hold state and hold vaults for tokens and NFTs. Components are thus the Radix equivalent to live smart contracts on other networks.
For example, the blueprint below defines the structure and logic of a liquidity pool (in fact, on Radix we have native liquidity pools called Pool Units). The blueprint can then be used to instantiate many different independent liquidity pool components, each configured to cover a different pair of tokens.
Each instantiated component maintains its own configuration and holds its own private state.
One key difference that components have to smart contracts on other networks is that they don’t define how assets behave. Instead that role is performed by Radix Engine’s built-in “resources”, which universally define core asset behavior and allow easy and intuitive manipulation by component logic..
This means components have clearer function, and allows them to be more modular and composable.
There are also special system components that are not developed by a developer, but are instead native to the Radix platform. Smart Accounts are one such example of a system component. See What’s the difference between user components and system components for more.
Blueprint Catalog
As all blueprints are deployed to the public and permissionless Radix Ledger, developers can use these to instantiate their own components. This effectively creates an on-network “catalog” of available blueprints. This fosters easy and transparent reuse, good community-driven standards, as well as the ability for developers to receive direct on-ledger per-usage payment for useful functionality they create via the Developer Royalty System.
You can check out how blueprints and components work in our Technical Docs.
Further reading:
