Back to application

Product and technical framework

Mettelia Whitepaper

Product, points and on-chain architecture for a clearer BOT Chain participation layer.

Version 1.1

Updated September 2026

Mettelia Whitepaper

Version 1.1 Network: BOT Chain Status: Mainnet Release Last Updated: September 2026

Important Notice

This document describes the current product direction and intended technical framework of Mettelia. It is provided for informational purposes only and may be updated as the product, technical environment, security requirements, and applicable rules evolve.

Mettelia Points are not tokens, currency, securities, investment products, ownership interests, claims on project assets, or promises of future value. No token launch, reward distribution, allocation, or airdrop is guaranteed. Nothing in this document constitutes financial, investment, legal, tax, or regulatory advice.

1. Executive Summary

Mettelia is an on-chain intelligence and participation layer designed for the BOT Chain ecosystem.

The current Mettelia release gives users a simple, non-custodial way to connect a wallet, confirm wallet control in the browser, activate a public on-chain profile, complete lightweight on-chain actions, and view a readable participation record. The product is live at mettelia.online, and the MetteliaPassport contract is deployed on BOT Chain mainnet.

Mettelia is built around a straightforward principle:

Information should be readable off-chain and participation should be verifiable on-chain.

The initial product does not hold user funds, execute trades, recommend investments, or require token approvals. Its purpose is to provide a trustworthy entry point for users who want to understand and participate in the BOT Chain ecosystem while retaining control of their wallets and assets.

Over time, Mettelia may expand from wallet identity and participation records into ecosystem discovery, wallet intelligence, alerts, and transparent strategy tools. Those later capabilities will be introduced only where reliable data, suitable infrastructure, and appropriate risk controls are available.

The current release deliberately distinguishes between three types of evidence:

  • Live product functions: wallet connection, network switching, mainnet profile activation, daily check-in, and contract-state reads;
  • Browser-local preview functions: wallet confirmation and Mettelia Points history;
  • Planned services: server-verified wallet sessions, receipt-backed points settlement, indexing, and a verified project directory.

2. The Problem

Web3 applications often introduce unnecessary friction before users understand what a product does.

Common problems include:

  • unclear wallet requests;
  • transactions without readable context;
  • fragmented explorer data;
  • exaggerated metrics;
  • points systems with hidden rules;
  • speculative airdrop language;
  • interfaces that confuse visual complexity with useful intelligence;
  • applications that ask for approvals or deposits before establishing trust.

For new or developing ecosystems, these problems are amplified. Users may need to move between a network website, wallet, explorer, decentralized exchange, documentation, and community channels simply to understand how to begin.

At the same time, many participation campaigns reduce Web3 to a single “connect wallet” button with no meaningful product layer. They record activity but do not help users understand the network or create a durable, verifiable identity.

Mettelia is designed to create a better starting point.

3. Vision

Mettelia’s vision is to become a clear intelligence interface for the BOT Chain ecosystem.

The product is intended to connect three layers:

  1. Identity — a wallet proves control through a readable signature.
  2. Participation — selected actions are recorded through public BOT Chain transactions.
  3. Intelligence — network, wallet, and ecosystem information is presented in a consistent, understandable interface.

This creates a progression from simple onboarding to deeper ecosystem understanding without requiring Mettelia to custody user assets.

The long-term objective is not to create another speculative dashboard. It is to create a reliable product surface where users can understand what they are seeing, verify what they have done, and distinguish observed data from projections or future plans.

4. Why BOT Chain

BOT Chain is an EVM-compatible Layer 1 network designed for decentralized applications, AI-related applications, DePIN networks, and broader Web3 activity.

EVM compatibility allows Mettelia to use established Ethereum development standards and wallet tooling while deploying directly to BOT Chain. The network’s native BOT asset is used for transaction gas.

Mettelia uses the following network configuration:

  • Mainnet Chain ID: 677
  • Native gas asset: BOT
  • Mainnet RPC: https://rpc.botchain.ai
  • Mainnet Explorer: https://scan.botchain.ai
  • Testnet Chain ID: 968
  • Testnet RPC: https://rpc.bohr.life
  • Testnet Explorer: https://scan.bohr.life

Mettelia is an independent application built on BOT Chain. References to BOT Chain, its wallets, explorer, decentralized exchange, or other ecosystem products do not imply endorsement, partnership, or official status unless explicitly announced by the relevant parties.

