Lunaraty Protocol Whitepaper

Verifiable Participation on BOT Chain

Version 1.0 — 29 August 2026

This document describes the intended first release of Lunaraty Protocol. It is a product and technical specification, not an offer of securities, an investment solicitation, financial advice, or a promise of a token, airdrop, reward, return, allocation, or future benefit.

1. Abstract

Lunaraty Protocol is a wallet-native participation registry built on BOT Chain. Its first release gives a self-custody wallet a narrow way to create a public, inspectable participation record.

A wallet may confirm one standard Genesis Signal transaction and record 100 non-transferable Lunaraty Points. The standard action sends zero BOT value to the protocol contract, although the wallet still pays network Gas in BOT. A wallet may also activate one optional Eclipse Boost by sending exactly 0.01 BOT, bringing the wallet’s total to a maximum of 200 Points. The Boost can be completed directly by a new wallet or after the standard record has already been created.

Lunaraty Points are contract state. They are not an ERC-20 token, cannot be transferred, cannot be redeemed, have no cash value, do not represent protocol ownership, and do not guarantee eligibility for any token, airdrop, reward, allocation, financial return, or future product feature.

The purpose of the first release is not to maximize feature count. It is to establish a small, understandable system whose rules, payments, wallet state, transaction receipts, and public activity can be inspected.

2. Problem and Context

Many early Web3 products invite users to “connect a wallet” and then present points, levels, eligibility, or activity counters. These interfaces often blur several different states:

• a wallet has been connected to a webpage;
• a wallet has signed a message;
• a server has created an off-chain database entry;
• a transaction has been submitted;
• a transaction has been confirmed;
• a smart contract has updated public state.

When these states are presented as if they were the same, users cannot easily determine what actually happened. A local browser value may be mistaken for a public record. A submitted transaction may be shown as successful before it is confirmed. A points balance may be editable by an administrator without a visible rule. Future rewards may be implied even though no such program exists.

Lunaraty Protocol begins from a simpler premise: a first release should distinguish interface state from chain state and should make the limits of its points system explicit.

The protocol therefore focuses on one small record:

A wallet completed a defined Lunaraty participation action on BOT Chain.

The protocol does not attempt to prove that one wallet represents one unique person. It does not assess reputation, identity, investment value, social influence, or financial behavior. It does not custody assets, route trades, offer yield, or request token approvals.

3. Design Principles

3.1 Public proof before future promises

A Lunaraty balance is displayed only after the interface reads confirmed contract state. The product does not use local storage as the source of truth for Points, and it does not treat a submitted transaction as a confirmed record.

3.2 One clear action at a time

The first release offers two understandable choices:

• record 100 standard Points through a zero-BOT-value contract action; or
• activate an optional fixed 0.01 BOT Boost and reach 200 Points.

The interface must distinguish the protocol fee from network Gas and must never preselect or automatically submit the paid action.

3.3 Self-custody throughout

Users interact through an external EVM-compatible wallet. Lunaraty does not request private keys, seed phrases, keystore files, token approvals, deposits, or custody rights. Every transaction is reviewed and confirmed in the user’s wallet.

3.4 Fixed and inspectable rules

The V1 contract fixes the base amount, Boost amount, maximum balance, and Boost fee as constants. The owner cannot grant, remove, transfer, or arbitrarily rewrite a wallet’s Points.

3.5 Explicit limits

Lunaraty Points are participation records and nothing more. The interface and documentation must not imply that Points are money, a tradable asset, an investment, protocol ownership, or a guaranteed gateway to a later distribution.

3.6 A narrow contract is easier to inspect

The first contract does not integrate a DEX, bridge, lending protocol, token, NFT system, oracle, yield source, or cross-chain router. Fewer external dependencies make the product boundary easier to understand and test.

4. V1 Product Boundary

The first release includes:

• a public website based on a user-supplied design template;
• an original Lunaraty Protocol identity and logo;
• BOT Chain wallet connection;
• network detection and add/switch flow;
• a standard on-chain Points record;
• an optional one-time 0.01 BOT Boost;
• a wallet Account page;
• public contract statistics;
• recent activity read from contract state;
• transaction, block, contract, and Explorer links;
• this Whitepaper;
• privacy and terms disclosures;
• BOT Chain Testnet validation;
• Vercel deployment.

