Skip to main content

Tradoor

Tradoor — a reference card for a crypto project: what the product does and how verifiable the project’s key claims are; also — alignment with the Decentralized AI thesis (DecAI Fit).

Tradoor — a DeFi | Derivatives project on TON (token on BNB Chain), token (symbol: TRADOOR).

Disclaimer

Important: this page is a reference overview of the project. Within DecAIHub, we separately record a verification based on open sources within the AI thesis (what is real AI/onchain/why a token, and which sources this is based on).
This is not financial advice and not a recommendation to buy/sell/hold any asset. We do not assess price, returns, or entry/exit timing.
Conclusions are based on publicly available materials found as of the verification date. The absence of confirmation does not imply the absence of the technology.

TL;DR (for readers who are not into AI)

  • What it is: an onchain platform/protocol for trading options and perps (web/mobile/Telegram), with the NDMM pricing mechanism and a risk‑control system (ADL and others).
  • Who it’s for: traders who need options/perps on TON; also LP participants who provide liquidity (TLP).
  • Why onchain/token: the protocol core is deployed on TON (contracts, oracles); the TRADOOR token exists on BNB Chain, but its role in the product is publicly described only to a limited extent (the docs mention separate offchain $DOOR points).

How it works (very briefly)

  1. The user does: connects a wallet (TON), tops up the TON balance for fees and USDT for trading, then opens/closes positions in perps/options.
  2. The system does: calculates the perp price via premium rate/NDMM, accrues funding, manages LP exposure risk (including via ADL).
  3. The user gets: the trade result (PnL), while LP providers earn income via the TLP mechanics (a share of fees, funding and traders’ PnL).
  4. Where the blockchain is: the onchain part of the protocol and the oracles are on TON (Pyth pull model via smart contracts); the TRADOOR token is deployed on BNB Chain.
  5. Token role (if any): the TRADOOR token exists as BEP‑20, but the public docs focus on the protocol/trading on TON; separate offchain $DOOR points for rewards are mentioned.

Quick links: AI thesis fit

Project passport

Field Value
Project name Tradoor
Also known as (aliases) TonTradoor; Tradoor Mini App; TLP
Logo (logo) ../assets/116_tradoor_logo.png
Token symbol (ticker) TRADOOR
Category DeFi | Derivatives
Primary chain (chain) BNB Smart Chain
Type non-EVM
Network status mainnet
Consensus (consensus) PoS (TON)
Launch date (launch_date) 2024
Project status (status) active
Token (standard) BEP-20
Token contract 0x9123400446a56176eb1b6be9ee5cf703e409f492
Token model (token_type) unknown
Max supply 60,000,000 TRADOOR
Issuance fixed
Tokenomics (tokenomics, brief) the docs include an audit of the vesting contract, but there is almost no public tokenomics/utility for the TRADOOR token; separate offchain $DOOR points (rewards) are mentioned
Governance —
Admins/keys —
Audit yes (TonBit 2024; Zellic 2025; ScaleBit token vesting)
Bug bounty —
Team (team) —
Funding (investors/funding) Kenetic Capital; TON Ventures (as claimed in the user guide)
AI component (ai_component) AI/ML "liquidity shield"
Use‑case (use_case) trade options + perps on TON
DecAI Fit — AI thesis fit 3/6 — medium alignment with the Decentralized AI thesis
DecAI Fit component summary 1 / 2 / 0 / 3
Last verified 2026-02-11

General project overview

Tradoor is an onchain protocol/platform for trading derivatives (options + perps), oriented toward access via web, mobile and Telegram. In the docs, the product is positioned as a fast, UX‑oriented way to trade derivatives; fast order confirmations and a transparent fee model are claimed.

The technical docs describe the key elements of the core: the NDMM pricing mechanism (premium rate as a function of the deviation rate), the funding rate for perps, TLP (the liquidity provider model) and the ADL risk failsafe.

Features/modules

  • Options + Perps in one product (per the user guide).
  • Pricing/“price lock” + NDMM: formalization of the premium rate as a function of exposure skew (DR) and pegging of the contract price to the index price.
  • Funding rate: calculation and execution of funding for perps.
  • ADL: auto‑deleveraging as a fail‑safe under extreme exposure.
  • TLP (liquidity provider): subscription/redemption rules and income sources for LPs.
  • Oracles: Pyth (pull model), integrated via smart contracts on TON.
  • Rewards (offchain points): the user guide describes $DOOR points and referral bonuses.

