RADIX WikiRADIX Wiki

Overview

In Scrypto, code is organized into a hierarchy:

  • Blueprints – Templates that define logic, state, and access rules (analogous to Rust structs with impl blocks, or Solidity contracts as classes)
  • Packages – Deployed bundles of one or more blueprints (analogous to Rust crates). Each package has a unique address on the ledger
  • Components – Runtime instances of blueprints, each with its own state, address, and access rules

This model enables code reuse (many components from one blueprint), clear separation of logic and state, and component royalties for blueprint authors.

What a Package Holds

Publishing a package creates one ledger entity whose state is split across seven partitions, and reading the list is the shortest description of what a package is. One holds the blueprint definitions. One holds each blueprint’s declared dependencies. One holds the type schemas. One holds the royalty configuration, one the authorisation template, and one the VM type, which is either Native or ScryptoV1. The last two both hold code: the original WebAssembly as uploaded, and the instrumented WebAssembly the engine actually runs, with metering calls injected so execution charges by the instruction. Both are kept, so a node can show the developer what was published and still execute what was metered.

What a Blueprint Declares

A blueprint is not only code. BlueprintDefinitionInit, the structure a publisher submits, carries seven fields, and five of them are policy rather than logic:

  • Type – Outer, or Inner naming the outer blueprint it belongs to. An inner blueprint cannot exist on its own; a vault is inner to its resource manager, which is what stops a vault outliving the resource it holds.
  • Transient – when set, no component of this blueprint may be persisted. This is how a bucket or a proof is forced to be resolved inside the transaction that created it.
  • Feature set – the options an instantiator may switch on, fixed at publication.
  • Dependencies – addresses always visible to this blueprint’s call frames.
  • Royalty and auth config – the charge per function, and the rules protecting each function and method.

The remaining field is the schema: state layout, function signatures, events and named types. Because the schema is on the ledger rather than in a separate artefact, a wallet or an explorer can decode a component’s state and a method’s arguments without the developer publishing an ABI anywhere, which is what lets the Radix Wallet show what a transaction does before it is signed.

Authorisation is declared here too, and in two parts. Function auth is AllowAll, a map of rules per function, or RootOnly, that last one reserved for functions only the transaction processor may call. Method auth is either AllowAll or a static mapping from method to role, with the roles themselves resolved per component by the role assignment module. The blueprint fixes which roles exist; each component decides who fills them.

Publishing, and What Cannot Change After

The Package blueprint exposes four functions and no others: publish_wasm, publish_wasm_advanced, which additionally takes an owner role and metadata, publish_native, which only the engine’s own genesis and protocol updates use, and PackageRoyalty_claim_royalties. There is no function to replace a package’s code, and no method either.

A published package is therefore immutable, and upgrading means publishing a new package at a new address and moving whatever should move. Blueprints carry a {major, minor, patch} version, and a comment on BlueprintDefinition records the intent behind it – the interface "must be backward compatible with minor version updates" – but the versioning describes definitions rather than giving anyone a way to swap code beneath a running component. A component that exists keeps running the code it was instantiated against, for as long as the ledger does.

Royalties

A blueprint author can charge per call, which is the part of the model with no equivalent on most networks. RoyaltyAmount has three forms: Free, a fixed amount in XRD, or an amount in USD, which the engine converts at the protocol’s own price. A package-level royalty sets the charge per function, and a component can add its own on top. The cap is a constant, MAX_PER_FUNCTION_ROYALTY_IN_XRD, set to 166.67 XRD, so a call cannot be priced arbitrarily high by an author whose blueprint something else already depends on.

Collected royalties accumulate on the package and are withdrawn by whoever holds the right to call claim_royalties. Component royalties covers the instance-level half.

HydrateLast updated Sep 21, 2026v2.0.07 revisionsVerified Sep 21, 2026