> For the complete documentation index, see [llms.txt](https://www.degenbot.wiki/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://www.degenbot.wiki/release-verification.md).

# Release verification — owner review

Owner-facing checklist for verifying this guide against the deployed bot before publication.

{% hint style="warning" %}
**Owner review—not a verified release specification.** This page is hidden from navigation, not access-controlled. Do not store credentials, customer records, or confidential deployment details here.
{% endhint %}

### Status of this edition

The September 9, 2026 guide covers the alerts-only Degen Trading Bot. It is written for members rather than developers operating the server. It contains 30 reader-facing pages, including section introductions, practical examples, performance explanations, and account help.

The guide has not been checked against the current private repository or a live member account. The available GitHub connection did not provide access to the repository. The product-specific basis is the owner's current description, the reported stream names, and the reported `/performance` command. Historical Ninja Bot documentation is preserved in the archive, not treated as the current specification.

Writing these pages did not change bot code, strategy, model parameters, subscriptions, or deployment configuration. The content remains in a GitBook change request, not a published release.

### 1. Verify identity and access

Confirm the exact official Telegram username and bot link, the membership/product URL, and the support destination. Add verified links to the welcome, quick-start, membership, and help pages. Do not derive a bot username from a brand name.

Use a clean member account to test the actual onboarding route. Check free or trial access only where offered. For paid access, use an authorised test process and confirm the purchase-to-Telegram mapping, expiry behaviour, and an access-recovery path. Do not make a real purchase solely for this documentation check without approval.

Confirm the terms and privacy-policy URLs. Do not invent retention periods, encryption assurances, refunds, response times, or eligibility conditions.

### 2. Verify commands and preferences

Record the deployed release identifier and test date. Compare every current command and menu button against its handler and a real response. In particular, verify `/start`, `/performance`, and whether `/menu`, `/help`, `/analyze`, or `/chatid` are actually offered.

Replace the provisional command table with the verified inventory. Do not reinstate exchange-linking, order execution, grid, or automatic-trading instructions from the old wiki.

Test each advertised preference, its save confirmation, and persistence. Establish whether selecting a symbol changes an analysis view, an alert subscription, or both. Keep filters, pause controls, exports, archives, reports, and stock coverage out of the feature list unless actually available and tested.

Add current, redacted screenshots only after checking that their labels and steps match the deployed release. Do not use a mock-up as an actual product screenshot.

### 3. Verify markets, time, and delivery

Publish the supported instruments, venues, market types, and relevant price sources. Explain the symbol notation. Do not reuse the old execution bot's exchange list as the alerts coverage list.

Confirm timestamp meanings and timezones: market event, observation, generation, send, and outcome times. Test a delivered notification and a follow-up. State any known delivery limitations without promising uninterrupted service or a fixed alert count.

### 4. Specify each alert stream

For **1m LONG+SHORT**, **Fast Move**, and **Consensus**, verify the deployed version and describe:

| Item to verify           | What readers need to know                                                                                  |
| ------------------------ | ---------------------------------------------------------------------------------------------------------- |
| Purpose and timing       | What the stream detects and whether a message is an early observation, confirmation, or outcome update.    |
| Eligibility and trigger  | Supported markets, required data, and the condition that makes an observation eligible.                    |
| Data interval            | Whether data is closed-candle or intrabar, and what the timeframe label represents.                        |
| Reference and boundaries | How reference price, target, invalidation, and any percentage distances are defined.                       |
| Evaluation window        | When scoring begins and ends; do not infer this from “1m.”                                                 |
| Closure rule             | First boundary reached, closing price, fixed horizon, or the actual implemented alternative.               |
| Ambiguity and gaps       | Treatment of same-candle target/stop cases, missing data, outages, and delayed delivery.                   |
| Expiry and corrections   | How expired, cancelled, corrected, and unresolved observations are recorded.                               |
| Score meaning            | Ranking, confidence, probability, or another measure; calibration evidence where a probability is claimed. |

The current stream pages explain interpretation but deliberately do not invent these parameters.

### 5. Reconcile /performance with its record

Verify the exact numerator and denominator, eligibility filters, date range, sample size, unresolved counts, and treatment of expiries. Confirm the construction of the null baseline and that an “edge” value means the stated percentage-point difference.

Keep streams, versions, live observations, backtests, simulations, and actual trading records distinguishable. Check for overlapping observations, future-data leakage, favourable same-candle assumptions, and selective omissions. Preserve a correction history.

The guide uses invented examples rather than founder-reported headline rates. Do not replace them with advertising claims without a dated, reproducible, appropriately qualified evidence record. An alert result must not be described as a subscriber return.

### 6. Check AI claims and service health

For each advertised model, verify that it is trained, loaded, validated, and used by the live alert path. Record the model version and relevant training cutoff. Confirm the behaviour when data or a model is unavailable.

Separate autonomous monitoring from retraining and strategy changes. The guide does not certify model health, adaptive-learning mode, a fallback policy, or an independent audit.

### 7. Review publication and the archive

Check the rendered draft on a narrow/mobile layout, all navigation links, code blocks, tables, and callouts. Verify external platform instructions when updating this guide.

The original Ninja Bot pages are preserved and hidden in the draft. Hiding is not a security boundary. Review legacy visibility before publishing so obsolete execution instructions cannot be mistaken for current onboarding.

Decide whether to rename the existing site and space from Ninja Bot to Degen Trading Bot; those site settings have not been changed by this draft. Remove the documentation-preview notice only after the material release checks are complete. Merging content and publishing an unpublished site are separate actions.

### Source and editorial notes

Owner-provided product context supports the alerts-only scope, reported stream names, and existence of `/performance`. Earlier business plans describe intentions and reported status, not a production audit. The old GitBook and uploaded README describe a previous execution product. Official Telegram and Whop documentation supports the platform instructions linked in the member guide; financial-risk references support general cautions, not approval of Degen.

Keep uncertain implementation details in this checklist until verified. The final member guide should describe what the deployed service actually does, not what an earlier plan proposed.