IROA.AI Whitepaper

1.1 Mission

Link

IROA’s mission is to ensure that skill with digital devices is never a condition for survival or independence. Regardless of age, disability, literacy, dexterity, vision, hearing, or cognitive pace, everyone should be able to express intent and use essential daily services.

IROA is not another giant all-in-one app. It is a daily-life support foundation that preserves one request state and clear responsibility boundaries even when a request begins by phone, is approved on a watch, runs for hours in a secure execution space, and finishes through a kiosk or a person.

1.2 Core values

Link

1. Completion first: Do not stop at an explanation or search result. Produce a verifiable outcome such as a confirmed booking, accepted order, submitted application, or completed cancellation.
2. User control: The AI assistant does not decide on the user’s behalf. Cost, payment, contract, and sensitive-data transfer require understandable confirmation.
3. Help by choice: When automation is difficult or unwanted, connect naturally to family, volunteers, support workers, institution staff, or store staff.
4. Minimum personal data: Do not centralize a person’s entire identity. Share only what the request needs, with the required execution space, for the required time.
5. Personalized accessibility: Adapt dialogue, screen, confirmation method, and execution order to the person and situation—not only font size.
6. Community participation: Node operators, stores, institutions, volunteers, data contributors, and accessibility evaluators are co-producers entitled to fair treatment and evidence-based rewards.
7. Relationships before technology: Companion AI and robots do not replace people. They connect users to the relationships and help the user chooses.
8. Device independence: A smartphone or personal computer is not required. Phone, watch, kiosk, and companion devices provide equivalent request, approval, cancellation, and outcome channels.

1.3 Project boundaries

Link

• Domain availability and trademark availability are different. Trademark, domain, and similar-service review must be completed before public expansion.
• The IROA token is intended to support Node deployment and operation and reward verified ecosystem contributions. It does not promise a fixed price, fixed return, repurchase, or listing.
• Everyday services use KRW and regulated payment methods such as cards, simple payment, and bank transfer. Essential service access never depends on token ownership.
• IROA does not replace medical diagnosis, treatment, or professional judgment.
• IROA does not promise to predict or prevent unattended death. It supports routine check-ins and faster human connection, and must validate benefits and false alarms in the field.
• Robots act only within staged safety validation. Surveillance, coercion, and uncontrolled physical action are not defaults.

1.4 Product promise

Link

IROA measures whether the request was understood, whether the user knew and approved the cost and data use, whether an external service confirmed the outcome, and whether cancellation, recovery, or human handoff worked after failure. Install count, conversation count, model size, and automation rate are not the primary outcome.

Request → Plan → Choose → Approve → Execute → Verify → Recover or hand off is one lifecycle shared by every access point and execution space.

---

2.0 Say it once, continue anywhere

Link

After saying “Book my hospital visit,” the user should not have to watch a screen. A request may start on the phone, continue with a schedule choice on a watch, run through web booking in a secure execution space, be read back by a companion device, and transfer to a welfare worker when an exception appears. Each access point receives only the data and authority needed for its current step.

2.1 Rehabilitation hospital booking and mobility

Link

A user says, “Book rehabilitation next Tuesday morning and arrange an accessible taxi.” IROA confirms intent, loads only approved preferences, prefers the hospital’s official integration, and otherwise uses an isolated per-request browser. It explains schedule and cost choices, submits only after final approval, coordinates transport, and reports through the user’s chosen channel. Login problems, ambiguous questions, or failed booking trigger a bounded handoff to an approved person.

2.2 Kiosk ordering and payment

Link

A user with hearing and motor impairments starts a session through watch or mobile QR/NFC. The kiosk temporarily applies accessibility preferences, explains suitable options in the right combination of text, image, sign-language video, or speech, and reconfirms item, quantity, price, discount, and refund terms. Payment credentials remain in the regulated payment provider’s approval flow. Personalization data and temporary tokens are deleted when the session ends.

2.3 Companion and staged check-in

Link

The companion supports conversation and routines chosen by the user. A missed response is not immediately classified as danger. IROA retries across permitted channels, waits for the user-defined interval, then sends the minimum help request to selected family, neighbors, volunteers, or institutions. Emergency services are contacted only under a predefined emergency rule or clear immediate danger. The user can stop, change, or delete signals, timing, contact order, and conversation memory.

2.4 Welfare applications and long-running requests

