---
title: "1. Scrypto Fundamentals"
path: "/developers/scrypto/01-fundamentals"
version: "1.4.0"
author: "Hydrate"
createdAt: "2026-02-22T17:46:02.323Z"
updatedAt: "2026-08-02T15:07:21.073Z"
---

# 1. Scrypto Fundamentals

## [Asset-Oriented](/contents/tech/core-concepts/asset-oriented-programming) Programming

Scrypto is built on [asset-oriented programming](/contents/tech/core-concepts/asset-oriented-programming) — a paradigm where digital assets are first-class primitives managed by the [Radix Engine](/contents/tech/core-protocols/radix-engine), not arbitrary integers in a smart contract's storage.

In [Solidity](https://soliditylang.org), 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](https://docs.radixdlt.com/docs/blueprints-and-components), Components, and Packages

Scrypto's object model has three levels:

| Concept | Analogy | Description |
| --- | --- | --- |
| **Package** | Library / crate | Deployment unit containing one or more blueprints. Deployed once, referenced by address. |
| **Blueprint** | Class / template | Defines state shape and methods. Contains no state itself — it's a template. |
| **Component** | Instance / object | A live instantiation of a blueprint. Holds state, owns resources in [vaults](https://docs.radixdlt.com/docs/resources). |

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

### Code Structure

```rust
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](/contents/tech/core-protocols/radix-engine) Differs from EVM

| Aspect | EVM ([Solidity](https://soliditylang.org)) | [Radix Engine](/contents/tech/core-protocols/radix-engine) (Scrypto) |
| --- | --- | --- |
| Assets | Contract storage mappings | First-class resources with engine-enforced rules |
| Transfer | Call a function that mutates state | Move a bucket between [vaults](https://docs.radixdlt.com/docs/resources) |
| Authorization | `msg.sender` checks | Badge-based [access rules](/developers/scrypto/03-authorization-and-badges) |
| Reentrancy | Must be guarded manually | Impossible — resources move, not references |
| Composability | External calls with ABI encoding | Native cross-component calls via [transaction manifests](/developers/transactions/01-manifest-language) |
| Scaling | Single global state | Shard-aware via [Cerberus](/contents/tech/core-protocols/cerberus-consensus-protocol) |

## Key Takeaways

- **Resources are real** — they behave like physical objects, not database entries
- **[Blueprints](https://docs.radixdlt.com/docs/blueprints-and-components) are templates** — they define behavior but hold no state
- **Components are instances** — each with independent state and resource [vaults](https://docs.radixdlt.com/docs/resources)
- **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](/contents/tech/core-protocols/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](/contents/tech/research/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 [&ldquo;underway&rdquo;](https://t.me/hyperscale_rs/10334) rather than a sharding retrofit of the Radix Engine, on the reasoning that [&ldquo;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&rdquo;](https://t.me/hyperscale_rs/10336). The repository does integrate the real Radix Engine today, but [&ldquo;it can only run a simple subset of transactions where the mapping from transaction -> substates can be determined purely from the manifest&rdquo;](https://t.me/hyperscale_rs/10359).

What that costs existing dApps was given a range on 2 August: [&ldquo;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&rdquo;](https://t.me/hyperscale_rs/10346). 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](https://t.me/hyperscale_rs/10338) 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](/developers/transactions/01-manifest-language), 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](/contents/tech/research/hyperscale-rs) page as it develops.

## Next Steps

- [Resources, Vaults, and NFTs](/developers/scrypto/02-resources-and-nfts) — define fungible and non-fungible [resources](https://docs.radixdlt.com/docs/resources) and manage them in vaults
- [Authorization and Badges](/developers/scrypto/03-authorization-and-badges) — badge-based access control, the Scrypto alternative to Solidity `msg.sender` checks

## External Links

- [Scrypto Overview](https://docs.radixdlt.com/docs/learning-to-explain-your-first-scrypto-project)
- [Asset-Oriented Programming](/contents/tech/core-concepts/asset-oriented-programming)
- [What is Radix Engine?](https://learn.radixdlt.com/article/what-is-radix-engine)
- [Components, Blueprints, and the Blueprint Catalog](https://learn.radixdlt.com/article/what-are-components-blueprints-and-the-blueprint-catalog)