Radix takes a different route from networks that reproduce Ethereum's execution environment. Its Babylon release uses the Radix Engine and a transaction model designed around financial resources. Applications therefore need Radix-specific development and integration work rather than a simple redeployment of an EVM contract. The project's official vision combines a purpose-built language, understandable wallet interactions and eventual sharding.

Those are different layers of the project: Babylon's deployed application environment is not evidence that every promised scaling feature is already running.

Olympia, launched on July 28, 2021, was the first public mainnet. Its practical offering was narrower: transfers, staking, validator operation and a desktop wallet, supported by an explorer. The historical knowledge base describes it as an unsharded Cerberus network. Remembering that limited first release explains why older holders sometimes discuss Radix as a network that existed for years before its application ecosystem. Mainnet age and the age of the smart-contract environment are different historical measurements.

The Olympia-to-Babylon migration preserved token balances, controlling keys and validator stakes, but changed how software represented them. Babylon uses an account-style state model and Bech32m addresses with new prefixes. Its transaction history starts a new state-version sequence, while epochs continue. An exchange or tax tool cannot simply concatenate the two APIs and assume identical records. The continuity is economic ownership; the underlying addresses, transaction formats and indexing rules require deliberate reconciliation.

Protocol changes also require coordination among validators. Radix's node documentation describes ordinary mainnet updates using readiness signals tied to stake thresholds, consecutive epochs and an allowed activation window. Installing software is not the same thing as activating its rules. Nodes must agree when to move together, otherwise the network can lose compatibility or liveness. The documented mechanism gives validator operators a concrete role in upgrades, separate from the Foundation's ability to publish software or a community body's decision to fund development.

A Radix resource is understood by the execution engine itself. Fungible resources can be split and combined; nonfungible resources carry distinct identities. Temporary buckets move resources during a transaction, while vaults retain them between transactions. This makes asset conservation a rule of execution rather than something every application has to reconstruct with its own balance bookkeeping. It does not certify that a resource is valuable or honestly described. A counterfeit token can still use the same well-behaved container machinery as a legitimate one.

Resource creators can also define who may mint, burn, withdraw or otherwise control a resource, and whether those permissions may later change. That flexibility is useful for regulated instruments and restricted credentials, but it means two tokens on Radix can have very different powers attached to them. A reader assessing an asset should examine its configured roles and their mutability. Native asset handling makes those rules expressible; it does not require every issuer to choose fixed supply, unrestricted transfer or immutable administration.

A transaction manifest describes component calls and resource movements in a human-readable form before encoding and signing. It can combine several operations atomically, include authorization badges and assert required resource amounts. Think of an exchange followed by a deposit: the manifest can describe the entire sequence, rather than leave the user to coordinate unrelated transfers. Its value for a wallet is that the intended actions can be inspected before execution. A readable representation remains useful only if the user and wallet interpret the relevant conditions correctly.

The worktop is the transaction's temporary staging area. Returned resources arrive there, can be placed in named buckets and passed to another component, and must end in valid storage. Assertions can make the transaction fail when a required quantity is missing. Fees are locked from an XRD vault before processing. These rules explain both the convenience and the discipline of Radix transactions: a developer must account for what happens to each resource, including leftovers, rather than treat an asset as an arbitrary number in application memory.

A Radix account is instantiated from a native blueprint and has methods and roles. Its owner can withdraw resources, lock fees, create proofs and configure accepted deposits. Separate third-party deposit methods respect those preferences. An unsolicited token can therefore be treated differently from a deposit explicitly authorized by the owner. Account securification can expand the authorization model to support multiple factors. The account component persists as the place holding assets even when its authorization becomes more elaborate than a single initial key.

Applications reach the ledger through several interfaces. The Core API exposes node information and transaction flows, while a Gateway adds services such as filtered history, historic state and resubmission management. The Engine State API provides a more comprehensive view of current engine state when enabled. This distinction matters during an infrastructure handover: a wallet-facing service can be unavailable even while validators continue reaching agreement. Maintaining usable access requires software, indexing and hosting as well as the underlying consensus network.

The validator component records operational configuration and manages stake. Owners can register or unregister, change the consensus key, choose whether to accept delegated stake and signal protocol-update readiness. Delegators consequently rely on more than a displayed reward rate. The node must remain correctly registered and able to participate, and its operator retains specific administrative responsibilities. Radix's component model exposes these operations as ledger methods, making the distinction between holding a staking receipt and running the actual consensus infrastructure explicit.

Staking produces Liquid Stake Units associated with a validator's pool. Reward emissions increase the pool's XRD backing without increasing the existing LSU supply, so the redeemable XRD per unit can rise. The documented reward model allocates emissions by stake, deducts the validator's fee and penalizes missed leader proposals by withholding that epoch's rewards. Only the active top-stake set earns these consensus rewards. This is a receipt for a changing pool balance, not an interest payment guaranteed independently of validator performance.