Link

Even without a smartphone or computer, a secure execution space can check current public information and compare only consented fields. It can continue within limited authority after a call ends and report through phone, watch, companion, or an approved helper. IROA distinguishes “possibly eligible,” “application accepted,” and “benefit approved.”

2.5 Booking by phone without a smartphone

Link

The voice assistant explains minimum identity checks without requesting a full resident number, password, or OTP in conversation. If candidates are not immediately available, it calls back after secure execution completes. Final submission follows a clear read-back of time, place, and cost. Text relay, sign-language interpretation, and protected human handoff provide equivalent routes.

2.6 When execution fails

Link

IROA explains where it stopped, clearly marks anything already sent or paid, and offers retry, another channel, or human help. A handoff carries the necessary summary and approved context—not the entire conversation. De-identified failure evidence may improve service and Node quality.

---

3.1 Digital access gap

Link

As Korea becomes a super-aged society, installation, registration, identity verification, complex menus, small targets, timeouts, and payment errors can block access to mobility, health care, food, and welfare. Different disabilities require different interaction and support; a single “large text mode” is not enough. IROA treats the gap as a service-design problem, not merely a lack of user training.

3.2 Limits of current accessibility solutions

Link

Screen magnification, reading, task-specific chatbots, caregiver proxy use, wearable dashboards, staff-call buttons, and document-reading tools are valuable but fragmented. After understanding information, the user still has to cross apps, authenticate again, choose options, pay, and verify the result. IROA joins these pieces into one request execution flow.

3.3 Primary participants

Link

3.4 Differentiation

Link

General assistants provide broad answers but rarely own outcome verification. Accessibility tools improve interfaces but leave cross-service procedures to the user. RPA automates screens but often lacks personal authority and sensitive-data boundaries. IROA combines user-controlled authority, official integrations, isolated execution, result verification, and chosen human help.

3.5 Initial market

Link

IROA begins with a small number of high-frequency, high-friction requests in Korea: booking and changes, accessible mobility coordination, store ordering, welfare preparation, and check-ins. Expansion depends on measured completion, safety, institutional agreements, and sustainable unit economics—not addressable-market claims alone.

---

IROA is a product family that shares request state, identity, consent, and accessibility policy. Users choose the access point suited to the moment without losing request continuity.

4.1 Daily-request AI assistant

Link

The assistant converts a spoken request into a plan containing goals, constraints, services, and approval points. Supported categories may include bookings, accessible transport, ordering, store payment assistance, welfare preparation, hospital visit preparation, routines, helper calls, and cancellation or refund support.

4.2 Personalized accessibility assistant

Link

Settings reflect actual preference and ability: text size and density, speech speed and repetition, touch area and switch input, captions and vibration, sign or pictorial explanation, number of choices, plain language, fatigue-aware simplification, and helper permissions. The user device is the default store; external environments receive minimum temporary settings.

4.3 Human-help network

Link

People participate when a call or field judgment is needed, legal representation is required, or the user chooses not to automate. Roles and information access are granular. Identity and role are verified, and every performed request leaves a reviewable record.

4.4 Companion and check-in assistant

Link

Users set when it may initiate, retry limits, avoided topics, allowed memory, and whom to contact. It supports conversation, chosen routines, scheduled human connection, staged non-response checks, immediate stop and deletion, and explicitly prohibits diagnosis or prediction of unattended death.

4.5 Proof of outcome

Link

IROA distinguishes understanding, search, selection, submission attempt, service receipt, payment approval, final confirmation, and completed cancellation or refund. Where possible, it verifies official API responses, booking identifiers, payment approval, and official notifications.

4.6 Service catalog and responsibility

Link

Each service card states supported country, official integration or screen execution, required identity, confirmation points, expected time and cost, cancellation, human handoff, and retention. Unsupported work is labeled unsupported, under review, or human help available—never disguised as a result.

---

5.1 Automate action, not judgment

Link

5.2 Prefer official connections

Link

IROA prefers published APIs, institutional standards, MCP tools, Apple App Intents, Android AppFunctions, and other official capabilities. When screen execution is unavoidable, it uses an isolated per-request environment, allowlisted domains and actions, separate user confirmation for consequential steps, no central password or payment-key storage, independent outcome checks, and immediate stop or human handoff on failure.

5.3 Respect mobile-platform limits

Link