4.1 Mainnet Release Record

These addresses are published for verification. They are not a request to send funds.

5. Product Overview

5.1 Wallet Connection

A user begins by connecting an EVM-compatible wallet.

The application detects whether the wallet is connected to BOT Chain. When the wallet is connected to another network, Mettelia provides a clear request to switch to or add BOT Chain.

Connecting a wallet does not transfer assets and does not, by itself, create a blockchain transaction.

5.2 Wallet Verification

A connected address is not sufficient proof that the user controls that address. Mettelia therefore requests a gasless, human-readable signature.

The signed message includes:

  • the Mettelia domain;
  • the connected wallet address;
  • BOT Chain’s chain ID;
  • a unique nonce;
  • the issue time;
  • a statement explaining that the signature does not authorize an asset transfer.

In the current release, the signature is confirmed in the browser and the confirmation is stored on the user’s device. It does not create a backend session or a production reward claim. A future verification service may add expiring nonces, server-side signature checks, and one-time reward enforcement; those capabilities are not presented as live today.

5.3 Mettelia Profile

Verified users may select one of three initial participation profiles:

  • Discoverer — focused on exploring protocols, products, and ecosystem activity;
  • Analyst — focused on data, transparency, and risk-aware interpretation;
  • Builder — focused on building, testing, supporting, or integrating applications.

The selected profile is activated through a zero-value smart-contract transaction. The user pays BOT Chain network gas, but the contract does not require a payment to Mettelia.

The activation creates a public, verifiable record associated with the wallet.

5.4 Daily On-chain Check-in

After activating a profile, a user may complete one on-chain check-in per UTC day.

The check-in:

  • requires an active profile;
  • sends no BOT value to Mettelia;
  • records a public transaction;
  • is limited to one action per wallet per UTC day;
  • may create a points event after the transaction is verified.

The daily action is intended to establish a simple, transparent participation history. It is not a staking, yield, or investment mechanism.

5.5 Network and Wallet Context

The interface may display selected live fields, including:

  • current BOT Chain network;
  • chain ID;
  • latest block number;
  • estimated gas context;
  • connected wallet BOT balance;
  • profile status;
  • points;
  • previous Mettelia actions;
  • explorer links.

When a value is unavailable, Mettelia should display an unavailable state rather than a fabricated substitute.

6. Points Framework

Mettelia Points are non-transferable product records that recognize specified actions.

The initial framework is:

ActionPointsFrequencyVerification
Connect and confirm wallet50Once per browser recordLocal gasless signature
Activate Mettelia profile150Once per walletBOT Chain transaction
Daily on-chain check-in10Once per UTC dayBOT Chain transaction

In the current release, points are a browser-local preview stored on the user’s device. Profile activation and daily check-in remain publicly verifiable through BOT Chain transactions and direct contract reads. No production points database or cross-device settlement service is claimed as live.

6.1 Why Points Are Off-chain

Storing every points calculation directly on-chain would add cost and reduce the ability to correct operational errors. The present release uses the following limited model:

  • identity and selected actions are verifiable;
  • points preview accounting remains browser-local;
  • transaction-based preview events store their transaction reference on the same device;
  • the contract prevents duplicate profile activation and same-day check-ins;
  • rules are published in the interface.

A later receipt-backed service may add cross-device accounting, unique reward constraints, and operational corrections. That service remains planned.

6.2 What Points Are Not

Mettelia Points:

  • are not transferable;
  • cannot be purchased;
  • are not redeemable for cash;
  • do not represent equity;
  • do not represent governance rights;
  • do not represent protocol revenue;
  • do not represent a token allocation;
  • do not guarantee an airdrop;
  • do not guarantee access to future products;
  • may be changed, suspended, corrected, or discontinued.

Mettelia may consider points in future community programs. Such consideration is discretionary and does not create a contractual right, expected return, or entitlement.

7. Smart Contract Design

The initial smart contract is called MetteliaPassport.

Its purpose is limited to recording profile activation and daily check-ins.

7.1 Core State

The contract stores:

  • whether a wallet has activated a profile;
  • the selected profile type;
  • the last UTC day in which the wallet checked in;
  • aggregate profile and check-in counters.

7.2 Core Functions

`activateProfile`

This function:

  • accepts one of the supported profile types;
  • can be called only once per wallet;
  • requires no BOT payment to Mettelia;
  • records the selected profile;
  • emits a public activation event.