Typical scenarios

  • Scenario 1 (trader): connects a TON wallet → tops up TON/USDT → opens/closes perps or options → receives PnL.
  • Scenario 2 (LP): subscribes to TLP → receives income/loss from fees, funding and the aggregate PnL of traders according to the TLP rules.
  • Scenario 3 (rewards): trades/invites friends/completes tasks → receives $DOOR points and a share of friends’ fees (as USDT) under the terms of the referral program.

Getting started (wallet/network)

  • What you need: a TON wallet (including Telegram Wallet) for the onchain part; trading requires TON for fees and USDT (per the user guide).
  • Network/chain: TON (trading/contracts); the TRADOOR token is deployed on BNB Chain (BEP‑20).
  • Fees: gas in TON when interacting with onchain contracts; for operations with the token on BNB Chain — BSC fees.

Architecture/tech (non‑AI)

  • Components: user interface (web/Telegram mini app), onchain protocol contracts on TON (the TonBit audit mentions Tact code and the repository), BEP‑20 token on BNB Chain.
  • Participant roles: traders; LP providers (TLP); protocol operators/contributors.
  • Where logic runs: pricing/risk logic (NDMM/funding/ADL) and oracles are claimed to be onchain on TON; UI/UX and part of the loyalty programs ($DOOR points) are offchain.
  • Dependencies: Pyth Network (pull model) for prices; TON infrastructure; for the token — BNB Chain.

Token/economics (expanded, no forecasts)

  • Token utility: the open Tradoor docs focus on the onchain protocol (options/perps) and LP mechanics; the utility of the TRADOOR token (BEP‑20) is described only to a limited extent. The user guide separately describes offchain rewards/points $DOOR.
  • Protocol necessity drivers: per the current Tier‑1 sources, the TRADOOR token is not shown as a critical component for trading; rather a separate token/vesting + a marketing layer.
  • Who pays fees: traders pay protocol fees (the fee mechanics are mentioned in the TLP context) and TON gas; operations with the TRADOOR token on BSC — BNB Chain gas.
  • Where fees go: partly to TLP income (per the docs: a share of transaction/liquidation fees, funding fees and traders’ PnL).
  • Issuance/burn: max total supply 60,000,000 TRADOOR (per BscScan); no information on burn mechanics was found in Tier‑1.
  • Security/incentive mechanisms: LP/trader incentives — via TLP and DOOR points/rewards; no separate onchain slashing/staking was found in Tier‑1.
  • Distribution and token issuance schedule: no public TRADOOR tokenomics was found; at the same time, the audits section includes an audit of the BSC vesting contract (ScaleBit).
  • Treasury: —.

Governance

  • Who makes decisions: — (no formal governance process is described in Tier‑1).
  • How protocol parameters change: via contract/parameter updates (in practice) and UI updates; no public process was found.
  • Where decisions are discussed/made: X/Telegram/docs.
  • Keys/multisig: —.

Security and incidents

  • Audits: TonBit (smart contract audit, May 2024; TON/Tact); Zellic (protocol report, May 2025 — link in the docs); ScaleBit (BSC vesting audit for the TRADOOR token — link in the docs).
  • Bug bounty: — (not found).
  • Incidents: — (not found).
  • Threat model: oracle risks (price correctness), LP/ADL exposure risks, risks of centralized access to parameters/updates, token/vesting risks, UI/Telegram integration risks.

Project status and timeline

  • Current status: the product is available as a mini app (per the docs) and the technical docs describe a working protocol; the TRADOOR token exists on BNB Chain.
  • Key releases/milestones: 2024‑05 — TonBit smart contract audit; 2025‑05 — Zellic audit (per the Audits page).
  • Roadmap: — (not found).

Ecosystem/integrations

  • Integrations: Pyth Network (oracles), Telegram mini app/wallet, TON ecosystem; token on BNB Chain (BscScan).
  • Partners: Kenetic Capital; TON Ventures (as claimed in the user guide).
  • Where it’s actually used: trading options/perps (user guide) and participation in the TLP/ADL mechanics (technical docs).

AI component of the project

  • What is real AI here? The Tier‑1 docs contain claims about an “AI‑enhanced liquidity shield” and the use of machine learning in the trading engine; at the same time, there are no public details/metrics, so this is rather a claim that an AI/ML component exists than a verifiable description of a model.
  • What is truly onchain? The oracles (Pyth pull model) and part of the protocol logic are claimed to be smart contracts on TON; a BEP‑20 token TRADOOR also exists on BNB Chain.
  • Why is a token needed? The existence of the TRADOOR token is confirmed onchain (BscScan), but the docs describe the token’s utility/necessity for trading weakly; the user guide features separate offchain $DOOR points for rewards.
  • Red flags (based on the information found): AI‑washing (generic “AI‑enhanced” wording without specifics), token‑washing (the token exists, but its “necessity” for the protocol is not proven), onchain‑washing (part of the onchain on TON is claimed, but public contract addresses/explorer links are not provided in the current sources; the deployment addresses of the TON contracts should be double‑checked).

