NODEA Protocol

1.1 The name

NODEA combines “node” and “idea.”

A node is a point of connection within a network. An idea is the starting point of a product, protocol, or community. NODEA represents the point where a project idea meets the infrastructure, participants, and explicit rules required for a token launch.

1.2 Vision

NODEA’s vision is a token-launch market in which material terms are published before commitment, access rules are consistently calculated, and post-sale actions follow an inspectable process.

1.3 Mission

NODEA’s mission is to build practical launch infrastructure for Robinhood Chain that:

• gives serious teams a structured route to market;
• gives participants clearer information and deterministic eligibility;
• aligns access with longer-term commitment;
• makes token distribution schedules visible;
• separates protocol safeguards from unrealistic promises of safety.

2.1 Fragmented information

Launch terms are often distributed across multiple channels and revised without a clear record. Participants may struggle to determine which version is current, who controls the contracts, how tokens are allocated, or when supply becomes transferable.

2.2 Opaque allocation

When allocation rules are not disclosed precisely, participants cannot reliably estimate eligibility or understand why one wallet received more than another. First-come systems may favor speed and automation. Unspecified discretionary allocation creates a different kind of uncertainty.

NODEA is intended to require each launch to publish its eligibility method, tier rules, caps, allocation method, and oversubscription treatment before commitment begins.

2.3 Misaligned unlocks

Immediate or poorly disclosed token unlocks can create sharp changes in circulating supply. The same concern applies to participant allocations, team tokens, advisor tokens, ecosystem reserves, and liquidity provisions.

Vesting cannot guarantee price stability. It can, however, make the timing of token distribution visible and reduce ambiguity about when different allocations become transferable.

2.4 Unclear recourse

Some launches provide no defined process if a sale is cancelled, a minimum condition is not met, or a participant decides not to claim under an offered refund option. Others describe a refund informally without specifying eligibility, timing, deductions, or the contract that controls the funds.

NODEA is designed to make claim and refund conditions launch-specific, explicit, and visible before participation.

2.5 Review misunderstood as a guarantee

Review can identify inconsistencies, missing disclosures, administrative risks, and technical concerns. It cannot predict every failure or prove that a project will succeed.

NODEA therefore treats review as a structured information and risk process—not as insurance, investment advice, certification, or an endorsement.

3.1 Disclose before commitment

Material launch terms should be available before funds are committed. A participant should not need to infer the token price, allocation method, vesting schedule, claim conditions, or administrative controls.

3.2 Make rules deterministic where possible

Tier qualification and effective NODEA should be calculated from published values. Contract state and transaction events should make the result inspectable.

3.3 Reward duration, not speed

NODEA uses time-based lock multipliers so that access depends on the amount and duration of committed NODEA, rather than on page-refresh speed or a separate collectible.

3.4 Separate access from returns

A lock multiplier changes the effective NODEA used for tier calculation. It is not an interest rate, APY, token reward, revenue share, or guarantee of an allocation.

3.5 Align distribution with disclosed schedules

Participant, team, and other material token allocations should follow schedules published before the launch. Any exceptions or administrative powers must also be disclosed.

3.6 Design security in layers

Smart-contract review, testing, access control, monitoring, operational procedures, and incident response each address different risks. No single measure makes a launch safe.

3.7 State uncertainty honestly

Draft values should be labeled as draft. Undeployed functionality should be described as intended. Unknown information should remain unknown rather than being replaced with a marketing claim.

5.1 Project teams

Project teams apply to launch, provide information, define proposed launch terms, deploy or identify token contracts, fund required distribution contracts, and remain responsible for their statements and obligations.

Listing on NODEA does not transfer responsibility for a project from its team to the protocol.

5.2 Participants

Participants review the published terms, evaluate risks, lock NODEA when they choose to seek tier access, and decide whether a specific launch is appropriate for them.

Tier eligibility is not a recommendation to participate.

5.3 Review function

The review function assesses submitted materials against a documented checklist. It may request changes, identify unresolved risks, or decline a launch.

The scope, reviewer identity or entity, conflicts policy, and limitations of review should be disclosed before public activation.

5.4 Protocol operations

Protocol operations may initially manage launch configuration, administrative workflows, incident response, and approved contract actions. These powers must be limited, documented, and visible.

Any multisignature requirements, timelocks, emergency controls, or upgrade permissions will be published with deployed contract documentation.

5.5 Smart contracts