Mobile operating systems restrict arbitrary cross-app control. IROA uses official deep links, APIs, intents, shortcuts, allowed system features, and safe web flows first, then moves the request to a secure execution space with approval. Experimental platform capabilities are not treated as launch dependencies.

5.4 Explain and cancel

Link

Users can ask what is happening, why an option was selected, which data goes to whom, whether cost occurs, whether the action can stop or reverse, and whether a person can check it. Explanations use plain language appropriate to the user.

---

Mobile provides the richest settings and approval experience but is not mandatory. Identity and consent belong to the user, not a device, and each access point temporarily uses only needed authority.

6.1 Core functions

Link

• Voice, text, photo, and button requests
• Local schedule, preference, and accessibility profile
• Biometric approval for consequential action
• Service-account and permission management
• One-time authority for secure execution spaces and kiosks
• Progress, result, payment, and helper controls
• Data access, deletion, and consent withdrawal

6.2 Work mobile cannot safely complete

Link

Long forms, multi-window bookings, desktop-only systems, hours-long waiting, and large document or model workloads can move to an IROA secure execution space. The approval channel creates a bounded authority containing purpose, sites, expiry, usable information, and forbidden actions.

6.3 Users without mobile

Link

Options include registered phone and voice verification, in-person institutional verification when required, passkeys or one-time QR/cards on watch, kiosk, or companion, spoken request summaries, dual confirmation for payment or contract, and outcomes by call, voice device, paper receipt, or approved helper.

6.4 Guardian mode

Link

Guardian mode is not full account access. Permissions can allow schedule viewing while requiring renewed user approval for a change, or require dual confirmation for payment. Health fields are shared individually, and emergency escalation can be time-limited.

---

7.1 Role of the watch

Link

The watch supports short voice requests, reminders, haptic or spoken approval, kiosk personalization through QR/NFC, permitted daily health signals, helper calls, payment confirmation assistance, and lightweight check-ins. It is not merely a smaller phone.

7.2 Samsung Health and Galaxy Watch

Link

With user consent, selected activity, heart-rate, and sleep information may provide daily context such as fatigue reminders or user-defined safety contacts. Wearable signals are incomplete and do not replace emergency or medical judgment. Responses follow user-defined rules and are framed as checks and contacts, not diagnoses.

7.3 Wearable AI direction

Link

Personalized wearable models are a research direction, not evidence of partnership or clinical validation. Sensor signals are not used as sole grounds for medical diagnosis, automatic payment, or contract.

7.4 Payment and the watch

Link

IROA links secure approval provided by existing wallets, banks, card companies, or regulated payment services. It may show items and amount for confirmation, but IROA, the kiosk, and the execution space do not retain card numbers or payment keys.

---

IROA’s default remote runtime is a resettable secure execution space provided by IROA or an approved operator—not the user’s computer. It supports users without a smartphone or PC and handles long-running or high-compute work.

8.1 Requests that need secure execution

Link

Examples include institutional booking and cancellation, long waiting-list or delivery checks, multi-service comparison, long forms and accessible document conversion, robot-side planning, and approved asynchronous work while a device is disconnected.

8.2 Isolated workspace per request

Link

Each task receives a fresh browser or container and encryption key, allowlisted domains, tools, actions, cost, and time, approved images and updates, remote attestation, restricted logging, and deletion of cookies, temporary files, and keys at completion. Operators cannot access raw conversation, health, or booking data.

A Task Capsule binds seven controls:

1. request declaration with purpose, service, success condition, and expiry;
2. one-time capability limited by domain, tool, action, and cost;
3. credential-vault link using official authentication, passkey, or short token;
4. policy sandbox controlling file, network, message, payment, and transfer;
5. mandatory user-confirmation points;
6. Result Receipt proving booking, submission, or payment outcome; and
7. Deletion Receipt proving disposal of temporary credentials, cookies, and keys.

Receipts do not publish raw personal data. Only non-identifying policy version, runtime state, or integrity proof may be retained where necessary.

8.3 Execution-space types and trust levels

Link

A higher level does not automatically permit more personal data. Purpose, consent, data class, and current attestation must all match.

8.4 Identity, passwords, and OTPs

Link

Execution spaces do not receive full account authority, passwords, or OTPs. Passkeys, OAuth, device or institutional confirmation, and verifiable credentials disclose only the necessary qualification. Payment or legal effect requires confirmation through a separate channel. Automation stops when safe separation is impossible.