DecAI Fit component summary

  • DecAI Fit: 3/6 — medium alignment with the Decentralized AI thesis
Component Level Score
AI reality low 1
Onchain necessity medium 2
Token necessity low 0
Evidence Tier‑1 present 3
Details

AI reality

AI_0 — AI intent (Tier‑1 roadmap) (1/0)

  • AI_0 (decision): 0
  • Claim (one line): the docs contain a “coming soon” about Quant AI, but at the same time an already existing AI/ML component is claimed (see AI_1), so AI_0 as “intent only” does not apply
  • Evidence: Tier‑1 — https://docs.tradoor.io/
  • Why sufficient / why not (one line): by the operational definition, AI_0=1 is set only when AI_1..AI_4 = 0
  • Conflict note (if any): —

AI_1 — what the AI does (1/0)

  • AI_1 (decision): 1
  • Claim (one line): the Tier‑1 docs claim the use of AI/ML (“AI‑enhanced liquidity shield”) for fair pricing and protection against “toxic flow”
  • Evidence: Tier‑1 — https://docs.tradoor.io/ ; https://docs.tradoor.io/tradoor-user-guide-v2
  • Why sufficient / why not (one line): Tier‑1 sources record the purpose of the AI/ML component, but without verifiable implementation details/metrics
  • Conflict note (if any): —

AI_2 — demos/examples (1/0)

  • AI_2 (decision): 0
  • Claim (one line): the product is available (mini app), but no Tier‑1 demos/examples specifically of the AI/Quant assistant at work or of reproducible AI scenarios were found
  • Evidence: Tier‑1 — https://t.me/tradoor_io_bot ; https://docs.tradoor.io/tradoor-user-guide-v2
  • Why sufficient / why not (one line): the existence of an app does not equal the existence of a verifiable AI demo; the docs contain no “request→response” or step‑by‑step example of an AI feature
  • Conflict note (if any): —

AI_3 — metrics/quality (1/0)

  • AI_3 (decision): 0
  • Metrics: —
  • Context (version/date/how measured): —
  • Evidence: Tier‑1 — https://docs.tradoor.io/
  • Why sufficient / why not (one line): metrics/benchmarks of the AI component are not disclosed in the Tier‑1 materials
  • Conflict note (if any): —

AI_4 — tech description/architecture/versions (1/0)

  • AI_4 (decision): 0
  • Claim (one line): Tier‑1 contains only a high‑level “AI‑enhanced” description, without architecture/versions/models/interfaces
  • Evidence: Tier‑1 — https://docs.tradoor.io/
  • Why sufficient / why not (one line): there is no technical description of the AI module, pipeline, versioning or specification
  • Conflict note (if any): —

Onchain necessity

OC_1 — contracts/addresses/chain (1/0)

  • OC_1 (decision): 1
  • Chain: TON (protocol/contracts); BNB Chain (token)
  • Addresses/identifiers: BEP‑20 token contract 0x9123400446a56176eb1b6be9ee5cf703e409f492; for the TON contracts, no explicit list of deployment addresses was found in the current Tier‑1 sources
  • Evidence: Tier‑1 — https://bscscan.com/token/0x9123400446a56176eb1b6be9ee5cf703e409f492 ; https://docs.tradoor.io/oracles ; https://r.jina.ai/https://www.tonbit.xyz/reports/Tradoor-Smart-Contract-Audit-Report-Summary.pdf
  • Why sufficient / why not (one line): the onchain identifier of the token is confirmed by the explorer; the existence of a smart‑contract part on TON is confirmed by the technical docs/audit, but the deployment addresses require additional verification
  • Conflict note (if any): —

OC_2 — onchain beyond just a token (1/0)

  • OC_2 (decision): 1
  • What useful logic is onchain: pricing (NDMM), funding rate, ADL and the LP mechanics (TLP) are described as parts of the protocol; prices are pulled via Pyth (pull model) on TON
  • Evidence: Tier‑1 — https://docs.tradoor.io/ndmm-pricing-mechanism ; https://docs.tradoor.io/funding-rate ; https://docs.tradoor.io/auto-deleveraging-adl ; https://docs.tradoor.io/tradoor-liquidity-provider ; https://docs.tradoor.io/oracles
  • Why sufficient / why not (one line): the Tier‑1 pages describe useful protocol logic that goes beyond “just a token”
  • Conflict note (if any): —

