Understand Retium
A blockchain built from the ground up on mathematical principles.
Retium replaces the linear, one-block-at-a-time model used by most blockchains with a multi-directional mesh structure governed by prime number mathematics. The result is a network that processes transactions in parallel, confirms them quickly, and scales naturally as usage grows.
Built on Math and Logic
Retium uses prime number mathematics to determine where blocks exist in the network. Every block ID is derived from prime factorization and mathematical composition. Each tick introduces a new prime number, generating new valid block IDs through relationships with previous primes.
Because the rules are purely mathematical, the network structure is deterministic. Anyone can independently verify which blocks should exist at any point by running the same calculations.
There is no randomness, no lottery, and no luck involved.
Traditional Chain
Single path
One block at a time
Throughput bottleneck
Retium Mesh
Blocks connect through shared prime factors, allowing multiple valid blocks to exist and process transactions simultaneously.
3D Mesh Architecture
Retium uses prime number mathematics to determine where blocks exist in the network. Every block ID is derived from prime factorization and mathematical composition. Each tick introduces a new prime number, generating new valid block IDs through relationships with previous primes.
Because the rules are purely mathematical, the network structure is deterministic. Anyone can independently verify which blocks should exist at any point by running the same calculations.
There is no randomness, no lottery, and no luck involved.
Built from First Principles
A blockchain built to solve real problems must be engineered from first principles, not assembled from borrowed parts.
Written from Scratch
Entire protocol built in Rust — no forks, no borrowed consensus.
Security First
Cryptographically signed releases, documented investigations, traced fixes.
Transparent by Design
Architecture documents, processes, and methodologies shared publicly.
Speed of Light
Transactions do not sit in a traditional queue. The Router assigns each transaction directly to an open block, while multiple blocks process transactions in parallel using smart routing based on transaction type, network state, and execution requirements.
Simple transfers are routed through high-throughput execution paths, while more complex operations are isolated into separate blocks to reduce congestion across the network. Users do not choose execution paths or pay additional fees to avoid congestion.
Retium is still in an early stage of development, but preliminary real-world testing has already demonstrated strong throughput potential. Based on current architecture scaling and planned protocol optimizations, throughput targets of 3,000–5,000 TPS on standard infrastructure are considered achievable while maintaining real transaction-level hard finality rather than theoretical or delayed settlement metrics.
Transparent Costs
Retium uses a weight-based fee model. Every transaction is assigned a weight from 1 to 5. A simple transfer costs less than a complex smart contract interaction.
There are no gas auctions and no bidding wars. Fee spikes caused by congestion do not occur because the mesh processes transactions in parallel.
One percent of fees is burned; the remaining 99% is distributed to validators and ecosystem participants.
1%
Permanent deflationary pressure
99%
To validators & ecosystem
1 – 5
Predictable fee tiers
None
No bidding wars
Scalable by Design
Multiple blocks are open simultaneously, typically between 3 and 20 concurrent blocks depending on traffic. RouterHelper dynamically adjusts how many blocks are open. The mesh itself grows exponentially with each tick as new primes generate new valid block IDs.
Workload is also distributed across specialized validator roles: Keepers, Workers, and Suits.
Keepers
Plan blocks, coordinate the network, store full mesh state, manage tick advancement.
Workers
Validate transactions through quorums of five. Most accessible role.
Suits
Validate sealed blocks. Approve block contents and move blocks through finality.
Transaction Finality in Milliseconds
Retium separates transaction confirmation from block finality. Every transaction is executed as soon as it enters the Retium network, reaching SoftFinal status immediately. It is then cross-validated through global consensus by Workers, who verify the post-execution state before the transaction reaches HardFinal confirmation.
Once consensus is reached, the receiver's pending funds become spendable. The transaction is permanent and cryptographically irreversible. This HardFinal stage introduces a small speed trade-off in exchange for stronger security and full network consensus.
Block finality is separate and handled later by Suits. This allows a user's transaction to confirm in milliseconds while the block continues through its own lifecycle.
No Forks. No Imitation.
Retium is built differently. It was written from scratch in Rust as an entirely original architecture. The prime-number mesh, validator role system, routing model, and finality mechanism were all designed specifically for the Retium network.
Retium cannot fork because block IDs are derived from prime-number logic. Each block must fit a unique position in the mesh based on its prime factors, parent links, and ancestry rules. Two nodes running the same calculations will always arrive at the same valid structure.
In traditional blockchains, forks can occur when competing blocks are produced at the same height. The network must then choose which branch to follow, often using a "longest chain wins" rule.
In Retium, that situation cannot arise. A competing block cannot simply appear beside the valid one, because every block position is defined by prime-number relationships. If a proposed block does not match the required prime structure, it is invalid and rejected.
Forks are not resolved in Retium.
They are structurally impossible.
No Mempool
In most blockchains, transactions are collected in a mempool, a waiting area where they sit until a miner or validator includes them in a block. This creates several problems: transactions can be reordered for profit, front-running attacks become possible, and users have no certainty about when their transaction will be processed.
Retium has no mempool. When a transaction arrives, the Router assigns it directly to an open block. There is no waiting room and no intermediary step.
This design eliminates an entire category of attacks. Front-running, where someone observes a pending transaction and submits their own transaction ahead of it, requires a mempool to work. MEV (maximal extractable value) extraction, where validators reorder transactions for profit, also depends on having a pool of unprocessed transactions to manipulate. Without a mempool, these attack vectors do not exist.
Transactions are processed in the order they arrive and routed by weight for efficiency. The system is first-come, first-served by design.
Why Retium Exists
Retium was built to create a blockchain architecture that is fast, fair, scalable, and mathematically structured from the ground up.
Our goal was not to copy an existing blockchain and make small changes to it. If you copy an architecture that already carries limitations, you also inherit those same limitations. That is why Retium was written from scratch in Rust and designed as an entirely original network.
Every part of Retium was designed specifically for this network: the PrimeMesh, validator roles, routing model, finality mechanism, and block creation logic.
Retium exists because we believe blockchain infrastructure should be built for real-world use from the beginning. Payments, gaming, AI systems, enterprise applications, digital assets, and high-throughput platforms need a network that can process transactions quickly, route them efficiently, and scale without forcing users into unnecessary complexity.
This is why Retium was not forked, copied, or modified from another chain.
It was built from scratch because a new architecture requires a new foundation.
Parallel Processing
Multiple blocks processed simultaneously within each tick.
Specialized Roles
Keepers, Workers, and Suits each handle distinct responsibilities.
Deterministic Finality
No probabilistic guarantees — mathematical certainty.
Direct Routing
No mempool. Transactions go straight to blocks.
Mathematical Structure
Block positions determined by prime number factorization.
Main Goal
Retium's goal is to become a blockchain infrastructure layer for mass adoption, real-world asset tokenisation, and business-grade applications.
Retium is not built only for crypto-native activity. It is built to give businesses, institutions, developers, and real-world platforms a stronger foundation to enter the blockchain space with confidence.
The network is designed for payments, gaming, AI integration, enterprise systems, real-world assets, digital identity, tokenised ownership, and other applications that require dependable blockchain infrastructure.
At its core, Retium aims to make blockchain usable beyond speculation — as practical infrastructure for real economic activity, digital ownership, and large-scale adoption.
Explore Use Cases