---
title: "4. Radix Engine Toolkit"
path: "/developers/transactions/04-radix-engine-toolkit"
version: "1.1.0"
author: "Hydrate"
createdAt: "2026-07-27T17:50:53.589Z"
updatedAt: "2026-07-27T17:54:25.770Z"
---

# 4. Radix Engine Toolkit

<Infobox>
| Core library | Rust, compiled to WASM and native targets |
| Wrappers | TypeScript, Python, Swift, C#, Kotlin |
| npm package | [@radixdlt/radix-engine-toolkit](https://www.npmjs.com/package/@radixdlt/radix-engine-toolkit) |
| Scope | Off-ledger only — no ledger state |
</Infobox>

## Introduction

The [Radix Engine Toolkit](https://docs.radixdlt.com/docs/radix-engine-toolkit) (RET) is the library that lets a program outside the network build, sign, and inspect Radix transactions. It is written in Rust and compiled to WebAssembly and native targets, with wrappers published for TypeScript, Python, Swift, C#, and Kotlin. Rust itself needs no wrapper — it uses the `scrypto` and `radix-engine` crates directly.

The boundary that matters is that RET is **strictly off-ledger**. It has no knowledge of ledger state, so it cannot tell you an account balance or whether a transaction committed. Those are [Gateway API](/developers/infrastructure/02-radix-apis) questions. What RET can do is everything that is pure computation: construct a manifest, compile and hash a transaction, derive an address from a public key, and decode [SBOR](/developers/scrypto/04-events-metadata-royalties) payloads. Nearly every wallet, exchange integration, and backend signer on Radix is built on it.

## What It Does

- **Transactions** — manifest building, transaction construction, compilation and decompilation, intent hashing, static validation, address extraction, and execution analysis (working out what a manifest will actually move).

- **Derivation** — virtual account and identity addresses from public keys, virtual signature non-fungible global IDs, and the Olympia-to-Babylon address mapping that migration tooling needs.

- **SBOR** — decoding Scrypto and Manifest SBOR payloads into readable form, and limited encoding back.

- **Events** — decoding events emitted by native components into typed models.

**Static validation** is the part most integrations under-use. It checks a transaction is well-formed — header bounds, signature counts, manifest structure — without a network round trip, which turns a class of submission failures into a local error.

## Choosing an Entry Point

The TypeScript wrapper exposes three classes, and picking the wrong one is the usual first mistake:

- `RadixEngineToolkit` — the developer-facing class. Full functionality, idiomatic TypeScript, **no backward-compatibility guarantee**. Use this unless you have a reason not to.

- `LTSRadixEngineToolkit` — a deliberately small surface with strong compatibility guarantees, aimed at exchange and custody integrations doing simple fungible transfers. Less capable by design; clients often outgrow it.

- `RawRadixEngineToolkit` — the internal WASM invocation layer. No compatibility guarantees at all. You should not need it.

Note also that the TypeScript wrapper is hand-written while the others are generated with UniFFI, and it is scoped to transaction construction, signing, and derivations. For anything beyond that, reach for one of the other wrappers or the Rust library.

## Building a Manifest in TypeScript

`npm install @radixdlt/radix-engine-toolkit`
The `ManifestBuilder` mirrors the Rust builder used throughout the Scrypto test suite, and allocates bucket and proof ids for you:

```
import {
  ManifestBuilder,
  address,
  bucket,
  decimal,
} from "@radixdlt/radix-engine-toolkit";

const manifest = new ManifestBuilder()
  .callMethod(senderAccount, "lock_fee", [decimal(5)])
  .callMethod(senderAccount, "withdraw", [address(xrd), decimal(10)])
  .takeAllFromWorktop(xrd, (builder, bucketId) =>
    builder.callMethod(recipientAccount, "try_deposit_or_abort", [bucket(bucketId)])
  )
  .build();

console.log(manifest.toString());
```

The result is the same manifest text described in [Transaction Manifest Language](/developers/transactions/01-manifest-language) — the builder is a typed way to produce it, not a different format. From there `TransactionBuilder` carries you through header, signatures, and notarisation to a compiled transaction ready for the Gateway, which is the flow described in [Transaction Lifecycle](/developers/transactions/02-transaction-lifecycle).

## When You Need It

Front-end dApps usually do not call RET directly — the [Radix dApp Toolkit](/developers/frontend/01-radix-dapp-toolkit) builds manifests and hands them to the wallet for signing, which is the right pattern when a human approves each transaction. Reach for RET when there is no wallet in the loop:

- **Backend signing** — a service that holds keys and submits transactions itself, such as an exchange withdrawal pipeline.

- **Programmatic wallets** — the official iOS and Android wallets are built on the Swift and Kotlin wrappers.

- **Analysis tooling** — decompiling a transaction or decoding SBOR to explain what it did, without running a node.

- **Autonomous agents** — see [AI Agents & x402 Payments](/developers/ai-agents/ai-agents-and-x402), where the agent constructs a transaction that a policy component or wallet then authorises.

## Next Steps

- [Radix dApp Toolkit](/developers/frontend/01-radix-dapp-toolkit) — the other direction — let the user's wallet do the signing

## External Links

- [Radix Engine Toolkit — Radix Documentation](https://docs.radixdlt.com/docs/radix-engine-toolkit)

- [radix-engine-toolkit — core Rust library on GitHub](https://github.com/radixdlt/radix-engine-toolkit)

- [typescript-radix-engine-toolkit — TypeScript wrapper and usage guide](https://github.com/radixdlt/typescript-radix-engine-toolkit)

- [@radixdlt/radix-engine-toolkit on npm](https://www.npmjs.com/package/@radixdlt/radix-engine-toolkit)