# MSH Whitepaper

Version 1.0 | 2026-10-24 | English

Translation published 2026-10-25. This edition preserves the scope and on-chain snapshot of the Simplified Chinese original; it is not a live market report. The Chinese original is the reference if a translation differs.

Website: https://mshbot.top

Contract: 0x5cf49332de35899d6852a28a8bbbd8727578ffff

## 01 Making bot services a practical use for the token

MSH brings Telegram bot hosting, community tools and digital product delivery into one website, giving the token a use through actual services.

### The problem and the product

Individuals and small communities need welcome messages, recurring answers, announcements, moderation and digital delivery without deploying and maintaining bot software themselves. MSH provides shared hosting and button-based configuration. Users retain their own bot identity; the platform operates the website, runtime and order verification.

MSH is a project token on BNB Smart Chain. Users can purchase service time and group capacity for a particular bot using MSH; verified MSH service payments go to the public burn address. BNB is also accepted for platform services.

Holding tokens alone does not activate a bot. Users must register, connect a bot, verify its owner and claim an available trial or purchase service. Holder fee distribution above a balance threshold is a separate on-chain mechanism, not free website membership.

### Sources of utility

- Practical utility: less deployment, maintenance and repetitive work.
- Service consumption: actual MSH service payments go to the burn address.
- Holder mechanism: eligible addresses may participate in fee distribution under contract rules.

> Service use and trading may create demand, but do not guarantee a rising price, sustained volume, distributions or perpetual operation. BNB payments mean MSH is not the only service payment asset.

## 02 Products available in this edition

This edition describes deployed capabilities at its publication date, rather than presenting plans as completed products.

| Module | Capabilities |
| --- | --- |
| Community basics | Welcome messages, whole-message keyword replies, rules and custom shortcut buttons. |
| Automation | Scheduled announcements, advertising keyword and link filtering, deletion and temporary muting. |
| Monitoring | Keyword alerts in authorized groups and change alerts for specified public web pages, subject to permissions and frequency limits. |
| Your own AI API | Users supply an endpoint, model and API key. Implemented protocols include OpenAI-compatible APIs, Anthropic Messages and Gemini generateContent. Compatibility with every vendor, proprietary protocol or multimodal feature is not guaranteed. |
| Digital store | Listings, encrypted code inventory, orders, delivery retrieval and support records. Telegram purchases use Stars; the independent website supports BNB/MSH payments to merchants. |
| Website workspace | Email-code registration, password login, security, bot management, linked-wallet balances, service orders, contract and market information, service burn records. |

All bot features are off by default. Owners privately use buttons to read instructions, configure and enable features. The website manages accounts, bot connections, group authorization, purchases and records. Personal and group ID tools work after connection without buying service.

The website and bot system interfaces support Chinese, English, Korean, German, Japanese, Spanish, Portuguese, French and Russian. User product text, keyword replies, codes and AI output remain in their original language. The site supports phones, tablets and computers. The original whitepaper was published in Simplified Chinese.

> Monitoring covers only sources the user is entitled to access and has authorized. It does not provide arbitrary access to private groups. Hosting does not remove API charges, gas costs or third-party restrictions.

## 03 Identity, permissions and access

| Identity | Purpose and limits |
| --- | --- |
| Email account | Manages its own bots, settings, products and orders. Registration requires an email code; login uses a password. An authenticator can be enabled. |
| Linked wallet | Proves address control and signs payments on the current device. The account stores the association, but phones and computers do not share signing permission. |
| Telegram owner | Sends the website's one-time code privately to the connected bot to establish management authority. Multiple bots may verify the same TG ID. |
| Members and buyers | Use enabled public features or retrieve their own purchases. They cannot access owner API keys, management settings or unsold inventory. |

### From registration to operation

- Verify an email address and connect a bot token you are authorized to control.
- Copy the website's single-use binding code to that bot's private chat within 10 minutes. Codes sent in groups do not bind an owner.
- Configure features through bot buttons. Make the bot and verified owner administrators of the target group, then verify group authorization on the website.
- Each account may claim one basic one-hour trial, with up to 2 groups and 100 ordinary replies. Trials do not enable store collection. Buy service time and group capacity for regular use.

