chAIn CoinWhitepaper
An AI Market-Making Vault and NVDAb
Tax Revenue Distribution Protocol on BNB Chain
Contents
- Summary
- 01 Project Overview
- 02 Protocol Architecture
- 03 Assets and Valuation
- 04 AI Decisions and Execution
- 05 Transaction Tax and Distribution
- 06 Participation Positions and Weights
- 07 Claims, Locking, and Reinvestment
- 08 Referral Weighting
- 09 Complete Calculation Example
- 10 Permissions, Disclosures, and Risks
- Appendix
Summary#
chAIn Coin combines AI action selection, smart contract execution, and transaction tax distribution in an on-chain vault protocol with defined uses of funds, a constrained execution scope, and an explainable basis for distributions.
Users make a non-redeemable BNB contribution to establish an independent participation position. The AI Market-Making Vault obtains action selections through Flap AI Oracle, and the project contract executes them under predefined rules. The action set is limited to Buy Back Tokens, Sell Tokens to Replenish Funds, Burn Tokens, and Hold and Observe.
The project plans to use chAIn/NVDAb as its trading pair. Both the chAIn buy tax and sell tax are set at 3%. Of the distributable net tax revenue actually received by the project, 90% goes to the Dividend Vault and 10% to development and operations. Eligible participation positions receive NVDAb, while distribution progress is recorded at its BNB-equivalent value when credited.
A position's base weight changes from 2x to 1x as its cumulative distribution accounting value increases. Once that value reaches twice the initial contribution accounting value, the position exits subsequent distributions. In the subsequent stage, 80% is claimable and 20% is conditionally locked. The locked portion can be unlocked through qualifying reinvestment within 3 days after exit. Eligible referrals can provide additional weight in the initial stage; holding chAIn does not itself increase position weight.
Version note: This document describes the confirmed protocol design; it does not mean that all functions have been deployed or made available. Development status follows the information recorded in V1.1. This revision primarily changes content structure, terminology, and presentation. Chapter 10 describes deployment scope and outstanding disclosures.
01 Project Overview#
1.1 Background and Positioning#
The name chAIn combines chain and AI and was inspired by CZ's expression “BNB + AI = BNB chAIn.” The project uses BNB Chain as its issuance and execution environment, bringing AI action selection and applications of tokenized real-world assets into specific vault and distribution processes.
BNB + AI + NVDAb = chAIn is the project's conceptual expression: BNB is used for participation and strategy funding, AI for action selection, and NVDAb for the target trading pair's quote asset, tax settlement, and actual distributions. The expression is neither a price relationship nor a conversion formula.
1.2 Design Principles#
- A defined decision scope. The model selects only from actions exposed by the contract. Its role in decision-making does not grant arbitrary authority to change the protocol.
- Distinct uses of funds. Participation funds enter the AI Market-Making Vault; actual distributable tax revenue is settled through the Dividend Vault.
- Explainable distribution rules. Position weights, cumulative distribution accounting values, locking conditions, and exit caps use a consistent accounting basis.
chAIn Agent embodies the project's narrative around market observation, strategic action, and holder confidence. Its actual execution capabilities are limited by the action set and contract rules described in this whitepaper.
02 Protocol Architecture#
2.1 Participants and the Two Vaults#
The protocol separates the responsibilities of the AI Market-Making Vault and Dividend Vault. A user's participation positions are recorded separately from the chAIn balance in their wallet.
| Participant or module | Responsibility |
|---|---|
| Participant | Contributes BNB to establish a position and obtains distribution eligibility under the position rules |
| AI Market-Making Vault | Manages participation funds and strategy assets; executes market actions permitted by the rules |
| Flap AI Oracle | Connects to model services and returns an action selection within the permitted execution scope |
| Project contract | Initiates requests, processes callbacks, and executes actions and accounting under predefined rules |
| Trading market | Supports chAIn/NVDAb trading, producing market information and applicable taxes and fees |
| Dividend Vault | Receives participants' share of NVDAb and records and settles position distributions |
Solid gold lines show participation or strategy funds, solid green lines show distribution assets, and dashed gray lines show decision information. Fund flows and information flows should be read separately. Specific conversion routes depend on deployment configuration.
2.2 Participation Fund Flow#
User contributes BNB → AI Market-Making Vault → market strategies under contract rules. Each contribution establishes an independent position for calculating distribution eligibility and progress.
Rule definition: BNB contributions are non-redeemable. A position record does not represent a BNB balance that the user can withdraw from the vault, nor does it create an obligation for the protocol to return that contribution.
With an NVDAb liquidity pool, strategies involve conversions between BNB, NVDAb, and chAIn. A buyback may convert BNB to NVDAb through a supported route before purchasing chAIn. A sale may first receive NVDAb and then convert it to BNB under the rules. Supported routes, conversion conditions, and accounts bearing the costs are deployment details.
2.3 Tax and Distribution Flow#
Taxable trades → tax collection and settlement → distributable NVDAb received by the project → Dividend Vault and development/operations account. The Dividend Vault records and settles claimable NVDAb and conditionally locked NVDAb for eligible positions.
Participation funds are not used directly to pay distributions to other positions. Distributions are based on assets actually received; accrued taxes or expected trading volume do not increase claimable balances. If the AI Market-Making Vault's own trades are taxable, the resulting tax revenue indirectly originates from vault expenditure and should be distinguished from incremental tax revenue generated by external trading.
03 Assets and Valuation#
3.1 Roles of the Three Assets#
| Asset | Role in the protocol | Accounting boundary |
|---|---|---|
| BNB | User participation, strategy funding, and position accounting unit | The initial contribution is non-redeemable; an accounting value is not a withdrawable BNB balance |
| chAIn | Project token, market-traded asset, and vault strategy asset | Holding tokens does not increase position weight; holding alone does not automatically qualify for position distributions |
| NVDAb | Target pool quote asset, tax settlement, and actual distributions | Recorded and distributed by token quantity; its market value can change |
3.2 Designated NVDAb Asset#
| Field | Information |
|---|---|
| Name used in this document | NVDAb |
| On-chain name and symbol | NVIDIA Corp / NVDAB |
| Network and decimals | BNB Chain / 18 |
| Contract address | 0x02fca66c1d1afb4e2a7884261eb00f63598a7436 |
This information carries forward the designated contract query results recorded in V1.1. Identify the asset by its network and contract address. This is the NVDAb address, not the chAIn contract address. See the designated contract link in Appendix C [6].
3.3 Cross-Asset Accounting#
The protocol uses BNB as its accounting unit and NVDAb as the actual distribution asset. Let the initial contribution be P BNB, the NVDAb quantity credited in distribution t be qₜ NVDAb, and the corresponding valuation rate be rₜ BNB/NVDAb:
Distribution accounting value for that credit = qₜ × rₜ BNB
Cumulative distribution accounting value C = sum of all credited accounting values
Conversion takes place when the protocol credits a distribution, not when the user clicks to claim it. Historical conversion values already credited remain fixed. Subsequent changes in the NVDAb price do not retroactively change position progress.
Calculation example: If an NVDAb distribution is equivalent to 0.1 BNB when credited, position progress increases by 0.1 BNB. Later changes in that asset's market value affect the user's actual asset value, but do not change the recorded accounting value of 0.1 BNB.
Cross-asset valuation still requires a corresponding price source, sampling window, validity period, and abnormal-price handling procedure. An AI action-selection service cannot replace an asset price source. Related outstanding disclosures are listed in Chapter 10.
3.4 Scope of Asset Rights#
This document makes no guarantee regarding the designated NVDAb issuer, stock-backing ratio, custody arrangements, redemption eligibility, or treatment of corporate actions. Any such rights must be verified against the issuer's official documentation matching this contract address; the current version does not include such documentation.
“NVDAb distributions” means distributing chAIn transaction tax revenue in NVDAb. It does not mean that NVIDIA pays corporate profits to chAIn participants. An NVDAb pool does not automatically grant chAIn holders NVIDIA equity, redemption rights over that asset, or a fixed conversion right against pool reserves. The trading pair also does not automatically establish a fixed peg between chAIn and NVIDIA's stock price.
04 AI Decisions and Execution#
4.1 Decision Process#
The project connects to model services through Flap AI Oracle. Executable actions and related rules are encoded in the project contract. The Oracle returns an action selection, and the project contract handles the corresponding operation. See Appendix C [1] for the platform interface process.
- Request initiation. The project contract submits decision information, available actions, and model selection, and pays the Oracle request fee.
- Model inference. The Oracle backend calls the model off-chain, processes the input, and returns an action identifier within the valid range.
- Callback execution. The Oracle returns the result on-chain, where the project contract handles the selected action under predefined rules.
- Process records. Requests, returned results, and IPFS references to inference materials can be queried.
Model inference occurs off-chain. On-chain requests, callbacks, and execution records support traceability; they do not prove that model judgments are correct or that a strategy is profitable.
4.2 The Four Actions#
| Action | Function |
|---|---|
| Buy Back Tokens | Uses vault assets permitted by the rules to buy chAIn |
| Sell Tokens to Replenish Funds | Sells chAIn held by the vault to replenish strategy funds |
| Burn Tokens | Burns chAIn held by the vault under the rules |
| Hold and Observe | Maintains the current asset allocation without executing trades or burns |
The four actions are alternative branches, not a cycle executed in a fixed order. The corresponding contract version and strategy parameters specify action mappings, fund allocation ratios, triggers, and limits. This document does not assume that AI outperforms human judgment or fixed rules. Generating apparent trading volume cannot substitute for genuine market demand.
4.3 Permissions and Exception Handling#
The Oracle returns an action identifier; it does not automatically gain authority to change tax rates, distribution caps, allocation ratios, or other protocol parameters. The model's scope depends on the operations exposed by the project contract.
Encoding rules in a contract does not mean those rules are permanently immutable. Upgrade, pause, parameter adjustment, and fund management permissions should be disclosed with deployment information. Handling of failed requests, delayed results, failed callbacks, and expired decisions is governed by the published description of the corresponding contract version.
05 Transaction Tax and Distribution#
5.1 Tax Rates and Settlement#
Both buy and sell taxes are set at 3%. Applicability, conditions for taxation during the bonding-curve phase, duration, and exempt addresses are issuance configuration details. This does not imply that every transfer is charged at the same rate.
Under Flap's tax settlement mechanism, taxes can be collected directly in the quote asset during the bonding-curve phase when the relevant configuration is enabled. After migration to a DEX, taxes generally accumulate first in the project token and are converted into the quote asset once liquidation conditions are met. See Appendix C [2][3][4].
Tax accrual on a trade and receipt of NVDAb by the Dividend Vault may occur at different times. Conversion can incur platform fees, applicable integration fees, DEX fees, transaction taxes, and slippage. These must be accounted for according to the actual route.
5.2 Allocation of Net Tax Revenue#
Let T NVDAb be the distributable net tax revenue actually received by the project after applicable platform fees and other deductions:
| Destination | Share | Quantity allocated |
|---|---|---|
| Dividend Vault | 90% | 0.9 × T |
| Development and operations | 10% | 0.1 × T |
Calculation example: If the project actually receives 100 distributable NVDAb, 90 NVDAb goes to the Dividend Vault and 10 NVDAb to development and operations.
3% is the transaction tax rate; 90%/10% is the internal allocation of the project's distributable net tax revenue. A user's net distribution cannot simply be equated with 2.7% of trading value.
5.3 Revenue Sources and Distribution Conditions#
Distributions depend on actual trades and assets received. Distributions may decrease or pause if market demand is insufficient, liquidity declines, or settlement routes become unavailable.
AI Market-Making Vault strategies, referral bonuses, and position exits affect the use of funds or relative distribution shares. They do not guarantee enough revenue to cover all position contributions. Holding chAIn without an eligible participation position does not automatically confer eligibility for position distributions under this protocol.
06 Participation Positions and Weights#
6.1 Independent Position Records#
Each BNB contribution separately records its initial amount, cumulative distribution accounting value, claimable NVDAb, conditionally locked NVDAb, effective weight, and exit status. A new contribution creates a new position without resetting the historical records of existing positions.
6.2 Stages and Base Weights#
Let P be the initial BNB contribution and C the cumulative historical BNB-equivalent value of credited distributions:
| Cumulative accounting value | Position stage | Weight and distribution |
|---|---|---|
| C < P | Initial stage, informally “before break-even” | 2x base weight, with eligible referral bonuses available |
| P ≤ C < 2P | Subsequent stage, informally “after break-even” | Uniform 1x weight; initial-stage bonuses no longer apply |
| C reaches 2P | Distribution cap reached, informally “exit” | Exits subsequent distributions and receives no new distributions |
The horizontal axis represents cumulative distribution accounting value, not time. Reaching P means only that historical credited conversion values have reached the initial contribution accounting value. It does not mean that BNB principal has been redeemed or that the NVDAb held still has that current market value.
6.3 Relative Weights and the Distribution Cap#
Distributions are allocated in proportion to the weights of eligible positions. 2x is a relative weight, not a fixed return multiple or a rate of receipt. Actual effective weight depends on position size, stage, and eligible referral bonuses. Deployment parameters specify how it is calculated and updated.
Calculation example: A batch has 30 NVDAb to distribute. Two positions have final effective weights of 2 and 1, respectively, and neither crosses a stage boundary nor reaches its exit cap. They receive 20 and 10 NVDAb, respectively. This example illustrates relative shares only.
Each position's cumulative distribution accounting value is capped at 2P BNB, including both claimable and conditionally locked portions. New allocations stop when the cap is reached. The cap is not guaranteed to be reached; insufficient distributions may leave a position below P or 2P for an extended period or indefinitely.
07 Claims, Locking, and Reinvestment#
7.1 Treatment of Subsequent-Stage Distributions#
The portion of cumulative distribution accounting value above P is treated as follows:
| Portion | Share | Treatment |
|---|---|---|
| Claimable distribution | 80% | Credited as claimable NVDAb |
| Conditionally locked distribution | 20% | Credited as conditionally locked NVDAb for the corresponding position |
Both portions count toward cumulative progress. A distribution crossing P is split into initial-stage and subsequent-stage portions for separate treatment. On reaching 2P, the allocation is limited to the remaining allowance; no excess is credited to the position.
7.2 Unlocking Window and Threshold#
After a position reaches 2P and exits, the user has a 3-day reinvestment unlocking window. Locked NVDAb also records its BNB-equivalent value at the time of credit. These values accumulate to form the unlocking threshold L BNB.
Qualifying reinvestment of at least L BNB within the specified window unlocks all locked NVDAb for that position. Reinvestment below the threshold does not unlock a proportional portion. If the threshold is not met within the window, the locked balance returns to the Dividend Vault.
7.3 Relationship Between Old and New Positions#
Reinvestment funds enter the AI Market-Making Vault and establish a new position. The unlocked payout consists of NVDAb already recorded for the old position. The new contribution does not directly fund distributions to the old position.
Reinvested BNB is also non-redeemable and should be included in the individual's actual contribution cost. On-chain timing and triggers, attribution of qualifying reinvestment, and handling of multiple positions will be disclosed with the adaptation feature documentation.
08 Referral Weighting#
8.1 Conditions for Referred Participants#
A user who binds a referrer before their first participation and makes an initial contribution of at least 0.1 BNB receives a +0.1x bonus on that first position during the initial stage. With only this bonus, the first position has an initial-stage weight of 2.1x, returning to 1x upon reaching P.
8.2 Referrer Conditions and Cap#
For every 1 BNB in eligible positions that have not exited brought in by a referrer, the referrer's own positions that have not yet reached P receive a +0.1x bonus, capped at +1.0x.
| Referred eligible positions that have not exited | Additional referrer weight |
|---|---|
| 1 BNB | +0.1x |
| 3 BNB | +0.3x |
| 5 BNB | +0.5x |
| 10 BNB or more | +1.0x cap |
Updates to eligible amounts, treatment of non-whole amounts, and stacking of applicable referral bonuses follow the published contract and parameter documentation. Holding chAIn does not increase the distribution weight of participation positions.
8.3 Scope of the Mechanism#
The referral mechanism has no multilevel commissions and does not directly deduct a commission from a specific referred participant's distributions. When total distributable tax revenue is fixed, referral bonuses change relative shares among eligible positions; they do not generate additional tax revenue.
09 Complete Calculation Example#
9.1 Assumptions#
Assume a user contributes 1 BNB to establish a position and that the position ultimately receives NVDAb with a total historical credited conversion value of 2 BNB. The following explains stage and locking rules. It sets no receipt schedule and makes no revenue forecast.
9.2 From Participation to Exit#
| Step | Position record or treatment |
|---|---|
| Participation | Contributes 1 BNB; P = 1; the contribution is non-redeemable |
| Initial stage | C < 1; base weight is 2x, with referral bonuses where eligible |
| Reaches P | Cumulative historical credited conversion value reaches 1 BNB; weight returns to 1x |
| Subsequent stage | Further distributions are treated as 80% claimable and 20% conditionally locked |
| Reaches 2P | C = 2; exits subsequent distributions and enters the 3-day reinvestment unlocking window |
9.3 Distribution Records at Exit#
| Item | Accounting value at historical credit prices |
|---|---|
| Initial-stage claimable distributions | 1 BNB |
| Subsequent-stage claimable distributions | 0.8 BNB |
| Subsequent-stage conditionally locked distributions | 0.2 BNB |
| Cumulative accounting value triggering exit | 2 BNB |
The directly claimable portion has a total historical conversion value of 1.8 BNB. Additional NVDAb with a historical conversion value of 0.2 BNB is subject to unlocking conditions. All actual assets are NVDAb, and their market value when claimed may be higher or lower.
9.4 Reinvestment Treatment#
In this example, the unlocking threshold L is 0.2 BNB. The user must contribute at least another 0.2 BNB within 3 days after exit and satisfy the relevant qualifying reinvestment conditions to release the entire locked balance. The new contribution creates a new position without resetting the old position's cumulative progress.
If the threshold is not met within the window, the locked NVDAb returns to the Dividend Vault. This example does not guarantee that a position will receive enough distributions to reach any stage.
10 Permissions, Disclosures, and Risks#
10.1 Scope of This Version#
The following statuses carry forward the information recorded in V1.1. V1.2 revises documentation and the reading experience; it does not establish any new deployment or security validation conclusion.
| Work item | Recorded status |
|---|---|
| Basic vault and position mechanism | Basic development completed |
| Flap AI Oracle action selection | Integration completed; action rules encoded in the project contract |
| NVDAb target asset | Contract address designated |
| NVDAb conversion, distributions, and BNB valuation | In adaptation development; not yet available as a complete feature |
| Launch configuration, deployment, and security materials | To be disclosed separately at the corresponding launch stage |
Feature availability should be assessed together with validation results for NVDAb route adaptation, price-source configuration, distributions crossing stage boundaries, reinvestment unlocking, and tax settlement. Deployment materials and launch announcements determine the specific scope of availability.
10.2 Outstanding Disclosures#
| Category | Details to be specified |
|---|---|
| Issuance and deployment | Total supply, initial allocation, reserves, LP ownership and locking, chAIn and vault addresses |
| Taxes, fees, and routes | Tax duration, exemptions, conversion routes, platform and execution fees, and accounts bearing costs |
| Strategy parameters | Action mappings, triggers, execution ratios, and limits |
| Cross-asset valuation | Price source, sampling window, validity period, and abnormal-price handling |
| Weight updates | Updates to eligible referral amounts, treatment of non-whole amounts, bonus stacking, and update timing |
| Reinvestment handling | On-chain timing and triggers, attribution of qualifying reinvestment, and multiple-position handling |
| Administration and exceptions | Upgrade, pause, parameter modification, fund management permissions, and Oracle exception handling |
| Security materials | Contract versions, assessment scope, and publicly available security validation information |
Undisclosed details cannot be inferred from platform conventions. Rule descriptions should match the corresponding contract version. Any discrepancies should be explicitly explained and corrected.
10.3 Records and Traceability#
Public materials and future participant views should distinguish vault balances, AI request and execution records, actual tax settlement, position progress, and claimable and locked assets. Asset quantities, historical credited conversion values, and current indicative market values should be displayed separately, without combining them into a single “return” figure.
These record-display objectives do not mean that the corresponding interfaces are already available. This whitepaper is not a code audit report. Flap's official deployment information is used only to verify platform interfaces and does not replace the project's own deployment information. See Appendix C [5].
10.4 Risks and Protocol Boundaries#
| Risk | Impact on participants |
|---|---|
| Non-redeemable contributions | Initial BNB cannot be recovered from the AI Market-Making Vault; distributions may not cover the contribution |
| Insufficient distribution revenue | Reduced or discontinued market trading may prevent a position from reaching P or 2P |
| Asset price changes | Relative price changes among BNB, NVDAb, and chAIn affect valuation and actual asset value |
| NVDAb issuance and rights | Issuance, asset backing, custody, transfer, or redemption restrictions may affect conversions and distributions |
| Liquidity and conversion | Slippage, fees, declining liquidity, or unavailable routes may reduce settlement quantities or prevent trades |
| AI and Oracle | Data anomalies, incorrect decisions, service interruptions, delays, or callback failures may affect strategy execution |
| Price sources | Stale, distorted, or manipulated prices may cause errors in cross-asset distribution valuation |
| Contracts and administrative permissions | Code defects, external calls, upgrades, or parameter changes may affect asset security and protocol behavior |
| Conditional locking | If qualifying reinvestment is not completed in time, the corresponding locked distributions return to the vault and cannot be claimed by the user |
| Legal and platform rules | Requirements for tokens, vaults, tax distributions, and assets across jurisdictions may restrict participation |
The protocol does not promise capital protection, fixed returns, a fixed distribution schedule, price appreciation, or a fixed break-even period. AI decisions, weight adjustments, and the exit mechanism cannot eliminate these risks, nor do they independently demonstrate sustainable protocol revenue. Participants should make their own assessment in light of contribution size, non-redeemability, locking conditions, asset volatility, and applicable local requirements.
Appendix#
A Parameter Index#
| Parameter | Confirmed rule | Main text |
|---|---|---|
| Participation asset | BNB; contributions are non-redeemable | Chapter 2 |
| Target trading pair | chAIn/NVDAb | Chapters 2, 3 |
| AI action scope | Buy Back Tokens, Sell Tokens to Replenish Funds, Burn Tokens, Hold and Observe | Chapter 4 |
| Buy / sell tax | Both 3% | Chapter 5 |
| Net tax revenue allocation | 90% Dividend Vault; 10% development and operations | Chapter 5 |
| Actual distribution asset / accounting unit | NVDAb / BNB | Chapter 3 |
| Initial / subsequent base weight | 2x / 1x | Chapter 6 |
| Cumulative distribution accounting cap | 2P, including claimable and conditionally locked portions | Chapter 6 |
| Subsequent-stage treatment | 80% claimable; 20% conditionally locked | Chapter 7 |
| Reinvestment unlocking window / threshold | 3 days after exit / qualifying reinvestment of at least L BNB | Chapter 7 |
| Referred participant bonus | Initial contribution ≥ 0.1 BNB; +0.1x during the eligible first position's initial stage | Chapter 8 |
| Referrer bonus | +0.1x per 1 BNB in eligible positions that have not exited; capped at +1.0x | Chapter 8 |
| Token holdings and position weight | Holding chAIn does not increase position weight | Chapters 3, 8 |
B Terms and Symbols#
| Term / symbol | Definition |
|---|---|
| Eligible participation position | An independent position that remains eligible for distributions under its participation record and protocol rules |
| P | Initial contribution for one position, in BNB |
| C | Cumulative historical BNB-equivalent value of credited distributions |
| qₜ / rₜ | NVDAb quantity credited in distribution t / corresponding price in BNB/NVDAb |
| T | Distributable net tax revenue actually received by the project, in NVDAb |
| L | Unlocking threshold formed by the cumulative BNB-equivalent values recorded when locked NVDAb was credited |
| Break-even | Informal term for C reaching P; does not imply principal redemption or a guarantee of current market value |
| Exit | Informal term for leaving new distributions after C reaches 2P |
| Distribution | The project's allocation of NVDAb under position rules; not a distribution of NVIDIA corporate profits |
| Hold and Observe | One of the AI's available actions: maintain the current asset allocation without trading or burning |
C References#
- Flap AI Oracle
- Flap Token Launch Interface
- Flap Tax Liquidation Mechanism
- Flap Protocol Fees
- Flap Official Deployment Addresses
- Designated NVDAb Contract
These references are carried forward from the existing whitepaper to explain technical and asset interfaces. External documents may change. Citation does not imply that the relevant organizations have reviewed or endorsed chAIn.
D Version History#
| Version | Date | Revision scope |
|---|---|---|
| V1.2 | 2026-09-11 | Reorganized the outline, standardized terminology, added mechanism diagrams and a parameter index, and improved reading and export; existing mechanism parameters remain unchanged |
| V1.1 | 2026-09-10 | Removed token-holding weighting; limited AI actions to Buy Back Tokens, Sell Tokens to Replenish Funds, Burn Tokens, and Hold and Observe |
| V1.0 | 2026-09-07 | Initial formal Chinese edition |