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

NODE NETWORK

A NODE is an execution space verified per request.

Who operates a NODE, which trust level handles which request, and how verified work becomes a reward — explained from the whitepaper and the pilot design.

NODE registration, settlement, and rewards on this page are a design under validation in a private pilot. There is no open registration, sale, yield, or listing promise, and the network-state figures show only values read from the chain after a deployment manifest is published.

What a NODE is

Current

A NODE is a secure execution space that carries out one user-approved request within bounded authority. Every task gets a fresh isolated environment and its own encryption key, and moves only within the allowed domains, tools, actions, cost, and time.

No NODE controls the entire request. Planning, credential use, and outcome verification sit behind separate boundaries, and moving to a higher-risk step requires a newly issued, narrower capability.

The per-request protection bundle (Task Capsule) a NODE receives

  1. Request declaration — purpose, target service, success condition, and expiry
  2. One-time capability — task authority limited to allowed domains, tools, actions, and cost
  3. Credential vault link — official auth, passkeys, or short tokens instead of raw passwords
  4. Policy sandbox — independent control of file, network, messaging, payment, and personal-data transfer
  5. User confirmation points — steps such as payment, contracts, or sensitive data where execution must stop
  6. Result Receipt — the booking number, intake response, or payment approval that proves success
  7. Deletion Receipt — the record proving temporary credentials, cookies, and task keys were destroyed

Trust levels N0–N4

Current

A higher level does not mean automatic access to more personal data. Request purpose, user consent, data class, and the execution space’s current attestation must all be satisfied.

LevelExamplesAllowed requests
N0 public computeVerified de-identified compute poolPublic information and synthetic or de-identified processing
N1 managed executionIROA secure space or registered operatorLow-risk isolated web tasks and long tracking
N2 approved access pointKiosk, welfare center, companionBooking, ordering, bounded identity, human connection
N3 institutionHospital, municipality, welfare institutionSensitive work within contract and qualification
N4 personal approvalWatch, mobile, passkey, in-person checkCredential use and final approval

The owner of an execution space and the identity and state of the actual runtime are verified separately. The table matches whitepaper §8.3.

What an operator does

In validation

A NODE operator registers a NODE with a device key, runs tasks under the current policy version once approved, and proves results and deletion. There is no open registration.

  1. Create a device key

    A NODE device key is created apart from the operator wallet, and the NODE ID is derived from the key hash. The registration carries the device key’s signature, so only whoever holds the key can register its hash.

  2. Register

    The registration is recorded as Pending and receives no tasks yet.

  3. Qualification and approval

    A compliance role that has checked the operator’s qualification and trust level must approve the NODE before it becomes Active. The trust level can be adjusted later as the attestation state changes.

  4. Heartbeat

    An active NODE periodically reports its agent version, policy version, and spare capacity under its signature.

  5. Run tasks

    Requests run inside the Task Capsule scope and stop at every user confirmation point.

  6. Prove results and deletion

    A Result Receipt and a Deletion Receipt are left behind. Both must verify for the reward score to pass its security gate.

Suspension and revocation are executed by separate roles, and a leaked device key is revoked on its own while the NODE ID is kept.

Reward structure

In validation

NODE operating cost rests on real service fees; IROA tokens are a performance reward for verified work, availability, security, and quality alongside them. Registering a NODE or leaving equipment on does not create fixed returns.

Node build and operation reward allocation

2,500,000,000 IROA

of the 10,000,000,000 IROA maximum supply · whitepaper §16.2

Node token reward (whitepaper §16.4)

  • 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

Task score weights (pilot design §7.2)

  • Result quality40%
  • Accessibility quality25%
  • Timeliness15%
  • Human handoff quality10%
  • Resource efficiency10%
  • The completion gate and the security gate are 0 or 1. The security gate is 1 only when both the Result Receipt and the Deletion Receipt verify.
  • The uptime bonus stays within 10% of the verified task score and is never paid to a NODE with no tasks.
  • Scores of several NODEs are summed per operator, and one operator’s monthly reward stays within 5% of that month’s NODE budget. The excess stays in the NODE vault rather than being redistributed.
  • Self-dealing, duplicate requests, false completion, signature errors, policy mismatch, missing deletion, and disputed tasks are excluded from or held out of rewards.

More NODEs means a smaller average reward

Current
Average token reward dilution as the number of Nodes grows

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.

Whitepaper §16.4 · 12-year simulation

Network state

Current

Figures here show only values read from the contracts named in a signed deployment manifest. Until a manifest is published, only the structure is shown.

Network
Base
Release
v1
  • Active NODEs—Counts Active status only; pending registrations are excluded.
  • Trust-level mix—N0–N3 composition of active NODEs. N4 is a personal device and is never registered.
  • Finalized epochs—Monthly settlement roots finalized after the challenge window
  • Last settlement finalized—Block time of the most recent RootFinalized
  • Reward claims—Count only; amounts are never summed on this page.
Active NODEs per trust level and finalized epochs

Reading from the chain.

Activity

  1. Reading from the chain.

Pilot stages

NODE registration through Result Receipts, disputes, and reward claims is validated end to end on mainnet with private participants, then passes an independent audit and the V2 migration. No dates are promised; only entry criteria are published.

  1. Local and Base Sepolia complete

    In validation
    Outcome
    Contracts, verifier, and operator portal run as one flow on the testnet
    Entry criteria
    Module review/fix and final integration validation pass

  2. V1 issued on Base mainnet

    Planned
    Outcome
    10 billion IROA V1 issued, seven vaults reconciled, Safe and Timelock handoff
    Entry criteria
    Deployment artifact, Safe, Timelock, and legal scope confirmed

  3. Private participant validation

    Planned
    Outcome
    Only approved participants operate NODEs, receive, and transfer
    Entry criteria
    V1 address verified, vaults reconciled, allowlist operations ready

  4. Independent smart-contract audit

    Planned
    Outcome
    Real V1 addresses and operating evidence submitted to the auditor
    Entry criteria
    Audit scope and migration code submitted

  5. V2 deployment and 1:1 migration

    Planned
    Outcome
    V2 minted for exactly the V1 burned; total supply stays at 10 billion
    Entry criteria
    Audit must-fix items applied and migration rehearsal passed

Throughout the pilot there is no public sale, DEX liquidity, bridge, third-party custody, or listing.

Operator participation

Planned

Operating a NODE is a matter of qualification and approval, not open registration. Discussions start from the following.

  • A NODE device key separate from the operator wallet (hardware security module recommended)
  • An execution environment and remote attestation matching the trust level to be served
  • Operator qualification check and consent to the private pilot
  • Adherence to the policy version, submission of result and deletion receipts, and participation in the dispute process

Operator contact channel in preparation

No personal data is collected before an official contact channel is in place.

What this page does not promise

  • No promise of price, yield, liquidity, or exchange listing.
  • Verified contribution is reviewed together with dispute, cancellation, and quality criteria.
  • Holding tokens is never a condition for essential support.
Read the token economy chapterSee the reward structure in Q&A

Every section describes the project’s design as of this page’s publication and is not a service or reward guarantee.