Built for Developers

Clarity, safety, and performance — everything you need to build on Retium.

Retium provides a complete smart contract platform designed around clarity, safety, and performance. Rust is the native development language, and contracts are compiled to WebAssembly and executed in a sandboxed runtime with deterministic behavior across all nodes.

The developer experience centers on a single contract standard, a predictable execution model, and a deployment process that requires no special infrastructure.

Rust Native

WASM Runtime

Deterministic Execution

terminal

$ cargo build --target wasm32-unknown-unknown --release
$ retium-sdk deploy target/wasm32-unknown-unknown/release/contract.wasm \
--sk-path ./deployer.sk
Deploying contract...
From: reteeb4c87a3f01d2
Contract ID: 7a3f1c...c1d2
Deploy submitted successfully
$ retium-sdk call 7a3f1c...c1d2 transfer '{"to":"reteeb4c87a3f01d2","amount":100}' \
--sk-path ./deployer.sk

Single Contract Standard (RCP-1)

A unified contract model eliminates fragmentation and simplifies development.

Predictable Execution

Deterministic behavior ensures identical results across all nodes.

No Special Infrastructure

Deploy contracts directly without complex setup.

Build in Any Language

Retium uses WebAssembly as its contract execution format, making it language-agnostic. Any language that compiles to WASM can be used to build contracts.

Rust remains the recommended choice due to its strong toolchain and safety guarantees, but developers can also use C, C++, AssemblyScript, Go (TinyGo), Zig, and more.

WASM is the contract format. The source language is invisible at runtime.

recommended

Rust

C++

AssemblyScript

Zig

RCP-1 Retium Contract Protocol

Some legacy blockchains ecosystems accumulate multiple competing token standards over time — separate standards for fungible tokens, NFTs, multi-token collections, and more. Each comes with its own interface, assumptions, and integration complexity.

Retium replaces all of them with a single unified standard: RCP-1.

RCP-1 is not a token standard in the traditional sense. It is a contract behavior declaration framework.

Every contract on Retium implements the RetiumContract trait and embeds structured metadata directly into its compiled WASM binary using the RCP_METADATA marker.

This metadata defines what the contract does — whether it manages fungible tokens, non-fungible assets, governance, game logic, or any combination — without requiring separate standards.

Validators and keepers read this metadata to determine how the contract should be routed, priced, and executed. Because this declaration is embedded directly in the binary, contracts are fully self-describing. There is no ambiguity about functionality or cost.

contract.wasm

WASM Binary

Compiled contract code

↓

Embedded Metadata (RCP-1)

Weight · Version · Behavior flags

↓

Routing / Pricing / Execution

Validators read metadata

↓

Network

Deterministic processing

🔒 Locking Mechanism

Specific fields, including the contract logic, can be locked individually. Once a field is locked, it cannot be modified — ensuring immutability where it matters for financial or critical contracts.

↗ Evolution System

Contracts that need upgrades use a versioned evolution system with structured version chains.

Metadata includes:

Contract type (e.g. fungible token, NFT, key-value store)
Declared computational weight (1–5)
Behavioural traits and capabilities
Version and evolution chain
Lockable fields

Smart Contracts on Retium

Retium smart contracts can be written in supported programming languages and compiled to WebAssembly.

Contracts run inside a sandboxed execution environment. They do not access the filesystem, the network, or node internals directly. Instead, contract state is accessed through controlled host functions such as read_state and write_state.

This keeps contract execution isolated, predictable, and easier for validators to verify.

Retium's contract layer is designed around deterministic execution: the same contract, given the same input and state, should produce the same result across the network.

A higher-level developer SDK is planned to make contract writing simpler over time. Today, contracts use Retium's lower-level WASM entry point and state functions directly.

contract.rs

fn handle_transfer(caller: &str, args: &[String]) -> String {
    let to = &args[0];
    let amount = parse_u128(&args[1]);
    let from_balance = get_balance(caller);
    if from_balance < amount {
        return "{\"error\":\"insufficient balance\"}".into();
    }
    set_balance(caller, from_balance - amount);
    set_balance(to, get_balance(to) + amount);
    "true".into()
}

Sandboxed execution

Isolated storage

ACID safety

Determinism

Retium Virtual Machine (RVM)

The Retium Virtual Machine is powered by wasmtime, a production-grade WebAssembly runtime developed by the Bytecode Alliance. Wasmtime provides near-native execution speed, strong sandboxing guarantees, and a well-tested compilation pipeline from WASM bytecode to machine code.

Every contract invocation runs with a fuel limit of 100 million instructions. Fuel is consumed by each WASM instruction during execution. When fuel runs out, the runtime traps and the transaction is rolled back.

WASM

→

Runtime

→

Host Functions

→

State

Wasmtime Runtime

Near-native performance with production-grade WebAssembly execution.

Fuel Limits

100M instruction budget prevents infinite loops and resource abuse.

Isolation Boundary

Contracts interact only through defined host functions.

Weight System and Gas

Retium assigns a computational weight from 1 to 5 to each contract in its RCP-1 metadata, reflecting its resource needs to ensure fairness across contracts.

Gas costs rise with contract weight; weight-5 contracts use more gas than weight-1. The network checks actual usage against declared weight to prevent underreporting and ensure fair pricing.

At the block routing layer, Retium's system assigns transactions to blocks by weight, balancing computational load for predictable execution and fair pricing, unlike a flat gas market.

LightMediumHeavy

Contract Evolution

Contracts are not permanently frozen unless locked. They can evolve through versioned chains using the evolves_from field.

Each new version links to the previous contract, forming a transparent upgrade history. The runtime validates each upgrade.

Once locked, a contract becomes immutable. Locking is irreversible and used for production contracts. State is preserved across versions — no migration required.

→

Locked

Versioned upgrades

Irreversible locking

State preserved

APIs and Developer Tools

Contracts declare a computational weight from 1 to 5 in their RCP-1 metadata. The runtime tracks fuel consumption and prevents underreporting.

REST API

Interact with the network through a clean, documented API.

Web Explorer

Inspect chain activity, transactions, and contract state.

Canonical Signing

Secure transaction signing with deterministic serialization.

Retium SDK

Full developer workflow from creation to deployment.

retium-sdk

$ retium-sdk deploy token.wasm
✓ deployed: 7a3f1c4d...c1d2

$ retium-sdk call 7a3f1c4d...c1d2 transfer '{"to":"reteeb4...","amount":100}'
✓ submitted

$ retium-sdk balance reteeb4c87a3f01d2
→ 100 RTM