한국어Read the whitepaper
Menu
한국어Read the whitepaper

IROA NETWORK ATLAS

A verifiable execution network for the real world.

IROA is a protocol direction that coordinates user-approved real-world tasks through AI, people, institutions, and request-specific verified Nodes—through to a confirmed outcome.

Explore the network
IROA reward status · In validation
  • BasePlanned
  • Native USDCPlanned
Read the whitepaper
IROA ecosystem connecting a voice request with a watch, hospital, mobility, store, verified capsule, and human support
  1. 01Voice Request
  2. 02Task Capsule
  3. 03Verified NodeN2
  4. 04Proof Receipt
  5. 05Base SettlementNative USDC · Planned
  1. 01Interaction Plane
  2. 02Control Plane
  3. 03Execution Plane
  4. 04Settlement Plane
  • User-controlled approval
  • Data minimization
  • Outcome verification
  • Base Primary NetworkPlanned
  • Native USDC SettlementPlanned
  • Personal Data Off-chain
  • IROA Rewards · In Validation

FOUR OPERATING PLANES

Four planes connect human intent to real-world outcomes.

Each plane has a distinct role. IROA never presents an external service’s authority or outcome as its own.

  1. 01

    Interaction Plane

    Captures user intent and approval through phone, watch, mobile, kiosk, and companion devices.

    In validation

  2. 02

    Control Plane

    Separates request state, consent, policy, and trust levels.

    In validation

  3. 03

    Execution Plane

    Runs an isolated Task Capsule with minimum permissions and cleans up when it ends.

    In validation

  4. 04

    Settlement Plane

    Explores a future B2B settlement boundary based on verified completion evidence.

    Planned

Network Atlas

IROA Protocol Path

Requests execute with bounded authority, pass through verifiable outcomes, and reach a planned settlement boundary.

  1. Stage 01

    Request

    The user states a goal by voice, text, or touch and directly approves every consequential action.

    User approval point

    Consequential actions advance only after the user confirms them.

  2. Stage 02

    Task Capsule

    Purpose, one-time permission, data class, expiry, and confirmation points are bound to each request.

    Purpose
    Execute the approved request
    Permission
    One-time permission within request scope
    Data class
    D2
    Duration
    Until completion or expiry
    Public status
    In validation

  3. Stage 03

    Verified Node

    A Node with the required trust level and verified runtime performs only the bounded task.

    N2 Node

    In validation

    An example verification stage that checks policy and runtime state.

  4. Stage 04

    Proof Receipt

    External outcomes and policy requirements are checked, leaving only the minimum evidence required.

    Outcome
    Verifiable outcome summary
    Proof ID
    No live transaction identifier published
    Policy baseline
    Published whitepaper baseline
    Dispute state
    Validation process in design

  5. Stage 05

    Base Settlement

    A future B2B settlement direction, subject to deployment, legal, and security review.

    Network
    Base
    Settlement asset
    Circle Native USDC

    Planned See the settlement boundary

NODE & PROOF

Nodes and evidence have separate, verifiable roles.

No Node controls the entire request. User approval, bounded authority, and external outcome checks remain distinct boundaries.

Trust levels run from N0 public compute to N4 personal approval, and operators run NODEs only after qualification and approval.Explore the NODE network

Execution path from a user request through a secure Task Capsule and verified Node to completion evidence
Execution is limited to the request scope, and evidence is recorded only after the external outcome is confirmed.

01 / VERIFIED NODE

N2 Node

In validation

N2 is the design and review stage for approved access points such as kiosks, welfare centers, and companion devices.

02 / PROOF RECEIPT

Outcome
A task is not complete until its external outcome is verified.
Proof ID
Proof identifiers are published only when deployment and operation can support the claim.
Policy baseline
Policy version is kept as separate minimum evidence.
Dispute state
Uncertain outcomes move to human review and dispute handling.

Privacy Boundary

Keep minimum evidence, not raw data.

Raw personal data remains off-chain.

Minimum on-chain evidence
  • Policy version
  • Outcome-integrity hash
  • Minimal settlement proof separated from identity
Protected off-chain area
  • Raw personal data
  • Conversation, health, and booking details
  • Passwords, OTPs, and payment keys

WATCH · APP · NODE

IROA in everyday life.

User approval and minimal data sharing connect the watch, app, and NODE. This private pilot handles overnight records for users enrolled at a clinic.

An everyday connection

Your night. Your clinic’s morning.

It starts with wearing your watch to sleep. Your phone prepares the record and sends only the information to review to your connected clinic.

Private pilot · Supported devices
Illustrative morning scene of a wrist wearing a watch beside a phone showing overnight delivery status
Illustrative scene and screens

  1. 01 / WATCH

    On your wrist

    The native health app records the night. IROA’s watch screen shows wear and connection status.

    Illustrative IROA watch showing connection statusExplore the watch

  2. 02 / APP

    On your phone

    Read health records with consent and seal only the information to review for your enrolled clinic.

    Illustrative IROA app showing overnight delivery statusExplore the app

  3. 03 / NODE

    At your clinic

    Issue app enrollment codes and review deliveries from connected patient apps.

    Illustrative clinic NODE receipt screenExplore NODE

Your watch’s own health app takes overnight measurements. See the app guide for supported devices and readiness.

PHONE + WATCH

One small step. A more connected day.

