Langosta Whitepaper v1.0

A Web3 Intelligence and Verifiable Participation Layer on BOT Chain

Version: 1.0
Publication date: August 27, 2026
Network: BOT Chain
Status: Foundation release specification

---

1. Abstract

Langosta is an experimental Web3 intelligence and verifiable-participation interface built on BOT Chain. Its purpose is to help users distinguish inspectable on-chain evidence from unsupported project narratives.

The first Langosta release is intentionally narrow. It provides a BOT Chain Contract Lens for checking basic public facts about an address, a transparent methodology for future project research, and a one-time on-chain participation registry. A connected wallet may confirm a zero-BOT-value registry transaction and, after a successful BOT Chain receipt, receive 100 non-transferable Langosta Points.

Langosta does not launch a token through this whitepaper. Langosta Points are not an ERC-20 asset, are not transferable, have no cash redemption value, and do not establish eligibility for an airdrop, token allocation, financial return, or future benefit.

Langosta does not custody assets, execute trades, audit contracts, or provide financial advice. The project begins with a limited and verifiable foundation so that future research capabilities can be introduced without presenting simulated data as live intelligence.

---

2. The Problem

Web3 users often encounter projects through a sequence of claims: growth claims, community claims, partnership claims, technology claims, liquidity claims, and token claims. These claims can be useful starting points, but they are not automatically evidence.

A marketing website may describe a protocol as active while its declared address contains no deployed code. A screenshot may show a transaction without providing a public hash. A user count may represent wallet addresses rather than people. A liquidity number may omit its source, timestamp, venue, concentration, or withdrawal conditions. A security statement may refer to an audit that covers an older contract version.

The problem is not that every narrative is false. The problem is that the evidence, source, calculation, timestamp, and limitation are often separated from the claim.

This produces several recurring failures:

1. Unclear provenance. Users cannot see where a number originated or when it was collected.
2. Silent missing data. A missing fact is replaced by a plausible estimate, a zero, or an unsupported conclusion.
3. Mixed evidence types. On-chain records, project disclosures, market-provider data, analyst judgement, and model-generated text are presented as if they have equal reliability.
4. Overconfident scoring. A single headline score hides low evidence coverage and subjective assumptions.
5. Confusion between wallets and people. Address counts are represented as verified unique users.
6. Confusion between inspection and audit. Basic contract metadata is presented as a security determination.
7. Reward ambiguity. Points are marketed as implied token value without defined legal or technical terms.

Langosta is designed around a different principle: every product claim should remain connected to its evidence, and every unavailable fact should remain visibly unavailable.

---

3. Vision

Langosta's long-term vision is to become an inspectable research layer for emerging Web3 projects.

The product is intended to organize four categories of evidence:

• contract and permission evidence;
• liquidity and market-structure evidence;
• activity and adoption evidence;
• governance and transparency evidence.

A useful research layer should serve both people and software agents. For people, it should make sources, timestamps, calculations, and gaps understandable. For agents, it should expose structured fields, provenance, confidence, and version information rather than only unstructured marketing text.

The vision does not require Langosta to predict prices or replace human judgement. Its value should come from making evidence easier to inspect, compare, and challenge.

---

4. Foundation Release

The foundation release establishes the product's trust boundary before introducing a large data system.

4.1 BOT Chain Contract Lens

Contract Lens accepts a valid BOT Chain address and performs live RPC checks. It can display:

• the selected network;
• the queried address;
• whether deployed bytecode is present;
• bytecode size;
• a deterministic hash of the returned bytecode;
• the address's BOT balance;
• transaction nonce;
• query time;
• a link to the address in BOT Explorer.

Contract Lens verifies only basic public chain facts. It does not determine whether a contract is safe, audited, legitimate, solvent, liquid, or suitable for a user. The absence of deployed code does not prove malicious intent, and the presence of code does not prove security.

4.2 Langosta Profile

The Profile page reads the connected wallet's Langosta registry state directly from the smart contract. It displays:

• connected wallet;
• current network;
• BOT balance;
• Langosta Points;
• genesis-claim status;
• claim timestamp;
• claim block;
• registry contract;
• public Explorer links.