8.5 Personal computers are optional

Link

A user may choose local execution for already-authenticated services or private files, but owning, installing, powering, or maintaining a PC is never a condition for IROA access. Local execution runs only an explicitly enabled request and can be disconnected at any time.

8.6 Companion and robot execution

Link

Wake word, accessibility preferences, short conversation, and safety policy should remain on-device where practical. Larger reasoning receives only necessary inputs and one-time authority.

Robotics advances from fixed speakers, displays, kiosks, and telepresence; to bounded mobility trials; and only then to narrowly reviewed physical assistance after safety, insurance, ergonomics, institutional, and field validation. Default face recognition, continuous recording, coercive tracking, unauthorized door opening, object movement, and physical contact are prohibited.

8.7 Data in use

Link

Encryption at rest and in transit is not enough. Sensitive work must also minimize plaintext in memory, isolate processes and operators, constrain debugging and screenshots, rotate keys, and expose deletion and incident evidence. Higher-risk technologies require independent review before production claims.

---

9.1 Execution-oriented kiosk

Link

The kiosk identifies a goal, applies temporary accessibility settings, narrows and explains options, obtains confirmation, invokes regulated payment approval, verifies the receipt or booking, and deletes the session. Staff remain available for exceptions and user choice.

9.2 Adaptation by disability and preference

Link

The flow may change text density, contrast, speech rate, captions, vibration, switch input, touch target, choice count, plain-language confirmation, and time limits. It adapts to actual settings rather than inferring ability from diagnosis alone.

9.3 Why the kiosk can be a Node

Link

A kiosk can serve as an N2 approved access point when identity, device state, software image, data deletion, staff handoff, and output evidence meet published requirements. It receives only per-session authority.

9.4 Reducing store burden

Link

IROA may offer a lightweight software layer for existing hardware, a managed subscription including device and support, or a regional deployment shared by institutions. Store benefits and reward eligibility depend on measured accessibility, uptime, safe help, and verified requests—not installed device count.

---

10.1 Overall structure

Link

The Interaction Plane captures intent and approval. The Control Plane manages request state, consent, policy, trust level, and recovery. The Execution Plane runs isolated Task Capsules through approved Nodes. The Settlement Plane may later reconcile verified B2B service outcomes. Personal data remains off-chain; public evidence is minimal.

10.2 Central-service responsibilities

Link

• Request lifecycle and idempotency
• Consent, policy, trust-level, and service-catalog management
• Node discovery, eligibility, health, and routing
• Minimum evidence, dispute, and audit coordination
• Human-help matching and safe handoff
• Reward calculation and budget controls

The central service does not become a permanent warehouse of passwords, OTPs, payment keys, raw health records, or complete household observation.

10.3 Node responsibilities

Link

Nodes attest their operator, device, software image, security state, allowed data class, region, and service capability; accept only matching Task Capsules; perform bounded work; return outcome and deletion receipts; and support incident containment and revocation.

10.4 Request assignment

Link

Routing considers task risk, data class, required institution or region, accessibility capability, available official integration, Node trust, latency, cost, energy, and human-help availability. The cheapest Node is not automatically selected.

10.5 Data classes

Link

10.6 Failure and recovery

Link

Requests use idempotency keys, bounded retry, checkpoints, external outcome reconciliation, cancellation and refund state, and explicit handoff. A Node failure does not silently become a duplicate purchase or submission.

---

11.1 Technology layers

Link

IROA combines speech and multimodal interaction, task planning, official tool integration, policy enforcement, isolated browser execution, outcome verification, accessibility adaptation, human handoff, and Node attestation. No single model is trusted to enforce every boundary.

11.2 Model selection

Link

Models are selected by task, language, latency, device, cost, privacy, and error profile. Small local models can handle wake words and simple classification; stronger hosted or managed models may plan complex work after minimum-data filtering. Critical approval, policy, and outcome checks use independent rules and service responses.

11.3 External-service connections

Link

Official APIs and standards come first, tool contracts validate input and output, and screen execution is isolated and monitored. Each integration publishes supported actions, permission requirements, failure behavior, and evidence quality.

11.4 Starting with limited capital

Link