An app that explains the next step. A watch that keeps it within reach. The same bright IROA design, built for each screen.

Actual IROA iOS home screen with record guide and waiting delivery statusActual watchOS example-mode capture showing 120 P, today plus 5 P and a mint action button. Awards disabled.
Development previews · Point numbers are examples · Awards disabled
01

A guide, not a guessing game

Enrollment, consent, overnight summaries and delivery history in one place. Local help stays available; the remote AI module is implemented and awaits response validation before activation.

02

A useful glance on your wrist

Preparation, battery, connection checks and local reminders on Wear OS and watchOS. Wear Tile and Apple Watch complications surface record status.

03

Participation, without a price tag

A separate, non-monetary ledger with confirmed, pending and reversed entries. Limits and duplicate prevention are implemented. Awards remain disabled; these are not IROA tokens, cash or a health score.

App & device guide
A bright clinic workspace with an IROA NODE screen showing anonymous sample receipts
Illustrative scene and screens

Data boundaries

Your records stay close. Care stays connected.

Minute-by-minute readings stay on your phone. Information sent to the clinic is sealed so that only its connected NODE can open it.

Explore the NODE network

SETTLEMENT BOUNDARY

Consumer payment and B2B settlement remain separate.

Base and Circle Native USDC are a future B2B settlement direction, subject to deployment, legal, security, and completion-evidence reviews. They are not live settlement infrastructure.

IROA settlement boundary separating everyday consumer payment, outcome verification, and institutional settlement
Consumer PaymentVerified Proof GateBase · Native USDC

Consumers use KRW, cards, bank transfers, and established payment channels.

  1. 01
    Consumer payment

    KRW · card · bank transfer · existing payment channels

  2. 02
    Request and approval

    Confirm scope, cost, and permission

  3. 03
    Outcome check

    Check external outcome and dispute state

  4. 04
    B2B settlement

    Base · Circle Native USDC · planned

Network
Base
Settlement asset
Circle Native USDC
Public status
Planned

A future B2B settlement direction, subject to deployment, legal, and security review.

  • Gas and wallet management are not consumer requirements.
  • IROA will not issue its own stablecoin initially.
  • Raw personal data and detailed execution records are not placed on-chain.

ECONOMY STATUS

Reward design begins with service sustainability.

IROA explores rewards for verified execution, accessibility quality, security, and deletion compliance. Access to essential support never depends on token ownership.

BASE MAINNET / IROA

Issued: 10,000,000,000 IROA0x43f5aF8756A50ba4B80BE649fb988aa7fBcEE94D

2026-10-01 · 7 vaults funded. Public transfers remain restricted at the verification snapshot.

Issuance notice & official contracts ↗

IROA Rewards

In validationMainnet issuance and vault funding are complete. Reward operations and public transfers remain in validation pending separate pilot, legal, and independent audit approvals.
  • No promise of price, yield, liquidity, or exchange listing.
  • Verified contribution is evaluated together with dispute, cancellation, and quality rules.
  • Token ownership is not a condition for essential daily support.

WEB WHITEPAPER

IROA.AI Whitepaper

The complete English edition of the IROA.AI whitepaper. The Korean edition remains the controlling version.

Read the web whitepaper
Version
v1.0
Controlling language
Korean Master
Publication status
Current

Connect real-world requests to verifiable outcomes.

The whitepaper brings protocol architecture, user authority, Nodes and evidence, settlement boundaries, and roadmap evidence into one reading flow.

IROA.AI Whitepaper 1.0 cover

EVIDENCE-GATED ROADMAP

Entry criteria and evidence matter more than dates.

Each phase shows its status, entry criteria, and required evidence so plans are never presented as live operations.

  1. 01

    Foundation

    Current

    Publish the whitepaper and shared principles, and fix the public status language for each capability.

    Entry criteria
    Public information separates operational evidence from plans.
    Evidence
    Whitepaper v1.0 and published design principles
  2. 02

    Request Validation

    Next

    Validate bounded requests that require approval, recovery, and human handoff.

    Entry criteria
    Users understand and can confirm goals and outcomes.
    Evidence
    Request lifecycle and field-validation criteria
  3. 03

    Secure Execution

    Planned

    Design and review per-request isolation, one-time permission, and deletion confirmation.

    Entry criteria
    Residual sensitive data and duplicate execution are controlled.
    Evidence
    Task Capsule and secure execution principles
  4. 04

    Node Network

    In validation

    Approval-based NODE registration, result and deletion receipts, monthly settlement, and reward claims are validated on Base Sepolia, then move through a private-participant pilot and an independent audit to V2. High-risk companion-device and robotics boundaries remain long-term research.

    Entry criteria
    The Base Sepolia deployment manifest and module validation are complete.
    Evidence
    Pilot stages A–E and the NODE network page
IROA human handoff in which a support worker and user review an uncertain request together
When automation is uncertain, decision authority and context return safely to a person.

INSTITUTIONAL READINESS

Design the validation scope with institutions and practitioners.

Future participation begins with the target users, one real-world task, and the current failure, delay, and human-handoff process.

Official contact channel in preparation

What to include in a future inquiry

  1. 01Institution and target users
  2. 02One real-world task to validate
  3. 03Current failure, delay, and human-handoff process

No personal data is collected until an official contact channel is available.

Read the whitepaper