MSH Whitepaper

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.

Products available in this edition

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

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.

Identity, permissions and access

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.

MSH on-chain identity

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

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.

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.

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.

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.

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.

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.

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.

Distribution conditions and transparency

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

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.

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.

Disclosures and next steps

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

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.

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
• MSH contract explorer
• Four.Meme token page
• OpenFour tax-distribution mechanism
• Telegram Stars documentation

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.