Smart contracts are intended to calculate or enforce the portions of a launch that can be expressed deterministically, including staking state, tier snapshots, commitments, allocations, claim state, refunds where enabled, and vesting.

Contracts can enforce coded conditions. They cannot verify every offchain statement made by a project or eliminate external legal and operational risk.

6.1 Review areas

6.2 Possible outcomes

A review can result in:

• Proceed — the launch may advance to term publication, subject to remaining conditions.
• Revise — additional information, changes, or evidence are required.
• Decline — the launch will not be listed in its submitted form.

NODEA should retain an internal record of material review decisions and publish the participant-facing findings or limitations appropriate to each launch.

6.3 Review limitations

Information can be incomplete, inaccurate, outdated, or deliberately misleading. Audited code can still contain defects. Identified contributors can fail to execute. Legal treatment can change.

7.1 Application

The project submits structured information and supporting material. Required fields should be versioned so that material changes can be identified.

7.2 Review and remediation

NODEA evaluates the submission, records questions, and requests remediation where appropriate. Open issues that are accepted rather than resolved should be disclosed as risks.

7.3 Term publication

Before commitments open, NODEA publishes the final launch configuration, material disclosures, and relevant contract addresses. A material post-publication change should trigger a visible revision notice and, where required by the launch rules, a renewed consent or cancellation process.

7.4 Eligibility snapshot

The protocol records the staking information used for the launch. The snapshot should identify:

• eligible wallet;
• locked NODEA;
• selected lock duration;
• applicable multiplier;
• effective NODEA;
• resulting tier;
• snapshot block or timestamp.

The exact snapshot method must be published before registration closes.

7.5 Commitment

Eligible participants commit under the published minimums, maximums, accepted assets, timing, and jurisdictional restrictions. A transaction should display the relevant amount and terms before signature.

7.6 Finalization and allocation

After the commitment window closes, the launch is finalized according to its disclosed success conditions and allocation method. Oversubscription treatment, unused capacity, rounding, and rejected commitments must be handled under the published rules.

7.7 Claim or refund

If the launch includes a participant decision window, an eligible participant chooses the available action before the deadline. Claiming and refunding the same allocation must be mutually exclusive.

7.8 Vesting and reporting

Claimed tokens enter the published distribution schedule. The interface should show claimed, vested, claimable, and remaining balances alongside the next scheduled unlock.

9.1 Required disclosure

Where a refund option exists, the launch terms should identify:

• who is eligible;
• what event or choice activates eligibility;
• when the window opens and closes;
• whether the option applies before or after final allocation;
• which asset is returned;
• whether network costs or disclosed fees are deducted;
• whether partial refunds are possible;
• what happens to the associated token allocation;
• which contract holds and releases the funds;
• what happens if a transaction is submitted near the deadline.

9.2 Participant state

The interface should show one clear state for each allocation:

• action not yet available;
• claim available;
• refund available;
• claimed;
• refunded;
• expired;
• cancelled.

9.3 Mutual exclusivity

If a participant claims the allocation, the related refund right should be consumed. If a participant completes an eligible refund, the associated allocation should be cancelled. The contract must prevent both outcomes from being executed for the same commitment.

9.4 Limitations

A refund mechanism introduces its own contract, liquidity, deadline, network, and operational risks. It should not be described as deposit insurance or a guarantee that all losses can be recovered.

10.1 Reference participant model

NODEA’s reference model is:

This is a reference configuration. A launch may use a different split only when the exact schedule is published before commitment.

10.2 Team and related allocations

Team, founder, advisor, treasury, ecosystem, market-making, and other material allocations should be disclosed with the same clarity expected for participant vesting.

Where those allocations are contractually vested, the interface should expose the contract, beneficiary class, start time, cliff, duration, release cadence, and any administrative powers.

10.3 What vesting can and cannot do

Vesting can make the timing of token availability more predictable and can limit immediate circulating supply. It cannot guarantee market depth, price stability, project execution, or aligned behavior after tokens unlock.

11.1 Effective NODEA

Effective NODEA = locked NODEA × lock multiplier

Only effective NODEA is compared with the tier thresholds.

The multiplier is an access-weighting factor. It does not represent APY, interest, a staking reward, revenue share, or a guaranteed financial return.

11.2 Lock positions

Before staking is activated, the production documentation must specify:

• when a lock begins;
• whether a position can be extended;
• whether additional NODEA can be added;
• how multiple positions are treated;
• whether delegation is supported;
• whether early unlock is impossible or subject to a defined rule;
• how an expiring lock affects registration and launch eligibility;
• how snapshots handle transactions in the same block.