Accounts have no fixed bot-count cap, but connection rates, queues and resources remain limited. Each bot is billed, configured and authorized independently. Removing a connection stops hosting and clears access credentials while retaining necessary accounting records. Pending payments and store support obligations must be resolved first. Removal does not delete the Telegram bot itself.

## 04 MSH on-chain identity

These values were read and cross-checked through two independent RPC nodes at the same confirmed BSC block.

| Item | Snapshot value |
| --- | --- |
| Name / symbol | MSH / MSH |
| Network / Chain ID | BNB Smart Chain / 56 |
| Token contract | 0x5cf49332de35899d6852a28a8bbbd8727578ffff |
| Decimals | 18 |
| totalSupply | 1,000,000,000 MSH |
| Reported maxSupply | 1,000,000,000 MSH |
| Distribution quote asset | WBNB: 0xbb4cdb9cbd36b01bd1cbaebf2de08d9173bc095c |
| Verified block | 129537706 |
| Block time | 2026-10-24 23:27:16 UTC+8 |

totalSupply and maxSupply are interface values from this reading, not an audit of minting, upgrades, pauses, blacklists or governance powers. A standard owner() read did not succeed; this is not evidence that ownership was renounced.

Issuance allocation, team holdings, reserve uses and vesting have not been announced. Public balances do not fully identify who controls each address. This document does not invent team percentages or lock periods.

> Identify MSH by its full contract address. BSC wallet support or Binance BNB/USDT market data does not mean a Binance exchange or Alpha listing, or third-party endorsement.

## 05 Service pricing

The service benchmark is fixed and converted to token units dynamically. Purchases cover a fixed duration; the platform does not automatically debit a wallet for renewal.

| Asset | Per bot and each 2 authorized groups |
| --- | --- |
| MSH | MSH equivalent to 0.1 USDT per 30 days, using a valid quote when the order is created. |
| BNB | 0.001 BNB per 30 days, scaled by duration and group capacity. |

Let G be purchased group capacity, a multiple of 2; T the purchased seconds; and P the USDT price of 1 MSH. An hour is 3,600 seconds, a day 86,400 seconds, a month 30 days and a year 365 days. One purchase may cover up to 10 years.

```
MSH = 0.1 × (G / 2) × (T / 2,592,000) ÷ P
BNB = 0.001 × (G / 2) × (T / 2,592,000)
```

Amounts round up to the smallest payment unit. Manual transfers add a unique identification suffix, shown in the full amount before payment; do not remove it.

For illustration only, at 1 MSH = 0.000005 USDT, 30 days for 2 groups costs a base 20,000 MSH; 4 groups costs 40,000 MSH. Corresponding BNB base prices are 0.001 and 0.002 BNB. This is a hypothetical example, not a current quote.

Orders lock their amount for 30 minutes. Missing, stale or failed quotes block new MSH quotes; old values must not be presented as live. Existing payments are checked against the original order. During active paid time, renewals must retain the same group capacity; change capacity after expiry and remove excess authorizations before reducing it.

> Pausing does not freeze purchased time or cause an automatic refund. Paid features stop at expiry. Remaining time does not transfer when a bot connection is deleted. Future price changes must be visible before purchase; existing orders are verified against their recorded terms.

## 06 Payments and service burns

Service payments, transaction-tax distribution and merchant sales are separate flows.

- Wallet connection: log in, bind the paying address, create an order and approve the BSC transfer in your wallet. The platform holds no wallet private key and cannot sign on another device merely because the account is linked.
- Transfer without connection: log in, verify the bot owner, create an order and send the correct asset and full amount on BSC from an ordinary wallet; submit the transaction hash. The QR contains only the address, not an automatically filled asset, network or amount.

Two BSC nodes verify the transaction, actual receipt and order match. Service activates after at least 30 block confirmations. Failed, irregular or late-mined payments follow their order status; screenshots and repeated submissions cannot replace verification.

