MASIATOOL WHITEPAPER

Wallet Identity, Participation Points and Public Proof on BOT Chain

Version: 1.0 Publication date: August 2026 Network: BOT Chain Website language: English

Important Notice

This whitepaper describes the intended foundation release of MasiaTool. It is not an offer to sell tokens, securities, financial products, or investment contracts. MasiaTool has not announced a token or promised an airdrop.

Masia Points are non-transferable participation records. They have no cash value, are not redeemable, do not represent ownership or governance, and do not establish eligibility for any future token, reward, allocation, or benefit.

Product features, roadmap items, network services, smart contracts, wallets, and third-party infrastructure may change after technical, security, operational, and legal review.

1. Executive Summary

A blockchain wallet is a powerful proof of key control, but a raw address is difficult to understand. It does not clearly communicate whether a user has activated a product profile, what participation path they selected, or where the underlying proof can be inspected.

MasiaTool is a wallet-native identity and participation toolkit built on BOT Chain. Its foundation release turns a connected wallet into a simple, readable, and publicly verifiable participation profile.

The first release focuses on a deliberately small set of capabilities:

• connect a compatible self-custodial wallet;
• add or switch to BOT Chain;
• activate a Standard or Boosted profile;
• record fixed, non-transferable Masia Points;
• display a deterministic Masia ID;
• read profile state directly from a smart contract;
• link confirmed actions to BOT Chain Explorer;
• avoid the custody of user assets and private keys.

MasiaTool does not claim to verify a person's legal identity. It does not launch a full decentralized identifier or verifiable credential protocol in the foundation release. Instead, it establishes a trustworthy base layer: explicit user consent, deterministic contract state, readable public proof, and clear product boundaries.

2. The Problem

2.1 Wallet addresses lack context

An address can receive assets and call contracts, but it is not a user-friendly profile. Most people cannot infer useful participation information from a hexadecimal string.

Applications often solve this problem by building centralized accounts around wallets. That approach can create new databases, passwords, opaque scoring rules, and platform-controlled identity silos.

2.2 Web3 identity is frequently overclaimed

Decentralized identity is a broad field that includes decentralized identifiers, credential schemas, issuers, holders, verifiers, revocation, selective disclosure, privacy technology, storage, portability, and governance.

A website should not claim to provide this entire stack when it only connects a wallet. Overstating identity capabilities weakens trust and makes it difficult for users to understand what is actually verified.

2.3 Participation systems can become speculative

Points are often presented as if they are guaranteed future tokens. Unclear language can cause users to spend money based on unsupported expectations.

MasiaTool uses fixed and non-transferable participation points. The product explicitly separates current functionality from possible future exploration.

2.4 Proof is often hidden behind the interface

A Web3 product should not require users to trust a success animation. A confirmed state should be traceable to the transaction, block, contract, and public storage that produced it.

MasiaTool treats verification links and contract state as first-class product elements.

3. Vision

MasiaTool's long-term vision is to make wallet-based identity easier to understand, verify, and integrate without forcing users into a proprietary account system.

The product follows five principles.

User control

The user keeps control of the wallet. MasiaTool does not ask for a seed phrase, private key, or keystore file.

Explicit consent

No wallet connection or transaction should occur without a user action. Every paid action must show the network, contract, function, value, and expected result before confirmation.

Verifiable state

Points and profile status are read from the contract. A UI message is not treated as proof by itself.

Minimal data

The foundation release avoids collecting legal identity documents, biometric information, or unnecessary personal data.

Honest scope

MasiaTool describes future credential and interoperability work as research and roadmap direction, not as functionality that already exists.

4. Product Scope

The foundation release contains five user-facing elements.

Wallet connection

Users can connect a compatible self-custodial wallet. The application checks the active chain and can request that the wallet add or switch to BOT Chain.

Profile activation

A connected user selects Standard or Boosted activation.

Standard activation records 100 Masia Points and sends zero BOT to the protocol. The user still pays network gas.

Boosted activation records 200 Masia Points and sends exactly 0.01 BOT to the protocol flow, in addition to network gas.

A Standard profile can later be upgraded by paying exactly 0.01 BOT. The final profile then records 200 points.

Masia Profile

The interface transforms contract state into a readable profile containing the wallet, network, status, tier, points, timestamps, blocks, transaction links, and contract link.

Masia ID

Masia ID is a deterministic display identifier derived from the chain ID and a hash of the wallet address. It improves readability but does not replace the underlying wallet.

Masia ID is not a W3C decentralized identifier and is not a claim about a user's legal identity.