The contract, rather than browser state or an editable database, is the source of truth for points.

4.3 Whitepaper and methodology

The foundation release publishes this whitepaper and the CLAW methodology before publishing project scores. This order is intentional. A score should not be shown until its inputs, missing-data treatment, evidence coverage, and calculation rules are implemented and inspectable.

---

5. The CLAW Research Framework

CLAW is Langosta's proposed research framework. It separates a project assessment into four dimensions.

5.1 C — Contract Integrity

Contract Integrity examines the technical and administrative surface of a project's declared contracts.

Possible evidence includes:

• deployed code at declared addresses;
• verified source code from an approved source;
• compiler and deployment information;
• proxy and implementation relationships;
• upgrade permissions;
• ownership and role controls;
• pause, mint, blacklist, withdrawal, and custody powers;
• external calls and dependency assumptions;
• published audits and the versions they cover;
• incident and remediation disclosures.

A live eth_getCode result is useful, but it is only one part of Contract Integrity. Langosta must not convert a basic code-presence check into a security rating.

5.2 L — Liquidity and Market Structure

Liquidity and Market Structure examines whether users can understand where and under what conditions an asset or protocol obtains market liquidity.

Possible evidence includes:

• liquidity venues;
• pool composition;
• depth and slippage;
• concentration;
• lock or withdrawal conditions;
• market-maker or treasury relationships;
• volume-source quality;
• token supply and distribution;
• bridge and counterparty dependencies;
• data timestamps and provider availability.

This pillar cannot be scored responsibly without an approved market-data or on-chain analytics provider. The foundation release therefore does not publish live liquidity scores.

5.3 A — Activity and Adoption

Activity and Adoption examines whether on-chain use is persistent, interpretable, and connected to an identifiable product.

Possible evidence includes:

• active addresses under a published definition;
• transaction frequency;
• repeated use over time;
• contract interaction diversity;
• application integrations;
• developer activity;
• product availability;
• concentration and Sybil limitations;
• data-source health.

A wallet address is not equivalent to a unique human. Langosta must keep these concepts separate.

5.4 W — Web3 Governance and Transparency

Web3 Governance and Transparency examines whether a project clearly discloses the people, permissions, processes, and evidence that affect users.

Possible evidence includes:

• team and organization disclosures;
• governance process;
• treasury visibility;
• privileged addresses;
• documentation;
• upgrade and incident communication;
• risk disclosures;
• source attribution;
• change history;
• dispute and contact channels.

Transparency does not guarantee good outcomes, but it makes claims and decisions easier to inspect.

---

6. Evidence Coverage and Missing Data

Langosta treats evidence coverage as a separate output from any future CLAW score.

Each research input should retain:

• source URL, transaction, contract, block, or other reference;
• source type;
• subject address or project identifier;
• evidence timestamp;
• retrieval timestamp;
• applicable CLAW pillar;
• status such as verified, partial, unavailable, or conflicting;
• confidence and limitations;
• transformation or calculation history.

A suggested coverage calculation is:

Evidence Coverage = observed applicable weight / total applicable weight

A future numerical CLAW score should not be published when Evidence Coverage is below 70 percent. In that state, Langosta should display Insufficient evidence rather than a low score that may be mistaken for a negative conclusion.

Missing data should not be silently converted into zero. Conflicting sources should remain visible as a conflict. Data-provider failures should produce an unavailable state instead of a plausible replacement value.

---

7. Future Scoring Architecture

When a verified research pipeline is introduced, Langosta may calculate a CLAW score as a weighted mean over observed, applicable pillars.

Default conceptual weights are:

Contract Integrity                  30%
Liquidity and Market Structure     25%
Activity and Adoption              25%
Web3 Governance and Transparency   20%

These weights are a methodology choice, not a scientific constant. They may be revised through a versioned process as the product learns from new project categories and failure modes.

Every published score should include:

• methodology version;
• pillar values;
• pillar weights;
• evidence coverage;
• missing-data list;
• source references;
• calculation timestamp;
• input hash;
• deterministic calculation rules;
• human and model contribution labels;
• known limitations.

