RADIX COMPONENT CATALOG
Radix DLT is a distributed Layer 1 system that meets the DeFi ecosystem needs (decentralized finance). While DeFi continued to compete, large blockchain networks supporting the market were already congested. As a result, scalability seems to be a tough nut to crack, and that is why projects like Radix DLT are built.
Creating the Radix Protocol aims to recapture the $ 71 billion lost annually through unnecessary friction in the traditional financial system and enable those at the lowest and highest financial levels to strengthen the DeFi ecosystem.
COMPONENT CATALOG
A developer’s work becomes an active smart contract in other blockchain systems after being passed on to system users. The component catalog for Radix processes applications before they are registered as “active” on the platform.
Components replace the intelligent contracts from Radix and enable the Radix Royalties system.
As with typical smart contracts, components allow a developer to create strong logic that is deployed and executed without relying on the network. However, there are significant differences. Components are created using a finite state machine (FSM) logic.
Instead of being deployed on the network and activated for immediate use, components are initially deployed as a kind of template in a general ledger repository, referred to as the component catalog.
Catalog components can be scanned multiple times (via a simple API call) into active embodied components, each time configured for specific user needs and with which users (and other incorporated components) can interact. Existing template components can be imported within the catalog so that new code can be placed over existing best-practice features without the need to copy or redistribute them.
Components are Radix’s substitute for smart contracts, and they make the Radix Royalties system possible.
Like typical smart contracts, Components allow a developer to build a strong logic that is deployed and executed with no doubt on the network, but there are some essential differences. More concretely, components are simply defined by what they possibly can do via its Actions.
By defining components by their Actions in this way, components can behave intuitively like physical assets or other finance building blocks.
With typical smart contract DLTs, a developer writes some code and then pushes it to the network where it becomes an active smart contract for users of the system to interact with.
How the Radix component catalog work
In typical smart contract DLTs, a developer writes code (Solidity in the case of Ethereum) and then sends it to the network, where it becomes an active smart contract that network users can interact with. The component catalog changes this model.
When a component’s scrypto code is sent to the network, it is first automatically added to an accounting record called the component catalog. Catalog components are like templates or inactive sheets that anyone can use to create various active components in the catalog based on the original.
To activate a catalog component for use, a developer creates his own sample component from the plan template and starts it. A sensed component has its own unique ID on the Radix network, and its actions are available to users or other components. This means that there is no limit to the number of times a component can be used in the catalog as a template for initialized components, which all behave in the same fundamental way.
The new components come to life as scrypto code added to the Radix network components catalog and can be easily configured and run or transferred to other new components.
The set up is simple, done through the API, and does not require any scrypto code. Most of the catalog components contain configuration parameters that you can use to customize the built-in component. In the component “token definition” described above, everyone can have their own token definition with their own name, symbol, leading resource, etc. This allows you to embed your own symbols and then print them.
By scanning components from a universal general ledger catalog in this way, Radix makes it very quick, easy, and secure for any developer to publish assets and access other simple functions created by others without learning and writing scrypto code.
Another way to use catalog components is to import them. A developer may want to utilize an existing component in the catalog but wish to add or customize what they can do with it. To do this, a new component is created that contains an import command for the component that offers the desired basic functionality. The additional functionality is then implemented in the developer’s own scrypto code.
When importing, the scrypto code of the original component is not copied. This is a link in the ledger to the original component (and version). An example of this could be a Price Oracle component that a developer might want to customize by adding a moving average price calculation (and the action to access it). The developer can create his own Oracle Special Pricing Component, import the original Oracle Pricing Component regarding its ID in the catalog, and add additional scrypto code for calculating the average price.
Both catalog components and sample components have their own unique component ID and are assigned to the unique developer ID of the creator. The components are versioned, and each newly deployed update requires a patch increment. Updating a component does not automatically force other components that use it to be updated. All previous revisions remain available in the general ledger, and existing components continue to access the previous revision. A developer can take on a new revision by performing his own component update with it.
Standard platform components
The Radix Foundation strives to complete the catalog with useful components that model common DeFi elements and behavior as standard platform functions. This includes assets (tradable or non-tradable tokens) and accounts (including multiple character verification) and is augmented with community-requested functionality that can consist of high-level DeFi staples like liquidity funds, exchange systems, etc. acquirable assets. Data oracle and more. Any of the standard catalog components developed by the Radix Foundation can be launched as is (e.g. provision of custom tokens via an API call) or can be modularly combined in various ways to create more complex functions.
With these standard catalog components, developers can bypass available feature redistribution themselves, speed up development time, or reduce them to zero for specific things like issuing a token. Catalog components created by third parties can likewise be transformed into standardized functions of the Radix network. No matter who creates them, the notebook’s catalog components make a natural compositional capability and interoperability for the DeFi ecosystem.
The Radix Developer Royalties system provides protocol-level incentives for everyone to contribute large or small components that can become “standards” for the platform.
Visit:
