SETTLEMENT

HTLC-based escrow, proof-linked release conditions, and trust-minimized commercial agreements on a live SHA-256d Proof-of-Work blockchain.

—
Agreements On-Chain
6
Template Types
4
Live Components
Overview

Settlement-first blockchain for escrow, agreements, and proof-based commerce

Irium is an independent SHA-256d Proof-of-Work chain built from scratch in Rust. Its commercial purpose is trust-minimized settlement — what happens before release, after timeout, at refund, or when a verifiable condition is met.

STEP 01
HTLC Escrow
Funds are locked on-chain in a Hash Time-Locked Contract. Release requires the secret preimage; refund is available after the timeout block height. No privileged party controls the outcome.
→
STEP 02
Proof Engine
Attestors submit cryptographic proofs against an agreement hash. A configurable policy defines which proof types and attestors are required before the release path is unlocked.
→
STEP 03
Timeout Refund
If the counterparty does not perform, the funder reclaims automatically after the refund timeout block height. No admin action required — the chain enforces it.
Use Cases

Why payments alone are not enough

Commercial coordination requires more than a transfer. Irium provides the infrastructure for conditional release, milestone payouts, and explicit refund paths.

OTC Escrow
Safer peer-to-peer trading. Seller locks IRM in escrow; buyer delivers off-chain payment; seller reveals the preimage to release funds to the buyer.
Contractor and Service Payments
Milestone-oriented release logic. Each deliverable leg funded and released independently with its own proof requirement and timeout.
Refundable Deposits
Security deposits and preorders with explicit refund paths. Funds return to payer on timeout if the payee does not authorize release.
Milestone Settlement
Staged commercial payouts. Multiple milestones each carry their own amount, secret hash, and timeout — independently fundable and releasable.
Verifiable Commercial Agreements
Agreement hash anchored to chain state. Off-chain terms bound to on-chain outcomes via document hash and cryptographic proof submission.
Merchant Delayed Settlement
Merchant-side settlement with a defined payout deadline. Funds are held in escrow until the merchant triggers release or the buyer reclaims after timeout.
Network Status

What is live today

SHA-256d PoW Chain Settlement Layer OTC Marketplace Proof Ecosystem Reputation System Public Explorer Public Mining Pool Fair Launch

The settlement layer, OTC marketplace, reputation system, and proof ecosystem are all live on mainnet. The base chain is an independent SHA-256d Proof-of-Work blockchain built from scratch in Rust — not a fork.

SHA-256d PoW ChainLive
Settlement LayerLive
OTC MarketplaceLive
Proof EcosystemLive
Reputation SystemLive
Public ExplorerLive
Public Mining PoolLive
No Premine / No ICOFair Launch
  • Rust implementationBuilt from scratch. Not a fork of any existing chain.
  • Objective-only consensusNo admin keys, no override powers, no freeze or seizure mechanism.
  • DNS-free bootstrapResilient peer discovery and Sybil-resistant networking from launch.
  • Mining secures settlementProof-of-Work miners secure the public base layer that commercial settlement depends on.
  • On-chain metadata supportAgreement hashes, proof anchors, and bond records written directly to the chain.
Agreement Templates

Six template types

Each agreement carries a template_type field that iriumd uses to validate and route it. Four types have irium-wallet CLI builders; two are recognized by the protocol but require hand-constructed JSON today.

simple_release_refund
Simple Escrow
Two parties, one amount, one secret hash. General purpose escrow with a single release path and timeout refund. The payer locks funds; release is authorized by revealing the preimage.
CLI builder available
otc_settlement
OTC Trade
Buyer/seller OTC trade. Includes asset reference and payment reference. Seller locks IRM in escrow; buyer receives after delivering off-chain payment and seller reveals the preimage.
CLI builder available
refundable_deposit
Refundable Deposit
Payer/payee deposit with purpose reference and deposit rule. Funds return to payer on timeout if the payee does not authorize release. Suitable for security deposits and preorders.
CLI builder available
milestone_settlement
Milestone Settlement
Multiple milestones, each with its own amount, timeout height, and per-milestone secret hash. Each leg is funded and released independently. Total amount is the sum of all milestone amounts.
CLI builder available
merchant_delayed_settlement
Merchant Delayed
Merchant-side settlement with a delayed payout deadline. Recognized by the protocol and accepted on-chain; requires hand-constructed AgreementObject JSON today.
No CLI builder yet
contractor_milestone
Contractor Milestone
Contractor-style milestone agreement with per-leg release authorization. Recognized by the protocol; requires hand-constructed AgreementObject JSON today.
No CLI builder yet
Lifecycle

Agreement lifecycle states

Every agreement moves through a defined set of states derived deterministically from the on-chain record. Every node reaches the same conclusion.

Draft
→
Proposed
→
Funded
→
PartiallyReleased
→
Released
Refunded
Expired
Cancelled
  • Draft
    Created locally. Funding transaction not yet broadcast.
  • Proposed
    Registered on the node. Awaiting on-chain funding confirmation.
  • Funded
    HTLC funding transaction confirmed on-chain. Funds are locked.
  • PartiallyReleased
    One or more milestones released; remaining legs still locked. Milestone agreements only.
  • Released
    Recipient unlocked funds by presenting the secret preimage. Settlement complete.
  • Refunded
    Funder reclaimed funds after the refund timeout block height was reached.
  • Expired
    Agreement passed its settlement deadline with no release or refund action.
  • Cancelled
    Agreement cancelled before funding.
release_eligible is the authoritative gate. Release eligibility requires both proof finality (proof buried at least 6 blocks deep by default) and a satisfied release policy. Wait for release_eligible: true on the agreement status response before releasing funds.
Proof Engine

Proof submission and policy evaluation

On top of the base HTLC, a proof submission and policy evaluation layer allows release conditions to be verified programmatically before funds move.

Attestors submit signed proof objects against an agreement hash. A configurable policy defines which proof types are required and which attestors are accepted. The evaluator counts only unique attestor identities — duplicate proofs from the same attestor count as one.

Proof finality depth — default 6 blocks. A proof is final after its block is buried at least 6 blocks deep (configurable via IRIUM_PROOF_FINALITY_DEPTH). If a chain reorganization removes the proof block, iriumd emits agreement.proof_reorged and the proof must be resubmitted.
Holdback — policies can declare a fraction of the escrowed amount in basis points that stays locked after the base release condition is met, releasing on its own deadline or proof requirement.
Attestor bonds — attestors may register an on-chain bond to signal accountability. Contradicting proofs from the same attestor can be slashed on-chain via an OP_RETURN anchor transaction.
N-of-M thresholds — a policy can require N-of-M attestor signatures. The evaluator counts only unique attestor identities across the active proof set.

Five standard proof schema kinds:

delivery_confirmed
Attestor confirms goods, services, or a deliverable was received.
payment_confirmed
Attestor confirms off-chain payment (e.g. bank transfer, USDT) was received.
milestone_accepted
Client confirms a milestone deliverable meets the agreed specification.
custom_attestation
General-purpose attestation for use cases not covered by the standard types.
timeout_expiry
Proof that the refund timeout height has been reached; used in automated refund paths.
Trust Model

Objective-only consensus

Irium's settlement direction depends on keeping consensus narrow, deterministic, and objective-only. Subjective judgment, discretionary governance, and privileged override powers conflict with trust-minimized positioning.

  • No admin keysNo privileged key holds authority over agreement outcomes or chain state.
  • No override powersNo party can reverse or block a valid on-chain spend once conditions are met.
  • No freeze or seizure mechanismFunds locked in an HTLC can only be spent by the holder of the preimage or after timeout.
  • No centralized dispute authority in consensusResolution options are defined by the agreement itself, not by a privileged operator.
  • Rules-based settlement paths onlySignatures, attestors, proofs, and timeouts must remain explicit and technically verifiable.
  • Mineable and publicly securedProof-of-Work mining secures the base layer that commercial settlement depends on.
Roadmap

Development phases

What exists, what is in development, and what is planned.

Phase 1
PoW Foundation
Core independent PoW chain, Rust node, public explorer, mining guide, mining calculator, fair-launch profile, resilient peer discovery, Sybil-resistant networking, DNS-free bootstrap.
Live
Phase 2
Settlement Primitives
Agreement anchoring, native HTLC escrow, timeout refunds, settlement layer, OTC marketplace, reputation system, proof ecosystem, milestone and deposit flows.
Live
Phase 3
Proof Automation
Objective proof validation, approved attestors, no-response auto-settlement, milestone proofs and holdbacks, N-of-M attestor thresholds, on-chain reputation anchoring.
Planned
Phase 4
Commercial Tooling
Merchant and contractor template builders, recurring invoice direction, dispute resolution, broader integration APIs, reputation tooling for marketplace participants.
Planned
CLI Reference

Using settlement via irium-wallet

The irium-wallet CLI handles the full agreement lifecycle from wallet setup through funding, proof submission, and release. All chain commands accept --rpc <url> to specify a node (default: http://127.0.0.1:38300).

Wallet Setup
irium-wallet init
irium-wallet new-address
Create and List Offers
irium-wallet offer-create \
  --seller <YOUR_ADDRESS> \
  --amount 1.0 \
  --payment-method bank-transfer \
  --timeout 25000 \
  --price-note "1 IRM = 0.10 USD"

irium-wallet offer-list --status open --sort score
Take an Offer and Fund the Agreement
irium-wallet offer-take --offer <OFFER_ID> --buyer <BUYER_ADDRESS>

irium-wallet agreement-fund agreement.json --broadcast --rpc http://127.0.0.1:38300
Submit a Proof
irium-wallet agreement-proof-create \
  --agreement-hash <AGREEMENT_HASH> \
  --proof-type delivery_confirmed \
  --attested-by attestor-id \
  --address <ATTESTOR_ADDRESS> \
  --evidence-summary "Payment confirmed." \
  --out proof.json

irium-wallet agreement-proof-submit --proof proof.json --rpc http://127.0.0.1:38300
Check Eligibility and Release
irium-wallet agreement-release-eligibility agreement.json --rpc http://127.0.0.1:38300

irium-wallet agreement-release agreement.json \
  --secret <PREIMAGE_HEX> \
  --broadcast \
  --rpc http://127.0.0.1:38300
Auto-Release Watch Mode
irium-wallet watch --auto-release
Get Started with Irium Core

Desktop wallet and full node — GUI interface, agreement builder, marketplace browser, and irium-wallet CLI included.

Download Irium Core

Windows / macOS / Linux  ·  github.com/iriumlabs/irium-core/releases/latest