The score should measure the defined research inputs only. It should not be represented as a price forecast, return estimate, audit opinion, or guarantee that a project is legitimate.

---

8. BOT Chain Integration

Langosta is designed for BOT Chain, an EVM-compatible network that supports familiar Ethereum development tools and uses BOT as its native Gas token.

The initial network configuration is:

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

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

The frontend should support standard wallet network switching and network addition. Preview deployments should use BOT Chain Testnet unless explicitly configured and labelled otherwise.

The official listed Mainnet RPC does not support eth_getLogs. Langosta's foundation release therefore relies on direct view calls and transaction receipts for the points profile. Any future event-history or research-indexing feature will require an approved indexer, third-party RPC, or WebSocket source, with its availability and data range disclosed.

---

9. Verifiable Participation and Langosta Points

A browser wallet connection is not an on-chain record. To make participation verifiable, Langosta uses a one-time registry transaction.

The intended flow is:

Connect wallet
→ switch to BOT Chain
→ read claim eligibility
→ review the registry transaction
→ confirm in the wallet
→ wait for a successful receipt
→ read 100 Langosta Points from the contract

The claim sends zero BOT value to the registry. The wallet must still hold enough BOT to pay the network Gas determined by the network and wallet.

Each wallet address may complete the genesis claim once. This is an address-level rule, not proof that one wallet represents one person. A single individual may control multiple addresses, and the foundation release does not claim to provide Sybil resistance.

Langosta Points are a non-transferable record of participation. They are not a token balance and do not create ownership, governance rights, revenue rights, redemption rights, or a claim against Langosta or any third party.

---

10. Registry Smart Contract

The foundation contract is LangostaRegistry.sol.

Its intended state includes:

GENESIS_POINTS = 100
hasClaimedGenesis[address]
points[address]
claimedAt[address]
claimedBlock[address]
totalClaimers
totalPointsIssued

Its primary methods include:

claimGenesisPoints()
canClaim(address)
getProfile(address)
pause()
unpause()

A successful claim marks the wallet as claimed, assigns 100 points, stores the timestamp and block number, updates aggregate counters, and emits a public event.

The registry is intentionally limited:

• it does not receive the user's BOT value;
• it does not custody funds;
• it does not route swaps;
• it does not mint an ERC-20 token;
• it does not make external calls during claim;
• it does not expose an administrator function to edit user points;
• it rejects direct BOT transfers and unsupported calls;
• it may be paused in an emergency;
• ownership uses a two-step transfer process.

The frontend must simulate the claim before requesting a wallet confirmation, wait for a successful receipt before showing points, and provide a public Explorer link. A rejected, reverted, timed-out, or failed transaction must not increase the displayed points.

---

11. Security Principles

Langosta's foundation security model is based on reducing scope.

11.1 Self-custody

Langosta does not request, collect, store, or control private keys, seed phrases, or keystore files. Wallet confirmations occur in the user's wallet interface.

11.2 No-fund registry

The registry claim is non-payable and does not require a Treasury. Direct transfers are rejected. This removes custody and withdrawal logic from the claim path.

11.3 Direct contract state

The Profile reads points from contract view functions. Browser storage may retain only non-sensitive pending-transaction metadata for receipt recovery. It is not the source of truth for points.

11.4 Explicit unavailability

RPC, wallet, browser, contract, Explorer, indexer, or third-party provider failures must produce an explicit unavailable or failed state. Missing data must not be replaced with a fabricated result.

11.5 Contract Lens limitation

Contract Lens is not a security audit. Users must not interpret code presence, bytecode size, code hash, balance, or nonce as proof that an address is safe.

11.6 Mainnet authorization

A Mainnet deployment should occur only after the project owner confirms the final contract version, owner address, deployment authorization, website configuration, and legal text. A developer's personal wallet must not be substituted as the permanent owner without explicit approval.

---

12. Data Integrity and AI Boundaries

The foundation release does not present preview content as live AI intelligence.

If model-generated analysis is introduced later, Langosta should separate:

• raw source data;
• normalized records;
• deterministic calculations;
• human analysis;
• model-generated summaries;
• confidence and risk indicators.