IROA begins with existing models, open standards, regulated payments, a small catalog of high-value requests, managed cloud isolation, and institution-led pilots. It does not begin by training a foundation model, replacing hospital records, manufacturing a general robot, or building an unrestricted automation platform.

11.5 Research and development scope

Link

Priority research includes disability-specific interaction, plain-language generation, robust outcome verification, prompt-injection resistance, capability security, remote attestation, deletion proof, on-device companion and wearable models, robot stop policy, accessibility evaluation, and privacy-preserving learning. Research claims remain separate from deployed capability.

---

12.1 Connect authority, do not collect everything

Link

IROA stores on user devices what can remain there and shares only minimum fields temporarily for execution. More data is not treated as automatically better intelligence.

12.2 Privacy principles

Link

• State purpose before requesting data.
• Default to private and minimum sharing.
• Prefer user vaults, local devices, or approved institutions for sensitive information.
• Delete task data after use and separate learning consent from service consent.
• Do not unfairly restrict service after learning-data refusal.
• Do not retain raw conversation, screen, or health data indefinitely.
• Separate personal data from reward records.
• Support access, correction, deletion, portability, and withdrawal.

12.3 One-time task authority

Link

Purpose: book rehabilitation at Hospital A
Allowed site: hospital.example
Allowed actions: view times, create booking candidates
Forbidden: payment, other departments, record download
Data: name, last digits of phone, preferred date
Expiry: 15 minutes
Final submit: separate registered approval channel required

Authority is signed, scoped, and disposed after use. Verifiable credentials should disclose only needed facts. Failed remote attestation prevents assignment of sensitive work.

12.4 Risks of agentic execution

Link

External content is never treated as user instruction. IROA separates request from content, validates tool input and output, stops on privilege expansion, independently controls upload, download, and messaging, checks consequential outcomes, and quarantines anomalous Nodes.

12.5 Rewards and personal data

Link

Raw health, disability, conversation, voice, video, location, identity, account, and household robot observations are never written to a blockchain or public ledger. Reward integrity uses pseudonymous qualification, outcome or dispute status, minimum calculation data, policy version, and qualification revocation state.

12.6 Security operations

Link

Operations include updates, vulnerability response, device enrollment and disposal, hardware-backed keys and rotation, anomalous login, request and reward detection, breach response and notice, independent assessment, and responsibility contracts for hospital, payment, and public integrations.

---

13.1 Integration stages

Link

1. information and visit preparation;
2. booking, change, and cancellation through official routes;
3. mobility, check-in, questionnaire preparation, and helper scheduling;
4. field-level consent for personal health information; and
5. standards-based institutional integration after contract and security review.

13.2 MyHealthWay and KR Core

Link

IROA may help a user understand and select information from national or institutional health-data services. Standards such as HL7 FHIR and KR Core do not themselves create access authority. Contract, legal basis, security review, consent, and clinical workflow are also required.

13.3 Medical boundary

Link

IROA may assist with booking, visit preparation, plain-language explanation of user-held material, questions for clinicians, reminders, chosen daily summaries, and contact after an unusual signal. It must not independently diagnose disease, change prescriptions, decide emergencies alone, impersonate clinicians, transmit health data secretly, or expose sensitive data for insurance or employment.

13.4 Shared value for hospitals

Link

Potential value includes fewer repetitive booking calls, better visit preparation, advance accessibility needs, plain-language intake, coordinated mobility and support, and teach-back assistance. Initial work begins around booking and access rather than replacing core clinical systems.

---

14.1 Lived experience is a design resource

Link

Older adults and people with disabilities are co-designers, not data sources. Feedback about difficult steps, understandable explanations, and assistant errors is central to accessibility quality.

14.2 Data that may be contributed

Link

Examples include user-submitted preferences, success and failure stage, explanation rating, consented simulated interaction, alternative plain language, Node delay and error, handoff outcome, companion retry and false alarm, robot safety stop, and de-identified usability evidence.

14.3 Prohibited or tightly restricted data

Link

IROA avoids continuous collection of complete conversation, passwords, OTPs, payment credentials, unconsented health, disability, location or face data, continuous household audio or video, unapproved companion memory, continuous robot-sensor upload for reward, clinical records for general model training, and private user-helper conversation.

14.4 Consent and compensation

Link

Learning and evaluation consent is separate from core service. IROA explains content, purpose, original versus summarized form, retention, deletion, reward, and limits after withdrawal. Financial vulnerability must not be exploited to induce excessive disclosure.