`dailyCheckIn`

This function:

  • requires an active profile;
  • allows one check-in per UTC day;
  • requires no BOT payment to Mettelia;
  • records the current day bucket;
  • emits a public check-in event.

`profileOf`

This read-only function returns the wallet’s profile and check-in state.

7.3 Deliberate Exclusions

The initial contract does not include:

  • token minting;
  • reward distribution;
  • deposit balances;
  • staking;
  • swaps;
  • token approvals;
  • asset transfers;
  • yield calculations;
  • administrative withdrawals;
  • custody functions.

This narrow scope reduces attack surface and makes the user action easier to understand.

8. Application Architecture

Mettelia currently uses a client-and-contract Web3 architecture.

User Wallet
    |
    |-- Local readable signature
    |-- User-authorized transaction
    v
MetteliaPassport on BOT Chain
    |
    |-- Public receipt and contract state
    v
Mettelia User Interface
    |
    `-- Browser-local points preview

Authentication, receipt-verification, indexing, and production points services are a planned second-stage architecture rather than current release claims.

8.1 Frontend

The frontend is intended to use a modern React and Next.js architecture with:

  • responsive server-rendered pages;
  • EVM wallet connection;
  • typed contract interactions;
  • accessible transaction states;
  • clear wrong-network handling;
  • Vercel deployment.

8.2 Authentication

The current release uses a readable wallet signature to confirm control in the active browser. It does not create an authenticated backend session. The message includes the domain, address, chain ID, nonce, and issue time so the requested intent remains clear to the user.

A future server-verified session design should use short-lived, one-time nonces and replay protection.

8.3 Transaction Verification

A submitted mainnet action is considered successful in the interface only after a successful transaction receipt. The application then reads the deployed contract to restore profile and check-in state for the connected wallet. The current release does not allocate production points through a backend service.

A future receipt-backed service should additionally verify sender address, destination contract, called function, decoded receipt event, current contract state, and prior reward records before allocating any settled reward.

The official BOT Chain documentation notes that broad eth_getLogs queries are disabled on the listed public mainnet RPC endpoint. Mettelia therefore verifies user-submitted actions through transaction receipts and direct contract reads. A dedicated indexer may be introduced later for historical analytics.

8.4 Data Storage

Current browser-local records include:

  • wallet address;
  • verification timestamps;
  • profile type;
  • preview points total;
  • preview point event history;
  • transaction hashes;
  • check-in day buckets;

The contract separately stores public profile and check-in state. Future services may add security, rate-limit, indexing, and receipt-verification metadata.

Mettelia should minimize stored personal information and should not store private keys or seed phrases.

9. Security Principles

9.1 Self-custody

Users retain control of their wallets and assets. Mettelia does not request seed phrases or private keys.

9.2 Minimal Permissions

The MVP does not request ERC-20 token approvals and does not require deposits.

9.3 Human-readable Intent

Wallet signatures and transaction prompts should explain their purpose in plain language.

9.4 Current Verification Boundary

Contract actions are confirmed through transaction receipts and direct contract reads. Points remain browser-local preview data and must not be described as server-verified or production-settled.

9.5 Replay and Duplicate Controls

The deployed contract prevents repeated profile activation and more than one check-in per UTC day. Server-enforced nonce reuse prevention and unique points constraints remain part of the planned verification service.

9.6 Secret Management

Database credentials, session secrets, and contract deployer keys must remain outside the public frontend bundle and source repository.

9.7 Testing and Contract Verification

The mainnet contract is deployed and the contract address, transaction hash, deployment block, and treasury/deployer address are published in this document and the product. The production application confirms deployed bytecode and reads aggregate counters from the contract.

Block-explorer source-code publication is not yet claimed as complete. Until it is completed, users can verify the deployment transaction and live bytecode, but should not interpret the explorer record as source-verified.

9.8 No Absolute Security Claim

No application, smart contract, wallet, RPC endpoint, or database is risk-free. Mettelia should not describe itself as “fully secure,” “risk-free,” or “guaranteed safe.”

10. User Experience Principles

Mettelia follows six product principles.

10.1 Clarity Before Action

A user should understand why a signature or transaction is requested before confirming it.

10.2 No Fabricated Metrics

Unavailable data is shown as unavailable.

10.3 Visible Transaction State

Pending, confirmation, success, rejection, and failure states are clearly distinguished.

10.4 Public Verifiability

On-chain actions include direct explorer links.

10.5 Transparent Points Rules

Point values, frequency limits, and disclaimers are visible in the product.

10.6 Accessible Design

The application supports keyboard navigation, visible focus states, readable contrast, reduced motion, and usable mobile layouts.

11. Roadmap

The roadmap describes intended directions rather than guaranteed delivery dates.

Phase 1 — Mainnet Passport — Live

  • production domain;
  • BOT Chain wallet connection;
  • browser-local wallet confirmation;
  • Mettelia profile activation;
  • daily check-in;
  • browser-local points preview;
  • public contract and deployment evidence;
  • public whitepaper;
  • Vercel production deployment.

Phase 2 — Verified Services — Next

Potential features:

  • server-verified wallet sessions;
  • receipt-backed points ledger;
  • indexed action history;
  • block-explorer source verification;
  • verified project directory;
  • protocol categories;
  • ecosystem entry points;
  • saved watchlists;
  • basic network activity views.

Project inclusion must not be interpreted as endorsement, safety certification, or financial recommendation.

Phase 3 — Wallet Intelligence

Potential features:

  • wallet activity summaries;
  • user-controlled wallet grouping;
  • token and protocol position views where reliable indexing exists;
  • event alerts;
  • clearer transaction interpretation.

Phase 4 — Strategy Tools

Potential features:

  • historical comparisons;
  • scenario simulation;
  • transparent risk indicators;
  • protocol-specific integrations;
  • methodology documentation.

Mettelia will not describe simulated or historical results as guaranteed future performance.

12. Governance and Operations

The MVP is operated as an application rather than a decentralized governance protocol.

Operational decisions may include:

  • points rule updates;
  • abuse prevention;
  • security fixes;
  • contract migrations;
  • feature prioritization;
  • data-provider changes;
  • service suspension.

Material changes to points rules should be published with an effective date. Corrections may be applied where fraud, duplication, software errors, or data inconsistencies are detected.

A future governance model, if introduced, will require a separate design and should not be implied by the initial points system.

13. Risk Factors

13.1 Smart Contract Risk

Code defects may cause transactions to fail or state to be recorded incorrectly.

13.2 Wallet Risk

Users are responsible for wallet security and for reviewing transaction prompts.

13.3 Network Risk

BOT Chain congestion, reorganization, RPC outages, explorer outages, or protocol changes may affect the application.

13.4 Data Risk

RPC and indexing data may be delayed, incomplete, unavailable, or inconsistent.

13.5 Application Risk

Browser storage, RPC, hosting, wallet, or software failures may affect the local preview record or access. Clearing browser data or changing devices may remove preview points because cross-device settlement is not yet live.

13.6 Regulatory Risk

Rules affecting digital assets, points programs, wallets, and decentralized applications may change.

13.7 Roadmap Risk

Planned features may be delayed, modified, or cancelled.

13.8 Points Risk

Points may be adjusted, suspended, or discontinued and may never be associated with any benefit.

14. No Financial Advice

Mettelia does not provide investment, trading, tax, legal, or financial advice.

Network data, wallet data, project information, simulations, or future analytical tools may be incomplete or inaccurate. Users are responsible for their own decisions and should independently verify material information.

References to protocols, assets, or ecosystem applications do not constitute an endorsement.

15. No Token or Airdrop Commitment

Mettelia has not promised a token or airdrop through this whitepaper.

Statements such as “points may be considered” describe only a possible future evaluation factor. They do not create:

  • a right to receive tokens;
  • a right to receive money;
  • a right to receive project ownership;
  • a right to participate in governance;
  • a minimum allocation;
  • a guaranteed reward;
  • an expectation of profit.

Users should participate only when they find the current product useful and should not incur transaction costs based on speculation about future rewards.

16. Conclusion

Mettelia is designed to make early BOT Chain participation clearer, more transparent, and more verifiable.

The first version deliberately limits its scope:

  • connect and verify a wallet;
  • inspect the public mainnet release record;
  • understand the active network;
  • activate a profile;
  • complete lightweight on-chain actions;
  • view a browser-local points preview;
  • retain custody of assets.

This foundation can support deeper ecosystem intelligence later without requiring the MVP to exaggerate its capabilities.

Mettelia’s operating principle remains:

Readable off-chain. Verifiable on-chain.

References