Public proof

Users can open their transaction, block, and contract on BOT Chain Explorer. The application must re-read contract state after a successful receipt before showing a final confirmed profile.

5. User Journey

The intended foundation journey is:

1. A visitor reviews the product and chooses to connect a wallet.
2. The application detects the wallet account and network.
3. The user adds or switches to BOT Chain when needed.
4. The application reads the current profile state.
5. A new user selects Standard or Boosted activation.
6. The application displays a transaction review.
7. The wallet asks the user to approve or reject the transaction.
8. The application waits for a successful receipt.
9. The application reads the resulting contract state.
10. The user receives a readable Masia Profile and Explorer links.

The application must handle rejected transactions, wrong networks, insufficient balance, reverted transactions, RPC failures, replaced transactions, and pending transaction recovery.

6. Masia Points

6.1 Fixed rules

The foundation release uses deterministic rules:

• Standard activation: 100 points;
• Boosted activation: 200 points;
• Standard-to-Boosted upgrade: an additional 100 points;
• maximum per wallet: 200 points.

6.2 Non-transferability

Masia Points are contract records, not ERC-20 tokens. Users cannot send, trade, sell, bridge, stake, or redeem them.

6.3 No economic rights

Masia Points do not represent:

• money;
• equity;
• debt;
• revenue sharing;
• profit sharing;
• governance;
• ownership;
• a claim on treasury assets;
• a promised service credit;
• a guaranteed reward;
• an airdrop allocation.

6.4 Sybil limitations

One wallet is not proof of one person. A user may control multiple wallets. MasiaTool should not describe wallet count as verified human count.

The foundation release does not attempt to solve proof-of-personhood.

7. Smart Contract Architecture

The foundation contract is called MasiaProfileRegistry.

It records a profile per wallet, including:

• activation timestamp;
• activation block;
• boost timestamp;
• boost block;
• points;
• boosted status.

The contract also exposes aggregate counters:

• total profiles;
• total boosted profiles;
• total points issued;
• total BOT forwarded.

Standard activation

claimStandard() creates a profile with 100 points. It does not accept protocol payment.

Direct Boosted activation

claimBoosted() requires exactly 0.01 BOT and creates a profile with 200 points.

Upgrade

upgradeBoost() requires an existing Standard profile, requires exactly 0.01 BOT, and changes the profile to 200 points.

Administrative boundaries

The owner may pause or unpause new writes for incident response. The owner must not have a function that arbitrarily changes individual point balances.

The treasury is fixed during deployment. The 0.01 BOT payment is forwarded to the configured treasury. The deployer, owner, and treasury must be approved by the project owner before Mainnet deployment.

Contract verification

The production contract source should be verified on BOT Chain Explorer. The website should expose the active contract address.

8. BOT Chain

BOT Chain is the execution and public verification layer for the foundation release.

The application uses the BOT Chain Mainnet configuration:

• Chain ID: 677;
• native token: BOT;
• RPC: https://rpc.botchain.ai;
• Explorer: https://scan.botchain.ai.

Testing uses BOT Chain Testnet:

• Chain ID: 968;
• native test token: tBOT;
• RPC: https://rpc.bohr.life;
• Explorer: https://scan.bohr.life.

The foundation release should be deployed and tested on Testnet before any Mainnet deployment.

The public Mainnet RPC may not support historical eth_getLogs queries. MasiaTool therefore reads profile state through direct contract view functions. A future activity index must use an approved indexing provider or WebSocket service and clearly communicate unavailable states.

9. Data and Privacy

9.1 Public blockchain data

Wallet addresses, contract addresses, transaction hashes, blocks, timestamps, balances, and contract state are public blockchain information.

MasiaTool may retrieve and display this information.

9.2 Data the foundation release does not require

The foundation release does not require:

• seed phrases;
• private keys;
• passport scans;
• identity card scans;
• face scans;
• biometric templates;
• legal names;
• home addresses;
• phone numbers;
• email addresses.

9.3 Local pending transaction recovery

The application may store a limited pending transaction record in the browser:

• wallet address;
• chain ID;
• transaction hash;
• contract address;
• action;
• submission time.

This record allows the application to recover confirmation state after a refresh. It does not make a failed or pending transaction successful.

9.4 Infrastructure visibility

Wallet providers, RPC providers, hosting providers, analytics providers, and the user's browser may process technical requests. Any configured analytics or cookies must be disclosed in the Privacy Policy.

Disconnecting a wallet from the website does not delete public blockchain records.

10. Security Model

MasiaTool relies on several independent systems:

• the user's wallet;
• the BOT Chain network;
• RPC endpoints;
• the smart contract;
• the browser;
• the frontend deployment;
• Explorer services;
• optional WalletConnect infrastructure.

No system is guaranteed to remain available or defect-free.

Users should verify:

• the active network;
• the wallet account;
• the contract address;
• the function;
• the BOT value;
• estimated gas;
• the final receipt.

The interface should simulate a contract call before submission when possible. A success state should be shown only after a successful receipt and a matching contract-state read.

Smart-contract reviews and tests reduce risk but do not eliminate it.

11. Identity Boundaries

The foundation release proves a narrow fact: a wallet called the MasiaTool registry and created a specific public contract state.

It does not prove:

• the legal identity of the wallet controller;
• uniqueness of a person;
• age;
• residence;
• accreditation;
• reputation;
• creditworthiness;
• regulatory status;
• ownership of external social accounts;
• authenticity of third-party claims.

Future credential functionality would require additional standards, schemas, issuer governance, revocation, consent, privacy, storage, interoperability, and legal review.

12. Token and Airdrop Policy

MasiaTool has not announced a token through this whitepaper.

No airdrop is promised.

Masia Points do not establish:

• eligibility;
• snapshot status;
• allocation;
• conversion ratio;
• token supply;
• vesting;
• reward date;
• expected value;
• financial return.

A future change would require a separate public announcement, updated rules, technical implementation, security review, and appropriate legal review.

Users should not spend 0.01 BOT based on an assumption that points will become financially valuable. The Boosted option is a current participation choice, not an investment product.

13. Roadmap

Foundation

• template-based public website;
• original MasiaTool brand and Logo;
• BOT Chain wallet connection;
• Standard and Boosted activation;
• Masia Points;
• public profile;
• Explorer proof;
• Whitepaper and legal pages;
• contract tests;
• Vercel deployment.

Profile Utilities

• wallet-address profile lookup;
• shareable public profile links;
• downloadable public profile cards;
• improved consent and disclosure controls;
• clearer network and provider health states.

Verified Attestations

Possible research areas:

• issuer registry;
• credential schemas;
• signed attestations;
• revocation;
• expiration;
• provenance;
• consent;
• selective disclosure;
• standards compatibility.

These capabilities will not be represented as live until implemented and reviewed.

Agent Access

Possible machine-readable interfaces:

• structured profile schema;
• explicit unknown and unavailable values;
• chain and contract identifiers;
• proof timestamps;
• rate limits;
• permissions;
• schema versioning.

Interoperability

MasiaTool may evaluate standards-based identity and credential adapters. It should avoid making users dependent on a proprietary representation when an open standard is appropriate.

Roadmap sections are exploratory. They are not guaranteed delivery dates or reward commitments.

14. Operations and Governance

The foundation contract owner can pause writes during an incident. Ownership should use a project-controlled address and preferably a multisignature process before a significant public launch.

The treasury address must be disclosed in deployment records. Contract changes, frontend contract-address changes, and material point-rule changes should be publicly documented.

A future upgradeable architecture should only be adopted after a clear need, security review, governance policy, and user disclosure. The foundation release should prefer a small and understandable contract.

15. Risks

Smart-contract risk

Code may contain defects or behave differently from expectations.

Wallet risk

Users may approve the wrong transaction, use a compromised wallet, or lose access to keys.

Network risk

BOT Chain, RPC endpoints, Explorers, and indexing services may be delayed, unavailable, or return inconsistent information.

Treasury risk

The configured treasury may be compromised or incorrectly configured.

Frontend risk

A malicious or compromised frontend could display incorrect transaction information. Users should check wallet transaction details.

Regulatory risk

Rules governing digital assets, points, identity products, privacy, and consumer disclosures vary across jurisdictions and may change.

Expectation risk

Users may incorrectly assume that points guarantee an airdrop or financial benefit. MasiaTool must continue to use clear non-promise language.

Privacy risk

Public wallet activity can be analyzed and linked with other public or off-chain information.

16. Conclusion

MasiaTool begins with a small and verifiable promise.

A user connects a self-custodial wallet, reviews a transparent BOT Chain transaction, creates deterministic contract state, and receives a readable profile with public proof.

This foundation does not solve every identity problem. It does establish the behavior required for a trustworthy identity tool:

• explicit consent;
• limited data collection;
• clear product boundaries;
• deterministic state;
• public verification;
• no unsupported token promise.

The long-term opportunity is to build from participation proof toward portable and consent-based identity. The first responsibility is to make the current layer real.