14.5 Learning strategy

Link

Use public accessibility data and synthetic data first; collect lived-experience data minimally and separately; prefer on-device evaluation, federated learning, and privacy-preserving statistics; measure by disability, device, and request; and evaluate comprehension, completion, and handoff—not accuracy alone. Refusing data contribution does not block essential service.

---

IROA rewards contribution to safe, accessible completion—not raw compute consumption.

15.1 Eligible contribution

Link

Eligible roles include managed, community, institutional, and specialist Node operators; stores providing AI kiosks; volunteers and qualified support workers; older and disabled accessibility evaluators; separately consenting data contributors; institutions and developers providing integrations; and contributors who identify and verify security or operational errors.

15.2 Node reward criteria

Link

Actual service fees in KRW or other regulated payment methods are the primary funding for Node operating cost and professional services. IROA tokens supplement them as performance rewards.

Node reward
= availability
+ verified request success
+ accessibility quality
+ appropriate human handoff
+ security attestation and deletion compliance
+ regional service contribution
- failure, duplication, and delay penalties
- security and privacy violation penalties

Evaluation includes outcome proof, latency and long-running stability, cancellation and complaint rates, correct accessibility settings, attestation and minimization, deletion receipts, energy efficiency, and handoff quality. Increasing compute or conversation time does not itself earn rewards.

15.3 Store and kiosk rewards

Link

Eligible evidence may include certified availability, successful accessible orders or bookings, actual staff support, local public access, and consented quality evaluation. User, payment, and outcome evidence and anomaly detection reduce self-generated fake requests.

15.4 Volunteers and helpers

Link

Not all help is assumed to be unpaid. Expenses, activity fees, local currency or points, recognized volunteer time, education and reputation, and formal professional fees may be combined according to expertise, duration, travel, responsibility, and risk. Qualified domains such as medicine, law, and finance are limited to verified professionals or institutions.

15.5 Reward disputes

Link

Payment is not removed solely by an automated score. Users and operators can appeal, material penalties receive human review, evidence and policy version are disclosed, and slower work caused by disability is not misclassified as poor quality.

---

The priority of the token economy is sustainable real-world service, not token price. The token supports Node deployment and operation, verified participation, and research and development. Node operators rely primarily on service fees in KRW or regulated payment methods; tokens are performance rewards. Users do not need tokens for booking, mobility, ordering, check-ins, or other essential functions.

16.1 Supply principles and token roles

Link

• Maximum supply is fixed at 10,000,000,000 IROA, with no additional issuance.
• Nodes earn performance rewards after verified completion and compliance with availability, security, deletion, and accessibility requirements.
• Users, helpers, evaluators, institutions, hospitals, stores, and local access points share one ecosystem-participation pool.
• Research allocation funds accessibility AI, secure execution, robot safety, privacy technology, and field validation.
• There is no promise of fixed price, fixed return, principal protection, repurchase, exchange listing, or appreciation.
• Safety, privacy, cancellation rights, and essential access cannot be limited by token holdings or voting power.

16.2 Token allocation

Link

Node, ecosystem, and R&D receive 63%. Ecosystem participation uses one managed pool rather than many small participant-specific pools. Payment basis and use by participant category are disclosed quarterly.

16.3 Initial circulation and vesting

Link

Baseline cumulative circulation is 2.0% at launch, 11.3% at year 1, 63.6% at year 5, and 98.5% at year 10. Team and investor allocations do not circulate at launch. Their maximum combined monthly unlock is spread to remain at or below 1.98% of the previous month’s cumulative circulating supply.

16.4 Node reward model

Link

Node token reward
= verified request completion
+ availability and response
+ accessibility and quality
+ security proof and deletion compliance
- failure, duplication, and delay penalties
- fake-work, security, and privacy penalties

Registering a Node or leaving equipment on does not create fixed returns. Result Receipts, cancellation and disputes, disability-specific quality, security state, and real service use are evaluated together. Fake requests and inflated Node counts can cause reward holds, suspension, and clawback.

In the 12-year stress test, the simple average token amount per Node declines sharply as the fixed pool is shared across more Nodes. In the baseline scenario, the year-12 average is approximately 1/1,083 of the year-1 average. Token emissions alone therefore cannot guarantee server, electricity, connectivity, or security-staff cost. If request fees and institutional contracts do not grow, new Node expansion slows and reward rates are recalculated.