Every model-generated statement should remain linked to its supporting evidence. A model should not invent a missing source, transaction, metric, team identity, audit, partnership, or contract address.

Future agent-readable outputs should include schema version, source identifiers, timestamps, methodology version, and unavailable states. Langosta should prefer a structured unknown over a confident unsupported answer.

---

13. Privacy

Wallet addresses, contract addresses, transaction hashes, blocks, timestamps, balances, bytecode, and contract calls are public blockchain information. Langosta may query and display this public information.

The foundation release does not require Langosta to custody personal funds or collect private keys. The frontend may store limited pending-transaction information such as transaction hash, wallet address, chain ID, and submission time so that confirmation can be recovered after a refresh.

Contract Lens queries may be visible to the configured RPC provider, hosting provider, analytics provider, or browser environment. Any analytics, cookies, logs, account features, or third-party services must be disclosed in the Privacy Policy before use.

Disconnecting a wallet from the website does not erase public blockchain records. Any future account, notification, or subscription feature must define retention, access, correction, and deletion rules before collecting additional personal information.

---

14. Roadmap

Foundation

• template-based Langosta website;
• original brand system;
• BOT Chain Contract Lens;
• wallet connection and network switching;
• genesis points registry;
• Profile;
• methodology;
• Whitepaper and legal pages;
• test coverage;
• Vercel deployment.

Verified Evidence Adapters

• project identity and contract records;
• approved Explorer and market-data adapters;
• source timestamps;
• provider-health monitoring;
• evidence normalization;
• conflict and unavailable states.

CLAW Research Reports

• versioned methodology;
• evidence coverage;
• pillar analysis;
• deterministic score calculation where coverage is sufficient;
• source-linked reports;
• change history.

Agent Access

• structured research API;
• authentication and permissions;
• rate limits;
• schema versioning;
• observability;
• evidence-bound responses.

Watchlists and Alerts

• saved projects;
• contract-change monitoring;
• source updates;
• risk-change alerts;
• user-controlled notification settings.

These stages describe possible direction. They are not guaranteed delivery dates, token milestones, or reward commitments.

---

15. Token and Airdrop Policy

Langosta has not announced a token through this whitepaper.

Langosta Points:

• are not an ERC-20 token;
• are not transferable;
• are not tradeable;
• have no cash redemption value;
• do not represent equity, debt, revenue, governance, or ownership;
• do not establish a token allocation;
• do not establish airdrop eligibility;
• do not guarantee any future utility.

No airdrop is promised. No snapshot date, allocation formula, conversion ratio, token supply, expected value, vesting schedule, reward date, or financial return is defined.

A future change would require a separate public announcement, updated technical rules, and appropriate legal review. Users should not infer such a change from their current points balance.

---

16. Risks and Disclaimers

Blockchain transactions may be irreversible. Users are responsible for reviewing the wallet, network, registry address, transaction value, and Gas details before confirming.

Smart contracts, wallets, RPC services, browsers, Explorers, indexers, hosting systems, data providers, and networks may contain defects, be attacked, return incomplete data, or become unavailable.

A successful Contract Lens query does not mean that an address is safe. A high future CLAW score would not guarantee security, legitimacy, liquidity, price performance, regulatory status, or future returns.

Research inputs may be delayed, incomplete, conflicting, or wrong at the source. Methodology weights involve judgement and may change through versioned updates.

Langosta does not custody assets, execute trades, operate a brokerage service, provide investment recommendations, or provide legal, tax, accounting, or financial advice. Users must make their own decisions and consult qualified professionals where appropriate.

The website, smart contract, methodology, and points system are experimental. Availability and functionality are not guaranteed.

---

17. Conclusion

Langosta begins with a simple principle: inspectable evidence is more useful than unsupported certainty.

The foundation release establishes a real BOT Chain interaction, a limited Contract Lens, a transparent points registry, and an explicit boundary between what is live and what remains planned. It avoids turning a wallet connection into fake points, basic bytecode inspection into a security audit, or future possibilities into token promises.

Langosta's long-term value will depend on the quality of its sources, the visibility of its data gaps, the reproducibility of its methodology, the safety of its contracts, and its ability to keep every conclusion connected to evidence.