Until those rules are implemented and reviewed, the interface must label staking parameters as working specifications.

13.1 Approximate locked NODEA required

The following table shows the approximate locked balance needed to reach each threshold at each duration. Values may require rounding up to the token’s supported precision.

13.2 Snapshot rules

Tier qualification should use a published snapshot block or timestamp. The production rules must explain how positions created, extended, transferred, or expired around the snapshot are treated.

Changes after a snapshot should not retroactively alter a finalized allocation unless the launch terms explicitly define a correction process.

14.1 Permitted launch configurations

A launch may use:

• a tier-specific maximum allocation;
• proportional allocation within an eligible pool;
• separate pools for different tiers;
• a hybrid of tier ceilings and proportional distribution;
• another method that is fully specified and technically enforceable.

The method must be published before commitments open.

14.2 Reference proportional calculation

For a launch that explicitly chooses proportional weighting, a reference calculation is:

Participant weight = participant effective NODEA ÷ total effective NODEA of the eligible pool

Pre-cap allocation = allocatable pool × participant weight

The launch then applies its disclosed wallet cap, tier ceiling, minimum allocation, and rounding rules.

This reference formula is not mandatory for every launch. The controlling method is the one published in that launch’s final terms and implemented by its contracts.

14.3 Oversubscription

Every launch should state:

• how oversubscription is detected;
• whether unused capacity moves between tiers;
• how rounding remainders are handled;
• when excess committed funds become withdrawable;
• whether a minimum successful raise applies;
• what happens if the launch does not meet its success conditions.

16.1 Project registry

Records approved launch identifiers, published metadata references, responsible addresses, and active status.

16.2 Staking and lock manager

Records locked NODEA, lock duration, multiplier, effective NODEA, and unlock eligibility.

16.3 Tier snapshot module

Determines the tier state used by a specific launch at its published snapshot.

16.4 Launch configuration

Stores controlling parameters such as timing, accepted asset, caps, allocation method, claim conditions, vesting reference, and administrative roles.

16.5 Commitment and allocation

Accepts eligible commitments and calculates or records final allocations under the launch method.

16.6 Claim and refund module

Tracks mutually exclusive claim and refund state where the launch enables those actions.

16.7 Vesting module

Releases token allocations according to the published cliff, start, duration, cadence, and beneficiary terms.

16.8 Treasury and fee routing

Routes project proceeds and any disclosed protocol fees only after the relevant launch conditions are met. The production fee model has not yet been finalized and must be published before activation.

16.9 Administrative controls

Any ability to pause, upgrade, cancel, recover, configure, or move assets is a security assumption. Production documentation must identify:

• which role has each permission;
• whether the role is a multisignature;
• signature threshold and signer policy;
• whether a timelock applies;
• the events emitted by an administrative action;
• the process for rotating or removing authority.

17.1 Contract assurance

Before handling production funds, relevant contracts should undergo:

• unit and integration testing;
• invariant and fuzz testing where appropriate;
• testnet exercises of success and failure paths;
• independent security review;
• remediation and verification of material findings;
• source-code verification for deployed contracts.

An audit reduces specific risks at a point in time. It does not guarantee that a contract is free of defects.

17.2 Priority threat areas

The review should explicitly consider:

• reentrancy and unsafe external calls;
• role and access-control errors;
• upgrade and initialization mistakes;
• incorrect tier boundary calculations;
• rounding and token-decimal errors;
• snapshot manipulation;
• duplicate claims or refunds;
• insolvency or missing distribution inventory;
• denial of service at deadlines;
• fee-on-transfer or nonstandard token behavior;
• timestamp and block assumptions;
• signature replay and frontend transaction substitution;
• compromised administrative keys;
• dependency and network failures.

17.3 Operational security

Production operations should use documented key custody, least-privilege access, change review, deployment checklists, monitoring, alerting, and incident procedures.

17.4 Incident response

Before activation, NODEA should publish:

• security contact and reporting method;
• severity classification;
• emergency decision authority;
• criteria for pausing affected functions;
• participant communication process;
• post-incident disclosure and remediation process.

17.5 Participant security

The interface should clearly show the selected network, contract being called, token amount, approval scope, and expected transaction. NODEA should never ask for a seed phrase or private key.

18.1 Intended utility

The NODEA token is intended to coordinate access to launches through:

• staking and time-based locks;
• calculation of effective NODEA;
• qualification for one of five access tiers;
• possible future governance functions that are separately specified and activated.

Holding NODEA alone does not create a right to an allocation. A participant must satisfy the active launch rules and any applicable eligibility requirements.

18.2 Maximum supply

The current working specification uses a maximum supply of:

100,000,000 NODEA

The token contract, decimals, minting controls, burn behavior, and final supply policy must be confirmed in the production token documentation.

18.3 Distribution

The final distribution has not been approved. Do not display invented percentages.

Before token activation, NODEA should publish a complete table covering:

• community or public distribution;
• staking or ecosystem programs, if any;
• protocol treasury;
• team and contributors;
• advisors;
• liquidity;
• project development;
• strategic participants, if any;
• reserves;
• cliffs, vesting, and unlock dates for every category.

18.4 No implied financial rights

Unless final legal and token documentation explicitly states otherwise, NODEA should not be described as equity, debt, a claim on protocol revenue, or a promise of yield.

19.1 Initial stage

During specification, implementation, and testnet work, a defined operating group may coordinate development and launch configuration. Its authority and controls should be documented.

19.2 Controlled activation

Before production launches, material administrative actions should use transparent roles, appropriate multisignature controls, and timelocks where they improve safety without preventing necessary incident response.

19.3 Progressive governance

Future governance may allow eligible stakeholders to propose or approve selected protocol parameters. The scope, voting power, quorum, delegation, execution delay, and emergency limitations require a separate specification.

Possession of NODEA should not be described as conferring current governance rights until those rights are implemented and active.

Phase 0 — Specification

• finalize launch requirements;
• validate tier and staking logic;
• define review and disclosure standards;
• complete product and contract architecture;
• obtain legal analysis for intended markets.

Phase 1 — Implementation

• implement staking and lock contracts;
• implement tier snapshots;
• implement launch, allocation, claim, refund, and vesting modules;
• build project and participant interfaces;
• add monitoring and operational controls.

Phase 2 — Testnet

• deploy on Robinhood Chain testnet;
• test boundary conditions and failure paths;
• run full launch simulations;
• test operational and incident procedures;
• collect participant and project-team feedback.

Phase 3 — Independent review

• complete external contract review;
• remediate material findings;
• verify production deployment procedures;
• publish contract, permission, and risk documentation.

Phase 4 — Curated pilot

• activate a limited number of launches;
• use conservative caps;
• monitor allocation, claim, refund, and vesting behavior;
• publish post-launch findings and improvements.

Phase 5 — Broader activation

• expand launch intake only after pilot evaluation;
• mature governance and operational transparency;
• evaluate additional protocol capabilities through separate specifications.

22.1 Project risk

A project may fail to build its product, attract users, manage its treasury, comply with its obligations, or continue operating. Submitted information may prove incomplete or inaccurate.

22.2 Smart-contract risk

NODEA, project, token, bridge, wallet, or dependency contracts may contain defects or behave unexpectedly. Exploits can result in permanent loss.

22.3 Market and liquidity risk

Tokens can be highly volatile. A market may not develop, and quoted prices may not represent executable liquidity. Vesting does not guarantee price stability.

22.4 Lock risk

Locked NODEA may be unavailable during adverse market conditions or when a participant needs liquidity. The opportunity cost of a longer lock can exceed its access benefit.

22.5 Allocation risk

Tier qualification does not guarantee an allocation. High demand, caps, jurisdictional restrictions, or the launch method can reduce or eliminate a participant’s final allocation.

22.6 Refund risk

A launch may not offer a refund. Where one exists, it can be subject to eligibility conditions, deadlines, contract risk, asset availability, fees, and network failure.

22.7 Network and infrastructure risk

Robinhood Chain, Ethereum, RPC services, indexers, wallets, bridges, and other dependencies can become unavailable, delayed, congested, or compromised.

22.8 Administrative risk

Privileged roles may be misused or compromised. Multisignatures and timelocks reduce some risks while introducing coordination and response tradeoffs.

22.9 Regulatory and legal risk

The legal treatment of tokens, staking, fundraising, refunds, and access restrictions varies by jurisdiction and can change. A launch may be unavailable to some users.

22.10 Governance risk

Future governance may be concentrated, captured, inactive, or unable to respond effectively. Token-based voting can create conflicts between large and small holders.

22.11 Information risk

Documentation, interfaces, indexers, or project statements can contain errors. Participants should verify material onchain information and seek appropriate professional advice.