The first release does not include:

• a Lunaraty token;
• tokenomics or a token sale;
• an airdrop commitment;
• a DEX, swap, bridge, or liquidity pool;
• staking, APY, lending, or yield;
• deposits or custody;
• NFTs;
• governance voting;
• referral farming;
• identity verification or proof of unique personhood;
• encrypted balances, private swaps, FHE, or anonymous transactions;
• cross-chain execution;
• an AI agent or automated trading system.

Roadmap references to future functionality are exploratory. They do not create an obligation to ship a feature or provide a benefit.

5. Participation Lifecycle

5.1 Wallet connection

The user connects a self-custody EVM wallet. Connection allows the interface to read the public wallet address, current chain, BOT balance, and Lunaraty contract state.

Wallet connection alone does not write to the blockchain. It must not be described as a completed on-chain claim.

5.2 Network verification

The interface checks that the wallet is connected to the configured BOT Chain environment. Testnet uses Chain ID 968. Mainnet uses Chain ID 677. The interface may request that the wallet add or switch networks, but the wallet user remains in control.

5.3 Standard Genesis Signal

An eligible wallet may review and submit the standard action. The transaction sends zero BOT value to the contract and requires network Gas in BOT.

After a successful receipt, the contract records:

• the wallet’s base claim status;
• 100 Points;
• the timestamp;
• the block number;
• aggregate participation statistics;
• a recent activity record;
• a public event.

A wallet cannot complete the standard action twice.

5.4 Direct Eclipse Boost

A wallet that has not completed the standard action may choose the direct Boost path. The transaction sends exactly 0.01 BOT to the contract and pays Gas separately.

After a successful receipt, the contract creates the base state and Boost state in one transaction, records a total of 200 Points, updates aggregate statistics, forwards the 0.01 BOT to the immutable Treasury, stores a recent activity record, and emits an event.

5.5 Upgrade after Standard

A wallet with 100 Points may later submit the same fixed 0.01 BOT Boost action. The wallet’s total becomes 200 Points. The Boost cannot be repeated.

5.6 Confirmation and evidence

The interface shows success only after receiving a successful transaction receipt and rereading contract state. It then presents available evidence, including:

• wallet address;
• action type;
• Points state;
• BOT value;
• transaction hash;
• block number;
• contract address;
• BOT Chain Explorer links.

If the transaction is rejected, reverted, or cannot be confirmed, the interface does not add Points.

6. Points Model

The V1 Points model is intentionally simple:

Base Points      100
Boost Points     100
Maximum Points   200
Boost Fee        0.01 BOT

Points are bound to the wallet that completed the transaction. They cannot be moved to another wallet, combined across wallets, delegated, sold, redeemed, or withdrawn.

A connected wallet is not necessarily a unique individual. A person may control multiple wallets, and a wallet may be used by more than one person. Lunaraty V1 does not claim Sybil resistance or unique-person verification.

The contract owner has no function to edit individual balances. This prevents discretionary grants and deductions inside the V1 contract. If a future version introduces a different rule, it should use a new, publicly documented contract and migration process rather than silently changing historical meaning.

7. Optional 0.01 BOT Eclipse Boost

Eclipse Boost is a one-time optional participation action. The contract accepts exactly 0.01 BOT. Values below or above that amount revert.

The payment is not:

• a deposit;
• a stake;
• an investment;
• a purchase of a token;
• a liquidity contribution;
• a promise of profit;
• a guaranteed path to a future distribution.

The wallet also pays network Gas, which is separate from the 0.01 BOT protocol fee. The review interface must show both concepts clearly.

After contract state is updated, the 0.01 BOT is forwarded to an immutable Treasury address set at deployment. If the Treasury transfer fails, the transaction reverts and no Boost state is recorded.

Before Mainnet deployment, the project owner must approve the Treasury address. A developer’s personal or temporary address must not be substituted.

8. Smart-Contract Architecture

The reference V1 contract is LunaratyGenesisRegistry.sol.

It uses:

• Solidity 0.8.x;
• OpenZeppelin ownership, pausing, and reentrancy protection;
• fixed constants for Points and the Boost fee;
• mappings for wallet state;
• aggregate counters;
• public events;
• a fixed-capacity recent activity ring buffer;
• an immutable Treasury;
• direct-transfer and fallback reverts.

8.1 Owner powers

The owner may pause and unpause new interactions and may transfer ownership through a two-step process. The owner cannot change individual Points, transfer user assets, alter the fixed V1 Boost fee, or claim on behalf of a user.

8.2 Pausing

Pausing blocks new Standard and Boost actions. Existing records remain readable. Pausing is an emergency control, not a method for rewriting history.

8.3 Ring buffer

The BOT Chain public Mainnet RPC disables eth_getLogs. To make a small recent-activity surface readable without relying on historical event scans, the V1 contract maintains a fixed-capacity ring buffer.

The ring buffer is not a complete historical index. Older records are overwritten as new records arrive. Events are still emitted so that a dedicated indexer or compatible RPC provider can build a complete history later.

8.4 Direct transfers

The contract rejects direct BOT transfers and unknown calls. The intended paid path is the explicit Boost function, which enforces the exact fee and updates state atomically.

9. BOT Chain Integration

BOT Chain is an EVM-compatible network. The first release uses the following public environments:

Testnet
Chain ID: 968
RPC: https://rpc.bohr.life
Explorer: https://scan.bohr.life
Native Gas token: BOT

Mainnet
Chain ID: 677
RPC: https://rpc.botchain.ai
Explorer: https://scan.botchain.ai
Native Gas token: BOT

Testnet is the required first deployment environment. Mainnet deployment occurs only after contract tests, wallet tests, Treasury validation, owner approval, legal copy review, and explicit deployment authorization.

A public website that still uses Testnet must display Testnet Preview clearly. It must not silently represent Testnet activity as Mainnet activity.

10. Public Data and Privacy Limits

Lunaraty V1 is not a private transaction protocol. Wallet addresses, transaction hashes, contract addresses, block numbers, timestamps, and BOT values are public blockchain data.

The website may read and display:

• the connected public wallet address;
• BOT balance;
• current network;
• contract Points state;
• claim and Boost status;
• aggregate contract counters;
• recent contract activity;
• transaction receipts and Explorer links.

The website does not require a legal name, phone number, profile biography, private key, seed phrase, or keystore file.

Pending transaction recovery may store non-sensitive browser data such as the transaction hash, wallet address, chain ID, action type, and submission time. This local data is not the source of truth for Points.

Third-party services may include wallet providers, WalletConnect, RPC providers, BOT Chain Explorer, analytics tools, and Vercel hosting. Their independent policies may apply. Privacy-conscious analytics should avoid sending full wallet addresses to third-party analytics systems.

11. Treasury and Administration

The V1 Treasury receives successful Boost fees. It does not receive the standard action because that action sends zero BOT value.

The V1 contract does not contain a general withdrawal function because Boost payments are forwarded during the transaction. The project should publicly document the deployed Treasury address and should use an approved project-controlled address, preferably with appropriate operational security.

Operational administration includes:

• approving the owner address;
• approving the Treasury address;
• deploying and verifying the contract;
• pausing in an emergency;
• transferring ownership when required;
• maintaining the public website and environment configuration.

Administrative control does not create the power to rewrite individual Points.

12. Security Model

The protocol’s security depends on several layers:

12.1 Contract correctness

The contract must be tested for duplicate claims, exact value handling, state accounting, Treasury forwarding, pause behavior, ownership, ring-buffer ordering, direct transfers, fallback calls, and reentrancy-sensitive paths.

12.2 User confirmation

Every state-changing action is confirmed in the user’s wallet. The interface must display the selected action, value sent, expected Points, network, contract, Treasury when applicable, and separate network Gas disclosure.

12.3 Receipt-based state

The interface does not treat a wallet prompt or transaction hash as final success. It waits for a receipt and rereads contract state.

12.4 Environment control

Contract addresses, deployment blocks, RPC URLs, and explorers are configured by environment. Missing configuration disables transactions rather than falling back to a fake address.

12.5 Secret handling