16.5 Ecosystem and R&D execution

Link

One ecosystem pool covers users, helpers, accessibility evaluators, institutions, and local access points. Rewards depend on verified completion, accessibility improvement, safe handoff, field operation, and error discovery—not personal-data volume or time spent. Qualified professional help is restricted to verified professionals or institutions.

R&D priorities are disability-specific accessibility and plain language; Node isolation, attestation, minimization, and deletion proof; recovery, duplicate prevention, and outcome verification; on-device wearable, companion, and robot safety; standards-based hospital, welfare, and public integration; independent security audit, privacy impact assessment, and co-evaluation with affected users.

16.6 Financial and governance controls

Link

Team, investor, and foundation wallets, schedules, and execution records are disclosed. Foundation and R&D budgets use multisignature control, annual budgets, staged payment, and quarterly disclosure. Conflicted decision-makers recuse. Smart contracts and reward formulas receive independent security audit. Securities, virtual-asset provider, tax, accounting, user-protection, and privacy questions receive separate review before issuance or circulation. Features lacking legal, security, and accounting clearance are not deployed publicly.

16.7 Simulation validation results

Link

This baseline validates token quantities and unlock structure. It does not predict price, return, listing, exchange rate, or Node profitability. During operation, actual request volume, service revenue, Node cost, reward concentration, sell pressure, and reserve depletion are recalculated quarterly.

---

17.1 Revenue sources

Link

Potential revenue includes institutional AI and accessibility subscriptions; hospital, welfare, and municipal implementation and operation; kiosk subscription or lease; companion operation; secure-execution request and usage fees; lawful booking or ordering partnerships; Node management, security, and quality assurance; public digital-inclusion and corporate social contribution programs; and accessibility evaluation and consulting.

IROA does not accept hidden recommendation fees. Economic interests are disclosed and user suitability comes first.

17.2 Stakeholder value

Link

17.3 Store and institution adoption

Link

Adoption models include a lightweight layer on an existing kiosk or PC, a managed subscription including equipment and support, a regional shared deployment, standards-based institutional integration, and a companion access point operated by a welfare institution with voice, display, telepresence, and human connection.

17.4 Social outcome metrics

Link

Metrics include request completion, safe human handoff, reduction in manual steps, booking or application time, failure gaps by disability, comprehension and control, staff calls, Node cost and reward balance, privacy incidents, check-in success and connection time, false alarms and deletion requests, and robot safety stops or near misses.

---

Timing adjusts to funding, institutional cooperation, and regulatory review. Each phase is evidence for deciding whether to fund the next.

Phase 1 · Months 0–3: Daily requests and initial companion

Link

Build conversational mobile, web, and phone access; two or three simulated or public-service connections; accessibility profiles; regulated payment approval links; failure and handoff; user-configured conversation and contact order; and small co-design sessions.

Entry criterion: users can express the goal and verify outcomes in simulated requests.

Phase 2 · Months 4–6: Secure execution space

Link

Build managed isolated browsers, encrypted workspaces, one-time authority, approval across channels, passkey and attestation pilots, long-running booking checks, outcome proof, and deletion receipts.

Entry criterion: complete bounded booking and change requests without a personal PC, duplicate action, or residual sensitive data.

Phase 3 · Months 7–10: AI kiosk field trial

Link

Build a lightweight kiosk prototype, QR/NFC session, disability-specific personalization, pre-payment confirmation, staff call, automatic deletion, and trials at two to five sites.

Entry criterion: improve completion for accessibility users while reducing store burden.

Phase 4 · Months 11–14: Companion, community Nodes, and rewards

Link

Operate N0–N4 trust levels, fixed companion and telepresence trials, community and specialist Nodes, quality measurement, check-in and false-alarm measurement, KRW fees plus performance-token trials, helper matching, and disputes.

Entry criterion: demonstrate per-request revenue and cost without privacy violations.

Phase 5 · Months 15–20: Institution links and mobile-robot research

Link

Run booking and visit-preparation trials, review MyHealthWay, FHIR, and KR Core, apply field-level health consent, assess institutional privacy and security, and research bounded telepresence and mobility under safety, insurance, ergonomics, and physical-stop review.

Entry criterion: agree legal and technical responsibility and validate safety in a real workflow.