| Flow | Recipient |
| --- | --- |
| MSH bot service | Burn address: 0x000000000000000000000000000000000000dEaD |
| BNB bot service | Platform address: 0xb70f823fd4d4772fa6f70ff9c7bb3b7c80f7ef99 |
| Digital products | Stars go to the merchant's bot; website BNB/MSH goes to the merchant's verified wallet. Product payments do not go to the platform service burn address. |

The overview's cumulative confirmed platform-service burn counts only verified MSH service settlements. A manual transfer's identification suffix accompanies the service payment to the same burn address. Unconfirmed amounts, external transfers, transaction-tax buyback burns and product payments are not automatically included.

> Sending tokens to 0x…dEaD does not itself prove that ERC-20 totalSupply decreased, or imply a price increase. The payer bears on-chain gas.

## 07 Holder fee distribution

1,000,000 MSH is the participation threshold. The 30% setting is a fee-allocation weight, not each user's rate of return.

| Parameter | Configuration at the verified block |
| --- | --- |
| minShare | 1,000,000 MSH |
| rateHolder | 30% |
| rateFounder | 55% |
| rateBurn | 15% |
| rateLiquidity | 0% |
| Post-migration buy / sell tax | buyFeeRate = 100; sellFeeRate = 100. In basis points, each is 1%. |

Eligible addresses share the holder pool according to valid shares recorded by the contract; each eligible holder does not receive 30% individually. Settlement depends on active distribution routes, total valid shares, thresholds, available funds and execution.

If 0.3 quote units actually enter the holder pool and an address owns 10% of valid shares, its portion is 0.03 units. This explains a proportion, not expected volume or returns.

These weights apply only to this token's tax-distribution mechanism, not all website revenue or launch-platform fees, and exclude gas. There is no commitment to distribute 30% of website BNB service receipts. Spending MSH reduces a holder's balance; qualifying once does not guarantee future eligibility.

> The 30% weight is not yield. Distributions may be zero. Holding is not staking, vesting or permanent free bot access; no fixed return, APY or recovery of capital is promised.

## 08 Distribution conditions and transparency

Readable settings are not proof of actual receipt; consult the contract and on-chain records.

| Condition | Snapshot and interpretation |
| --- | --- |
| quote | WBNB. The actual claim form and interaction depend on the contract and launch-platform interface. |
| minDispatchQuote | 0.01 WBNB, converted at 18 decimals. Reaching the threshold does not mean every holder is immediately paid automatically. |
| minDispatch | 50,000 MSH for post-migration token-tax conversion; distinct from the quote-asset threshold. |
| Phase | vault.phase() = 1, defined as Trading in OpenFour. Taxation and execution paths differ by phase. |
| founder | 0xb70f823fd4d4772fa6f70ff9c7bb3b7c80f7ef99 |

OpenFour's reference mechanism includes claimableFee(address) queries and claimFee() claims. Use the launch platform or a trusted interface after checking the contract address. An estimated website amount does not replace on-chain confirmation. This website does not currently promise automatic claims on holders' behalf.

A minimum balance alone does not guarantee valid shares. Pools, vaults, the token itself, the zero address, burn addresses and excluded addresses may not participate. Holdings through exchanges or collection addresses also depend on the relevant platform's rules.

This edition cross-checks principal public interface parameters and references OpenFour documentation. It is not an independent security audit, a complete permissions analysis or a full comparison of deployed bytecode with reference source. No paid or claim transaction was made merely to verify it.

> Launch-platform documentation may vary by generation. The actual contract's block-specific reads, receipts and events govern MSH's state and execution; another token's defaults must not be substituted.

## 09 Hosting, security and operating limits

The website is an application operated by the project. On-chain tokens and payments do not make the entire platform decentralized.

Bots, API settings, products, inventory, orders and operations are controlled by website-account ownership. Bot tokens, AI keys and product codes are encrypted. Users cannot borrow another account's API or read other users' inventory or deliveries. Sensitive operator actions require an authenticator and audit records.