XRD is the native staking and transaction-fee asset. The tokenomics knowledge base describes a burn of half the base network fee, alongside continuing issuance for network security. A burn and emissions can coexist, so activity does not automatically make net supply contract. The same page distinguishes XRD from eXRD on Ethereum; a representation on another ledger adds its own transfer and backing arrangements. The investment question is therefore about actual demand, issuance and infrastructure costs, rather than treating every transaction as a direct distribution to holders.

The Foundation's February 2026 consultation approved a taper of its additional validator subsidy, with June scheduled as the endpoint and a possible further vote under specified transition conditions. This subsidy was separate from protocol emissions. The published result urged operators to budget for lower support and unregister properly if they could not continue. It also acknowledged that validators might raise their commissions. Community ownership brings a concrete funding question: who pays for dependable infrastructure when an institutional sponsor steps back?

On April 28, 2026, the Foundation announced maintenance mode from May. It described minimal new development, reduced communications and a handover of services and governance tooling. Critical Gateway, Signaling Server and Connect Relay support had been funded through December, while other services were moving to community or cheaper hosting. Remaining treasury transfer depended on establishing the receiving legal entity and completing legal steps. This was a reduction in organizational activity, not an announcement that the public ledger had stopped.

An earlier consultation had elected a five-person Radix Accountability Council. The February result framed its members as facilitators of the transition, with administrative coordination and a channel between participants and the Foundation. Approval voting allowed support for several candidates, so percentages were not shares of a single exclusive-choice ballot. That institutional history matters because later transitional and permanent council proposals describe different roles. A title such as RAC cannot, by itself, establish who currently holds legal authority or controls a treasury.

The February 2026 Hyperscale report described an interim research phase after Dan Hughes's death. Its author reported a public test across 128 shards, with substantial synthetic swap load and dedicated infrastructure, and emphasized reproducibility and the remaining code handover. Those are test results reported by the project, not a measurement of Babylon's daily production traffic. The article also left publication timing dependent on agreements with outside parties. A credible scaling history preserves the workload, environment and release boundaries around a headline throughput number.

In April, flightofthefox proposed an eighteen-month path from the hyperscale-rs prototype to a mainnet-ready Xi'an implementation, followed by support. The discussion covered milestone payments, third-party audits, wallet changes and validator participation. Cyril supported the developer while asking for explicit performance criteria and protection against thin-market payment effects. The proposal illustrates a community trying to convert experimental work into deliverable obligations.

Its schedule and funding request are evidence of a plan under discussion, not proof that Xi'an has replaced Babylon.

The August 30 governance-framework thread separated constitutional ratification, legal formation, council election and a later activation vote. projectShift explained that these were distinct decisions, with the binding ballot documents taking precedence over the discussion. On September 18, the discussion phase closed for revisions going into subsequent stages. That record does not establish that every later stage had completed by this review.

It does show why the phrase community-governed needs institutional detail: drafting rules, creating an entity and granting operational authority are not interchangeable events.

The April charter discussion exposed a genuine disagreement about pace. Magal36 wanted a minimal legal structure established quickly so that treasury custody could be resolved. Daffy worried that weak rules would leave council members under pressure and emphasized protecting the intellectual property. StokDokulus asked that ordinary voters not accidentally inherit disclosure duties intended for officeholders. These participants shared an interest in continuity but differed about what preparation it required.

Their exchange is more informative than describing the community as uniformly enthusiastic about a DAO.

The wallet's future became an explicit community discussion as Foundation-led development wound down. Ghenadie set out maintenance, contracted development and community options. Vlad considered revenue-producing integrations, while linuxx argued for a neutral wallet funded externally. TheMueller proposed a commercial interface alongside a power-user base. These were competing proposals about incentives and user experience, not newly deployed wallet capabilities. They reveal a practical division between preserving a public utility and turning that utility into a sustainable business.

Leonets's May proposal sought milestone funding for Root Finance V2. Timan Rebel, posting as djtebel, questioned whether the community could afford future application development and argued that builders should fund their own products. Leonets replied that a credible delivery needed a team. This is an original dispute over scarce resources, rather than evidence that a grant was approved or that the application was safe. It shows how a small ecosystem's ambitions are filtered through maintenance costs, developer availability and obligations to existing users.

Radix allows package publishers and component owners to configure royalties on functions or methods. The charge becomes part of the transaction fee and is paid in XRD; an approximate dollar denomination uses a protocol-defined conversion rather than a live promise of exact fiat value. Component royalties can be fixed or updatable, while package royalties have their own rules. This offers developers a direct charging mechanism. It also makes pricing and administrative permissions part of the application's relationship with users and other developers who compose it.