Deployment private keys are not committed to source control, exposed to the browser, or placed in public environment variables. The website never requests a user’s private key or seed phrase.

12.6 Limited scope

The contract avoids token approvals, arbitrary external protocol calls, upgradeable proxies, and complex asset accounting. Limited scope reduces—but does not eliminate—risk.

A public deployment should not claim an audit unless a real, identifiable audit has been completed and published.

13. Risks and Limitations

Users should understand the following risks:

• blockchain transactions may be irreversible;
• wallets may show inaccurate or delayed estimates;
• RPC providers may be unavailable;
• network conditions may delay confirmation;
• smart contracts may contain defects despite testing;
• the project may pause new interactions;
• the Treasury address may be compromised if operational security fails;
• the website or third-party providers may be unavailable;
• points may never gain any additional use;
• a future version may not be released;
• a roadmap item may change or be cancelled;
• one wallet does not prove one unique human;
• recent activity in the ring buffer is not a permanent full-history index;
• public blockchain activity can be observed and analyzed by third parties.

Users should verify the network, contract address, value, and transaction details in their wallet before confirmation.

14. Roadmap

Phase 01 — Genesis Signal

• wallet connection;
• BOT Chain network flow;
• standard 100-point record;
• optional 0.01 BOT Boost to 200;
• Account and Explorer evidence;
• public contract statistics;
• recent activity;
• Whitepaper and legal disclosures;
• Vercel release.

Phase 02 — Signal Layer

Lunaraty may explore additional wallet-bound participation actions and richer evidence surfaces. Any new action should have a documented rule and should not silently change the meaning of V1 Points.

Phase 03 — Credentials

Lunaraty may explore non-transferable credentials or contribution categories. Such credentials would require separate security, privacy, product, and legal review.

Phase 04 — Coordination

Lunaraty may explore community input and ecosystem integrations after the protocol has a clearer operational and governance model.

All roadmap items are exploratory and may change. No delivery date, token, airdrop, allocation, financial return, eligibility, or future benefit is promised.

15. Airdrop and Token Disclaimer

Lunaraty Protocol V1 does not issue a token. Lunaraty Points are not a token and are not designed as a claim on a future token.

The project may study additional ecosystem uses for Points, but this statement does not create or imply:

• an airdrop;
• a snapshot;
• token eligibility;
• a conversion ratio;
• an allocation formula;
• a redemption right;
• protocol ownership;
• profit participation;
• financial return;
• preferential access;
• a guaranteed future feature.

Users should not pay the 0.01 BOT Boost because they expect a token or financial benefit. The Boost is an optional participation fee for the V1 record described in this document.

16. Conclusion

Lunaraty Protocol starts with a small and inspectable foundation: a self-custody wallet, one standard Genesis Signal, one optional fixed Boost, a maximum Points balance, a public contract state, and explorer-linked evidence.

The first release should be evaluated by whether its template adaptation is faithful, its wallet flow is understandable, its contract rules are fixed, its transaction states are accurate, its Treasury path is disclosed, its limitations are explicit, its tests pass, and its deployment can be verified.

Lunaraty’s initial objective is not to make the largest promise. It is to leave one clear signal on-chain.

Appendix A — V1 Parameters

Protocol: Lunaraty Protocol
Network: BOT Chain
Base Points: 100
Boost Points: 100
Maximum Points: 200
Boost Fee: 0.01 BOT
Standard Value: 0 BOT
Network Gas: Paid separately in BOT
Transferable Points: No
Token Issued: No
Airdrop Promised: No
Custody: No
Token Approval: No

Appendix B — Public Network Configuration

BOT Chain Mainnet
Chain ID: 677
Hex Chain ID: 0x2a5
RPC: https://rpc.botchain.ai
Explorer: https://scan.botchain.ai
Native Token: BOT

BOT Chain Testnet
Chain ID: 968
Hex Chain ID: 0x3c8
RPC: https://rpc.bohr.life
Explorer: https://scan.bohr.life
Native Token: BOT

Appendix C — Independent Project Notice

Lunaraty Protocol is an independent project. Reference to another website or protocol for design research does not imply affiliation, endorsement, partnership, shared ownership, or technical integration.