iExec RLC

iExec RLC: A Marketplace for Verifiable Off-Chain Computing

iExec connects application builders, data owners, computing providers, and users through an RLC-denominated marketplace. Its core design combines blockchain escrow, worker pools, staking, result verification, and trusted execution environments, while leaving important questions around hardware trust, governance, and real usage open.

What iExec is designed to do

iExec is a decentralized computing platform for applications that need access to external computing resources, datasets, or privacy-preserving execution. Its intended participants include application providers, dataset owners, workers that supply computing power, worker-pool operators, and users or smart contracts that pay for task execution. The marketplace links these participants, while the Proof of Contribution protocol, or PoCo, coordinates how off-chain work is recorded, checked, and paid for.

This makes iExec different from a conventional cloud service in structure, not necessarily in user experience. The system attempts to place the commercial agreement and security deposits on-chain while leaving the actual computation to external machines. That model is aimed at developers who want to outsource workloads or monetize applications and datasets without building their own complete cloud infrastructure.

How the marketplace and PoCo fit together

A typical workflow starts with registered applications, datasets, and worker pools. A worker-pool scheduler publishes an offer describing available resources, pricing, and a chosen trust level. A user selects an offer and creates a work order containing the application, optional dataset, and execution parameters. The iExec Hub records the agreement and locks relevant funds or stakes before the task is processed.

Workers then execute the task and submit cryptographic commitments to their results. PoCo uses multiple contributions, result revelation, and a consensus rule to determine whether a valid result has been produced. The result archive itself is not placed on-chain; hashes and contribution records provide an auditable representation. This design can penalize incorrect or incomplete contributions, but it also requires suitable worker selection, scheduler coordination, and deterministic application behavior for replicated computations to agree.

Trusted execution and confidential workloads

For privacy-sensitive jobs, iExec has built around trusted execution environments, or TEEs. The project’s technical material describes encrypted inputs being processed inside an enclave, with secrets delivered through a secret-management component and execution evidence linked to the worker. More recent project material describes work toward Intel TDX-based confidential computing and broader support for confidential AI, DeFi, and real-world-asset workflows.

TEEs are a practical dependency rather than a universal guarantee. Confidential execution depends on supported hardware, attestation procedures, software configuration, and the way applications handle inputs and outputs. iExec has also acknowledged a tension between broad public participation and the limited availability of consumer machines with suitable TEE capabilities. Its worker-pool strategy therefore includes external operators and partner-managed infrastructure, which may improve capacity while introducing additional operational and trust dependencies.

What RLC does inside the system

RLC is used as the payment and settlement asset for the iExec marketplace. Project documentation describes it being used to pay for computing resources, application execution, dataset access, and worker contributions. Participants can deposit RLC into the iExec Hub, where balances may be locked for staking, rewards, or other marketplace obligations. The SDK exposes modules for accounts, applications, datasets, deals, orders, tasks, results, storage, wallets, and worker pools, reflecting the token’s role in a wider service workflow rather than a single-purpose fee function.

iExec’s 2025 tokenomics material adds vouchers, builder incentives, and other programs intended to simplify access and encourage application development. These are project-designed mechanisms and should be separated from independently measurable demand: a voucher or incentive can increase usability, but it does not by itself demonstrate sustained production usage. The same material describes RLC as having a fixed supply of approximately 86 million tokens; this is a project statement that should be checked against the relevant contract and network records when supply precision matters.

Governance, upgrades, and control points

iExec’s governance position has changed in emphasis over time. In a 2020 discussion of PoCo, the project said its V3 contracts were not upgradeable and that using RLC as a governance token had been rejected at that stage because combining utility and governance could create unwanted effects. The same discussion described social reputation and user choice as important controls over schedulers, rather than relying on an on-chain court or universal blacklist.

The current open-source PoCo repository documents a modular contract architecture based on ERC-2535 for later protocol versions, including facets, deployment configuration, registries, and ERC20-based escrow. That code structure makes upgrades and multi-chain deployments more flexible, but it also means users and integrators need to identify the relevant deployment, administrator permissions, upgrade authority, and verified contract code on each supported network. The existence of open-source code is not the same as proof that every deployment has identical controls or risk characteristics.

Practical limitations and open questions

The main technical limitation is that iExec combines on-chain settlement with off-chain infrastructure that users do not control directly. Scheduler behavior, worker availability, networking, storage, application determinism, enclave attestation, and result delivery can all affect an execution. A blockchain record can make payments and commitments auditable, but it cannot by itself guarantee that a workload is useful, available at the required time, or safe from every hardware or software failure.

For RLC, the practical question is how much recurring demand comes from paid computation, protected data, applications, and confidential workloads rather than from grants, campaigns, or trading activity. The project’s roadmap targets AI, DePIN, confidential DeFi, and RWA use cases, but those are intended markets and development priorities, not proof of mature adoption. Readers should therefore evaluate deployment-specific contracts, worker-pool availability, application activity, liquidity, and governance controls separately before treating the broader iExec thesis as established.

Key takeaways

• iExec is a decentralized marketplace for computing resources, applications, datasets, and task execution.
• PoCo uses on-chain escrow, worker contributions, commitments, result revelation, and staking-related incentives to make off-chain work auditable.
• RLC is used for marketplace payments, deposits, rewards, and access to iExec services; project-led programs add vouchers and builder incentives.
• Trusted execution environments are central to iExec’s privacy strategy, but they create hardware, attestation, software, and operator dependencies.
• The open-source PoCo codebase documents modular, multi-chain contract infrastructure, so deployment-specific controls matter.
• Roadmap claims around confidential AI, DeFi, and RWA describe intended expansion and should not be treated as proof of current production adoption.

Risks and open questions

• TEE-based privacy depends on supported hardware, correct attestation, secure software configuration, and trustworthy handling of inputs and outputs.
• Worker pools and schedulers remain operational control points for task routing, worker selection, availability, and service quality.
• Replicated computation can be difficult for non-deterministic applications because workers may produce different valid outputs.
• The move toward modular and upgradeable contract architecture requires careful review of administrator and upgrade permissions for each network deployment.
• RLC demand depends on recurring paid usage of applications, datasets, and computing services; project incentives or roadmap announcements do not establish that demand.
• Liquidity, contract verification, deployment consistency, and worker-pool availability may differ across Ethereum, Arbitrum, Energi, Sora, and other supported environments.