Overview
Composability is the ability of one application to use another as a part: to call its code, hold its assets, and feed its output into something else. On Radix it works at three levels, each supplied by the platform rather than agreed between developers: code deployed by one team can be instantiated and called by any other; every token behaves the same way in every application because the engine defines what a token is; and a single transaction can chain calls to many applications, passing assets from one to the next. The strict form of the third, where the whole chain succeeds or fails as one, has its own page, Atomic Composability.
Reusing Code
Scrypto, Radix's Rust SDK for on-ledger code, splits a smart contract in two. A blueprint holds the logic and the shape of the state; a component is a live instance of it, with its own state and assets. Blueprints are deployed in packages, and "multiple components can be instantiated from the same blueprint": the docs' example is one liquidity-pool blueprint serving many token pairs, each pair its own component that behaves identically (Radix Docs: Blueprints and Components).
Code in one package can call code in another. The docs call this an external or cross-blueprint call, which "allows a developer to create complex systems by composing various blueprints and components together": a blueprint declares the interface it expects, then calls functions on a blueprint at a known package address or methods on a global component (Radix Docs: Advanced External Calls). Whether a given method will accept the call is up to that component's access rules, and its author can charge a royalty on each use.
Shared Assets Without a Token Standard
On Ethereum, a token is a contract, and applications can handle one another's tokens only because their authors implement the same interface: ERC-20 for fungible tokens, ERC-721 for non-fungible ones. A contract that departs from the interface, or implements it with a bug, breaks every application that assumed it.
Radix has no equivalent standard to agree on. Resources, its name for tokens of every kind, "are native to the Radix Engine, meaning the engine knows how resources are created and behaves, therefore enforces resource behaviors"; they can only move between containers, never be copied or lost, and even XRD is one (Radix Docs: Resources). Supply rules, minting rights and withdrawal restrictions are settings on the resource that the engine enforces and wallets can read, not code each issuer writes. A component that accepts a bucket of tokens therefore handles every resource on the network the same way, with no adapter per token, and no application has to be granted an allowance to move a user's tokens (Native Assets vs. Token Approvals).
What developers do agree on is metadata. The metadata standards name the fields, such as name, symbol and description, that the Radix Wallet, the Dashboard and exchanges expect on a resource, component or package, as a "least common denominator" for display. They govern how an asset is presented, not how it behaves.
Composing in the Transaction
The third level does not need either application to know about the other. A transaction manifest lists a sequence of component calls and the movements of resources between them, which "make[s] it possible to compose multiple actions to be executed atomically"; the manifest can also present badges for authorization, pay the fee, and assert minimum amounts so the user gets a guaranteed result (Radix Docs: Transactions & Manifests). Assets returned by one call land on the worktop and are passed into the next, so a swap on one exchange can fund a deposit into a lending market in the same transaction without either team writing integration code.
Since the Cuttlefish protocol update, composition can also span parties. A subintent is a signed mini-transaction with its own manifest that only executes as part of a larger one, exchanging buckets with its parent through yield instructions; the engine guarantees that "in a successful execution, every subintent will be executed in its entirety" (Radix Docs: Subintents). Delegated fee payment and multi-party trades are built this way.
Where Composability Stops
Composition holds only for assets and code on the same ledger. Tokens from other chains reach Radix as wrapped copies through a bridge, Hyperlane, and a transaction on Radix cannot also act on the chain the original sits on; what the copy is worth depends on the bridge, as the 2026 Hyperlane asset drain showed.
Within Radix, every transaction today is settled by one consensus instance covering the whole ledger, so any manifest can reach any component. Keeping that true across many shards is what Cerberus was specified to do, and it has not shipped: the hyperscale-rs work on a sharded network commits per shard rather than braiding consensus across them. Atomic Composability covers what that leaves open.