Phase 6 · Month 21 and beyond: Safe robotics and service stability

Link

Expand only after external Node-security audit, accessibility governance, token-contract and reward audit, long-term token-economy validation against real revenue and Node cost, and safety, regulatory, insurance, and field evidence for any physical assistance.

Not prioritized initially

Link

IROA will not initially build its own foundation model, diagnostic medical AI, full hospital-record replacement, its own stablecoin, unrestricted mobile-app control, face-recognition personalization, continuous household recording, unattended care replacing people, or physical-contact robotics before safety validation.

---

19.1 User rights

Link

Users can stop AI action, choose human help, access, correct, or delete data, refuse learning contribution, understand recommendation and reward criteria, report accessibility or discrimination, and challenge automated decisions.

19.2 Accessibility advisory structure

Link

No single expert represents every disability. Governance includes people with different disabilities, older users, families and support workers, accessibility specialists, health and welfare practitioners, privacy and security specialists, stores, and Node operators. Their views inform priorities, collection, rewards, and major incident response.

19.3 Node governance

Link

Operator identity and equipment are verified against public quality and security criteria, periodic recertification, restriction, reward holds, and removal. Operators have appeal and recovery paths. Regional diversity reduces concentration among a few large operators.

19.4 Algorithmic accountability

Link

IROA reports performance and failure by disability, discloses recommendation fees and commercial interests, preserves high-risk policy history, does not blame users for automation failure, and performs accessibility regression review before material model change.

---

20.1 When automation must stop

Link

Stop when intent is unclear and cost or legal effect may occur; unrequested data transfer is required; a site asks for greater authority or outside contact; results cannot be verified and duplication is possible; medical, legal, or financial judgment is required; the user expresses anxiety, confusion, or refusal; a companion lacks grounds to interpret non-response; or robot sensing, braking, or connectivity falls outside safety limits.

---

This document sets service, technology, business, and token-economy principles. Production service, token issuance, or investment communication requires separate validation.

21.1 Legal and regulatory

Link

Review privacy and sensitive data; disability discrimination and accessibility; electronic finance and payment boundaries; medical and health-data law; robot product liability, safety, insurance, and household recording; e-commerce, consumer protection, and agency; volunteer and labor compensation; and token securities status, virtual-asset provider obligations, user protection, tax, accounting, and advertising.

21.2 Technology

Link

Validate actual mobile-platform permissions, site terms for screen execution, Node isolation and updates, remote attestation and deletion effectiveness, passwordless recovery, institutional API authority, wearable accuracy and battery, on-device robot latency and safe stop, and independent audits of token contracts, vesting wallets, multisignature, and reward formulas.

21.3 Business

Link

Validate the three highest-frequency requests, affordable store subscription, kiosk electricity, connectivity and support cost, institutional procurement cycles, helper supply and quality cost, per-request profitability funded by KRW fees, Node cost, reward concentration, demand, quarterly sell pressure, reserve depletion, and whether companion or robot access is better leased or institution-operated.

21.4 Validation with affected users

Link

Measure completion by disability, understanding of action and cost, use without guardian support, timeliness of handoff, comprehensible privacy consent, sufficiency of KRW fees and performance rewards for long-term participation, effects and false alarms of companion interaction, and request, approval, cancellation, and outcome access without a smartphone or PC.

---

IROA.AI is not one more screen. It is a daily-life foundation that responsibly connects a request begun by phone, mobile, watch, kiosk, companion, or robot to long-running secure execution, official hospital and welfare integration, human help, and a verified real-world outcome.

Older adults and people with disabilities are co-designers and evaluators. Store and community Node operators, families, support workers, volunteers, and institutions enable execution. IROA assigns 63% of total supply to Nodes, ecosystem participation, and R&D to support verified contribution and long-term technology while placing privacy and self-determination ahead of cost reduction or automation rate.

Success is measured by completed daily requests, not model size or investment expectation. The question is whether a user who says “book it,” “help me travel,” “talk with me today,” or “connect me to a person” reaches a safe and understandable real-world outcome regardless of personal-computer ownership. Companion and robot value lies in connecting the user to chosen relationships and help—not replacing people.

This whitepaper is not an investment solicitation or medical, legal, or tax advice. The token economy is a baseline simulation of supply and vesting, not a price or profitability guarantee. Issuance and operation proceed only within completed legal, security, accounting, and business validation.