The platform does not collect wallet seed phrases or private keys. Hosting requires bot tokens; AI calls require user-supplied API credentials. Encryption does not remove server-compromise, authorized-person misuse, third-party leakage or configuration risks. Users bear their own AI provider bills.

Shared processes, durable task queues, request limits and sending quotas avoid a dedicated process for every bot. No fixed account bot cap does not mean unlimited concurrency, messages or computation. Telegram permissions, rate limits, RPC, email and API failures may affect service.

Daily encrypted backups and restore verification retain the latest 14 copies; an encrypted copy is saved on the current computer. Health checks support repeated-failure alerts and recovery notices. Continuous automatic offsite backup is not connected. Monitoring shares the server, so its email alerts cannot be relied on during total power or network loss.

> Custodial website deposits and withdrawals are not open. Current purchases use wallet payment or manual transfer without connection and need no website balance top-up. No capital custody, deposit interest or platform-asset backstop is promised.

## 10 Disclosures and next steps

Stabilize existing services first and disclose new work according to actual progress.

| Item | Disclosure status |
| --- | --- |
| Issuance allocation and reserves | Not announced. |
| Team holdings and vesting | Not announced. No claim of zero team holdings or completed vesting. |
| Operating entity and team | Not fully disclosed. The official information entry is the website listed here. |
| Independent audit | No independent report published; using a contract template is not an audit. |
| Liquidity and listings | No guaranteed depth, exchange listing or third-party listing arrangement. |
| Governance and staking | Token governance, staking yield and permanent free service through staking are not live. |

Completed work includes the website and accounts, bot connection and private owner verification, common automation, group capacity, MSH/BNB service payments, burn records, market display, digital store and multilingual interfaces.

- Fix real usage issues and improve payment-exception, support and operating information.
- Test capacity, permissions and isolation; improve independent monitoring and offsite backup.
- Disclose allocation, team, vesting and contract permissions; assess external security review.
- Consider a fee-distribution query interface after sufficient evidence and verification, without promising automatic claims, returns or a release date.

> This roadmap states priorities, not completed work, delivery dates or token returns. Changes to fees, permissions or money flows should be publicly explained and shown before purchase.

## 11 Risks, verification and version

Service rules and on-chain facts matter more than price expectations.

MSH price, liquidity and volume may vary sharply, and distributions may be zero. Transaction tax, gas, slippage and launch-platform fees affect trading costs. On-chain transactions are generally irreversible; the wrong asset, chain, address or amount may cause loss.

Contracts, protocols, wallets, the website server and user APIs carry risks. Permission changes, migration, platform rules, congestion or service termination may affect access. MSH grants no company equity, debt claim or fixed repayment promise. Users must check requirements applicable to their location.

Snapshot: BSC / 56; block 129537706; time 2026-10-24 23:27:16 UTC+8. Two nodes cross-checked the same block hash and principal readings.

```
0x37d3c2381b1995454bfbed9d9c3273caa67644b5273be7274c6b299114724ef6
```

- [Official website](https://mshbot.top/)
- [MSH contract explorer](https://bscscan.com/token/0x5cf49332de35899d6852a28a8bbbd8727578ffff)
- [Four.Meme token page](https://four.meme/token/0x5cf49332de35899d6852a28a8bbbd8727578ffff)
- [OpenFour tax-distribution mechanism](https://github.com/four-meme-community/openfour-docs/blob/main/docs/mechanisms/tax-token.md)
- [Telegram Stars documentation](https://core.telegram.org/bots/payments-stars)

Version 1.0 was published on 2026-10-24 in Simplified Chinese. HTML, PDF and editable Markdown are generated from one language source. On-chain figures are snapshots; prices and operating states change. Revisions should explain changes rather than present a static PDF as real-time data.

> This document explains the product and disclosed mechanisms. It guarantees no fixed return, token price, buyback or exchange listing. Referencing mechanism documentation does not constitute an independent audit of this deployed contract.