OC_3 — onchain is critical (1/0)

  • OC_3 (decision): 0
  • “Replace the blockchain” test: Tier‑1 contains a description of the onchain protocol on TON, but no explicit proof that the product is fundamentally impossible without a blockchain (rather than “implemented this way by choice”)
  • Evidence: Tier‑1 — https://docs.tradoor.io/ ; https://docs.tradoor.io/oracles
  • Why sufficient / why not (one line): there is no direct Tier‑1 argument “without onchain, X breaks down”
  • Conflict note (if any): —

Token necessity

TK_0 — no token (1/0)

  • TK_0 (decision): 0
  • Claim (one line): the project has a BEP‑20 token TRADOOR, while rewards in the product are also described as offchain $DOOR points
  • Evidence: Tier‑1 — https://bscscan.com/token/0x9123400446a56176eb1b6be9ee5cf703e409f492 ; https://docs.tradoor.io/tradoor-user-guide-v2/earn-rewards-on-tradoor/earn-rewards-by-trading
  • Why sufficient / why not (one line): the token is confirmed onchain, and $DOOR points are described in the user docs
  • Conflict note (if any): —

TK_1..TK_4 (1/0)

TK_1 — payment for the service (1/0)

  • TK_1 (decision): 0
  • Claim (one line): no confirmation was found in Tier‑1 that fees/access to trading are paid with the TRADOOR token
  • Evidence: Tier‑1 — https://docs.tradoor.io/ ; https://docs.tradoor.io/tradoor-user-guide-v2
  • Why sufficient / why not (one line): the user guide describes trading and rewards, but not TRADOOR payments for the service
  • Conflict note (if any): —

TK_2 — incentives/collateral/penalties (1/0)

  • TK_2 (decision): 0
  • Claim (one line): incentives in the docs are described as $DOOR points and referral payouts in USDT, not as protocol incentives via TRADOOR
  • Evidence: Tier‑1 — https://docs.tradoor.io/tradoor-user-guide-v2/earn-rewards-on-tradoor/earn-rewards-by-trading ; https://docs.tradoor.io/tradoor-user-guide-v2/earn-rewards-on-tradoor/earn-rewards-by-referring-friends
  • Why sufficient / why not (one line): there is no Tier‑1 confirmation that TRADOOR is needed for collateral/penalties/protocol incentives
  • Conflict note (if any): —

TK_3 — governance (1/0)

  • TK_3 (decision): 0
  • Claim (one line): nothing was found in Tier‑1 indicating that TRADOOR is used for governance/voting
  • Evidence: Tier‑1 — https://docs.tradoor.io/
  • Why sufficient / why not (one line): the governance mechanism is not described at a level sufficient for confirmation
  • Conflict note (if any): —

TK_4 — token is replaceable (1/0)

  • TK_4 (decision): 1
  • Claim (one line): it does not follow from the Tier‑1 materials that TRADOOR is an irreplaceable element of the protocol (core trading/liquidity/rewards are described without a need for TRADOOR)
  • Evidence: Tier‑1 — https://docs.tradoor.io/ ; https://docs.tradoor.io/tradoor-user-guide-v2
  • Why sufficient / why not (one line): the token’s utility for core functions is not proven; rewards are described as $DOOR points and USDT payouts
  • Conflict note (if any): —

Evidence (table)

Tier Source What it proves
Tier‑1 https://docs.tradoor.io/ official product description, AI/ML claims (“AI‑enhanced…”, Quant AI coming soon), positioning
Tier‑1 https://docs.tradoor.io/tradoor-user-guide-v2 user scenarios/modules; rewards context ($DOOR points), absence of an explicit TRADOOR utility for payments/trading
Tier‑1 https://docs.tradoor.io/oracles use of Pyth (pull model) in the protocol architecture (TON)
Tier‑1 https://docs.tradoor.io/ndmm-pricing-mechanism description of the NDMM pricing mechanism
Tier‑1 https://docs.tradoor.io/funding-rate description of the funding rate
Tier‑1 https://docs.tradoor.io/auto-deleveraging-adl description of the ADL risk mechanism
Tier‑1 https://docs.tradoor.io/tradoor-liquidity-provider description of the LP role (TLP)
Tier‑1 https://bscscan.com/token/0x9123400446a56176eb1b6be9ee5cf703e409f492 confirmation of the existence of the TRADOOR token (BEP‑20) and its onchain identifier
Tier‑1 https://docs.tradoor.io/audits list of audits and links to reports (PDFs may be unavailable for automated retrieval)
Tier‑1 https://r.jina.ai/https://www.tonbit.xyz/reports/Tradoor-Smart-Contract-Audit-Report-Summary.pdf Tier‑1 summary of the TonBit audit: audit scope and the repository/smart‑contract context

No comments to display

Back to top