Building on Radix

Introduction

Building on Radix asks you to unlearn one habit before anything else works. On most networks a token is a number your contract keeps in a mapping, and moving it means writing code that decrements one entry and increments another. On Radix the engine owns the asset. A resource moves between vaults through the engine’s own rules, and a blueprint that tries to lose it will not compile into a transaction that commits.

That single change removes a category of bug rather than a line of code, and it is why the learning path below starts with resources rather than with syntax.

The path

Getting started installs the toolchain, writes a first blueprint and deploys it to Stokenet and then mainnet. The Scrypto series is the long one: fundamentals, resources and NFTs, authorization and access rules, events and royalties, testing, vault patterns, multi-component architecture, oracles, and permissioned assets.

The transactions series covers the layer between an application and the ledger – the manifest language, the transaction lifecycle, fees, the Radix Engine Toolkit, and how addresses and entity types are formed. Manifests are worth real attention: a Radix transaction states what it intends to do in a form the wallet can show a user before they sign it.

On the client side, the front-end series runs from the dApp Toolkit through the Gateway SDK to ROLA, the wallet-signature login this wiki itself uses. Infrastructure covers running a node and the public APIs, and tools collects the community libraries and manifest builders.

Agents

The newest branch here is for software that acts on its own behalf. Radix Context and Radix Skills package the protocol’s documentation for coding agents, and x402 payments covers the emerging way an agent pays for a request it has just been refused. Radix’s subintents make that pattern unusually clean, because a client can commit to an exact payment without holding the XRD to pay the network fee.

What to expect

Scrypto is Rust, so the borrow checker is part of the job and the compile times are real. In exchange, most of what a Solidity audit looks for is unrepresentable: there is no reentrancy path through a resource transfer, no approve-and-drain, and no way to mint an asset a blueprint was not authorized to mint. Whether that trade suits a given project is a judgment about the team as much as the protocol, and it is worth making before the first blueprint rather than after.