1. Scrypto Fundamentals

Asset-Oriented Programming

Scrypto is built on asset-oriented programming — a paradigm where digital assets are first-class primitives managed by the Radix Engine, not arbitrary integers in a smart contract's storage.

In Solidity, a token is a mapping of addresses to balances inside a contract. Transferring tokens means calling a function that modifies that mapping. Bugs in this logic cause real losses — reentrancy, integer overflow, and unauthorized access.

In Scrypto, tokens are resources — objects with physical-like properties enforced by the engine. They cannot be duplicated, destroyed without authorization, or exist outside a container. The runtime guarantees that every resource is accounted for at the end of every transaction.

Blueprints, Components, and Packages

Scrypto's object model has three levels:

A single blueprint can be instantiated many times — each component is independent with its own state and resource holdings.

Code Structure

use scrypto::prelude::*;
 
#[blueprint]
mod my_blueprint {
    struct MyBlueprint {
        // State fields — persisted between transactions
        my_vault: Vault,
        count: u64,
    }
 
    impl MyBlueprint {
        // Functions: called on the blueprint (no &self)
        // Used for instantiation
        pub fn instantiate() -> Global<MyBlueprint> {
            Self { /* ... */ }
                .instantiate()
                .prepare_to_globalize(OwnerRole::None)
                .globalize()
        }
 
        // Methods: called on a component (&self or &mut self)
        pub fn get_count(&self) -> u64 {
            self.count
        }
 
        pub fn increment(&mut self) {
            self.count += 1;
        }
    }
}

The #[blueprint] macro handles serialization, state management, and ABI generation. You write plain Rust structs and methods.

How Radix Engine Differs from EVM

Key Takeaways

• Resources are real — they behave like physical objects, not database entries
• Blueprints are templates — they define behavior but hold no state
• Components are instances — each with independent state and resource vaults
• The engine enforces safety — reentrancy, double-spend, and overflow bugs are prevented at the runtime level

Scrypto and the Xi'an Execution Layer

Everything above describes the Radix Engine as it runs on Babylon mainnet today, which is the environment to learn and deploy against. It is not the environment Radix's next release is expected to ship.

Xi'an's sharded execution layer, hyperscale-rs, requires every transaction to declare which state it will touch before anything executes — that declaration is what fixes the participating shards and lets conflicts be analysed without running the transaction. On 1 August 2026 its lead developer confirmed that a purpose-built VM is “underway” rather than a sharding retrofit of the Radix Engine, on the reasoning that “the sharding adjustments are so many that it'd require touching everything. at some point it becomes easier to start with intention than to retrofit”. The repository does integrate the real Radix Engine today, but “it can only run a simple subset of transactions where the mapping from transaction -> substates can be determined purely from the manifest”.

What that costs existing dApps was given a range on 2 August: “best case scenario - contracts will just need a recompile. worst case scenario - there'll be some automatic transpiler devs can use to upgrade source code”. Both ends of that range describe migrating source rather than rewriting it. Whether Scrypto survives under its own name has not been stated — the question was put to the channel and drew no direct reply, and no mapping from today's blueprint model to the new VM has been published. The stated design goal, that a transaction's full set of touched substate keys be derivable statically from the manifest, is a stricter form of the declared-intent model Scrypto already uses rather than a departure from it. The wiki tracks this on the hyperscale-rs page as it develops.

Next Steps

• Resources, Vaults, and NFTs — define fungible and non-fungible resources and manage them in vaults
• Authorization and Badges — badge-based access control, the Scrypto alternative to Solidity msg.sender checks

External Links

• Scrypto Overview
• Asset-Oriented Programming
• What is Radix Engine?
• Components, Blueprints, and the Blueprint Catalog