Are you an LLM? Read llms.txt for a summary of the docs, or llms-full.txt for the full context.
Skip to content

Designed for the internet of tomorrow

EVM-compatible infrastructure with payment-first economics
View as Markdown

Radius gives you Ethereum-compatible development patterns with payment-first economics optimized for real-world transaction volume.

What works out of the box

Most Ethereum development workflows transfer directly to Radius.

ToolStatus
SolidityFully supported (validated up to Prague)
WAGMICompatible
viemCompatible
OpenZeppelinCompatible
FoundryCompatible
Standard precompilesCompatible (validated up to Prague)

What differs from Ethereum

Radius is EVM compatible, but it makes deliberate tradeoffs for payment workloads.

Use fixed, predictable fees

Ethereum fees change with demand. Radius uses fixed gas pricing so costs remain predictable.

EthereumRadius
Fee market biddingFixed gas pricing
eth_gasPrice varieseth_gasPrice returns 9.85998816e-10
Cost planning is dynamicCost planning is deterministic

A standard transaction cost is about 0.00010 USD.

Settle in milliseconds

EthereumRadius
Confirmation-based confidenceImmediate finality
Reorg risk existsNo reorg model
Minutes to high confidenceMillisecond-scale settlement

Use stablecoin-native fee flow

EthereumRadius
Must hold ETH for feesFees paid in RUSD
Separate gas-asset requirementStablecoin-native flow for payment apps
Volatile fee assetStable-value fee model

Contract implications

Keep standard Solidity patterns

Your existing contract logic and ERC standards work as expected.

IERC20(token).transfer(recipient, amount);
 
mapping(address => uint256) balances;
balances[msg.sender] = 100;
 
emit Transfer(from, to, amount);

Avoid assumptions tied to Ethereum-native balance semantics

Prefer explicit token accounting over patterns that assume ETH-style native balance behavior inside contract logic.

// Prefer token-based accounting checks in payment flows.
require(IERC20(feeToken).balanceOf(address(this)) > 0);

Data integrity model

Radius prioritizes deterministic execution and replicated operation:

  • Three-node clusters provide fault tolerance
  • Replication preserves data durability
  • Deterministic execution preserves consistency

This model is designed for high-throughput payment infrastructure.

Why this matters for modern applications

AI and machine-to-machine payments

Autonomous systems need low-latency settlement for API calls, inference, and compute usage. Radius supports this with:

  • Instant settlement
  • Sub-cent transaction costs
  • Stable-value fee economics

Micropayment business models

Low predictable cost unlocks:

  • Per-request API billing
  • Pay-per-visit content
  • Streaming payments for compute and bandwidth

EIP support

Radius tracks Prague support through Revm 33.1.0.

EIPSupport
EIP-7702Supported
EIP-1559Supported (adapted to fixed-fee economics)
EIP-2930Supported
EIP-4844Supported

Precompiles

Address rangePrecompile set
0x01 - 0x0aStandard Ethereum precompiles
0x4Db27Fa...Radius Edge extensions
0x07a2bA2...Debug utilities

Network configuration

ParameterValue
Network NameRadius Testnet
RPC URLhttps://rpc.testnet.radiustech.xyz
Chain ID72344
Currency SymbolRUSD

Next steps

  • Ethereum compatibility — Behavior differences and RPC constraints that affect production systems
  • Network and RPC — Endpoints, chain IDs, and integration setup
  • Fees — Fee model and the Turnstile behavior