Overview
Scrypto is the Rust toolkit for writing Radix smart contracts. A blueprint is an ordinary Rust crate that depends on the scrypto crate, published on crates.io as The Scrypto standard library
. The scrypto build command hands that crate to cargo build --target wasm32-unknown-unknown, and the WebAssembly module which comes out is what gets deployed to the ledger as a package. Radix's own documentation describes the central #[blueprint] macro as a way to define a blueprint using items defined in Rust grammar
. The grammar is Rust's, and so is the compiler.
What the toolkit adds is a vocabulary for assets. Tokens and NFTs are resources the developer moves between buckets and vaults rather than balances written into a mapping, the approach this wiki covers under asset-oriented programming.
Key Differences from Solidity
- No reentrancy – Scrypto's execution model makes reentrancy structurally impossible. Assets are in call-frame-local buckets that can't be accessed from nested calls.
- No approval pattern – Assets move directly via buckets. No
approve()+transferFrom(). - Authorization via badges – Instead of
msg.senderchecks, Scrypto uses badge-based authorization. Present a proof of holding a badge to access protected methods. - Blueprints → Components – Scrypto code is organized into blueprints (like classes) that are instantiated into components (like objects) on-ledger.
Modern Rust Support
Scrypto 1.3.1 unlocked modern Rust (1.92.0+) support with a new WASM build pipeline, ending the previous Rust 1.81.0 lockdown. Scrypto 1.4.0, the release that fixed the engine flaw behind the August 2026 asset drain, keeps that toolchain: its rust-toolchain.toml names channel 1.92.0, as 1.3.1’s does. Radix’s install guide still told readers to install Rust 1.81.0 and radix-clis 1.3.0 when checked on 12 September 2026; Getting Started with Scrypto covers which version a fresh install gets.
Language or SDK
Radix's materials call Scrypto a language. The radixdlt-scrypto README opens on the Scrypto language
, the language for building DeFi apps on Radix
; the address of this page says the same; and most of the ecosystem writes it that way.
The mechanism is narrower. Rust's compiler compiles the code, Cargo builds it, and the ledger stores a WebAssembly module. Scrypto is the crate, the procedural macros and the CLI that make such a module easy to produce from Rust. Asked on 2 September 2026 whether the authoring layer for the hyperscale-rs virtual machine amounts to a new language, its lead developer declined the word for both projects at once: let's not call it a language. it's a rust sdk. Scrypto is also not a language
.
Other toolchains can reach the same interface. 0xOmarA, the leading contributor to the Radix Engine Toolkit and one of the main authors of radixdlt-scrypto, replied in the same thread that you can write it in C or AssemblyScript today
, with the caveat that working in any language without an SDK is always going to be hard. What the SDK carries is the macro layer, which generates the metadata and the interface the Radix Engine expects, and writing that by hand is the work nobody wants.
The distinction changes how a portability claim should be read. A contract written in Scrypto is tied to a Rust library and a WASM target rather than to a syntax, so moving it to another authoring layer is an SDK migration. That is the shape the Xi'an transition is taking.
Deterministic Arithmetic
Every Radix Engine transaction must produce an identical result on every validator, so Scrypto does not allow IEEE floating-point math on-ledger. Floating-point rounding differs across hardware and compilers, which means two nodes could compute the same swap and disagree in the final digits. That disagreement would stall consensus. All on-ledger values use fixed-point integer types instead.
- Decimal is a 192-bit signed fixed-point number with 18 decimal places (values of the form m / 1018). It is the default type for token amounts and account balances.
- PreciseDecimal is a 256-bit signed fixed-point number with 36 decimal places, used for intermediate calculations where the extra precision limits rounding loss.
Both types panic on overflow or underflow rather than wrapping around, so an out-of-range result reverts the whole transaction instead of leaving a corrupted balance. The tradeoff is that precision is fixed and rounding is the developer's responsibility to manage.
Scrypto and Xi'an
Scrypto compiles to WebAssembly and runs on the Radix Engine, which is the execution environment of Babylon mainnet. The sharded successor network, Xi'an, is not expected to use the Radix Engine: on 1 August 2026 the lead developer of the production candidate confirmed a purpose-built VM is underway, and that the options which would have left existing dApps untouched have dissolved
.
The replacement authoring layer became legible in the first days of September 2026, and it belongs to the same family: They're both just rust sdks, with vaults, resources, proofs, etc.
The constant-product pool in the hyperscale-vm repository is a #[blueprint] macro over a Rust module holding vaults, buckets and a minted share resource, which a Scrypto developer can read on sight. The visible difference is that a component's data splits in two, mutable state on one side and a creation-fixed #[config] on the other, so the transaction graph can be computed from cached values at admission across shards. The VM itself is bound to no language at all: it takes WASM Component Model guests, with the Rust SDK as the intended path.
Three migration costs are on the record. Compiled packages do not carry over, so every contract needs rebuilding from source. Two capabilities go with sharding: locking a fee from a component during execution, and branching cross-component calls on mutable state. For the rest, the developer expects a transition to be trivial for 99% of builders even if the process cannot be entirely shimmed or run through a transpiler, and says the authoring ergonomics are still in flux, with an everything you need to know
guide a month or two out. That is a forecast about work not yet done. None of it affects Scrypto on Babylon, which is unchanged.