Back to overviewFAQ
Rules, payments, validators, and deterministic settlement.
Clear operational answers for the current validator-based trading evaluation system. Payment acceptance, activation, refunds, and deterministic settlement are validator-driven, not frontend-driven.
Core rule
Payment -> Verify -> Validator consensus -> Activate -> Continue
If any step fails, the system must keep an auditable state and must not silently accept the evaluation.
Evaluation basics
How plans, account size, and trading rules are applied.
What happens after I choose an evaluation?
The system creates a payment session for the selected plan. The evaluation is not accepted until payment is confirmed and validator consensus accepts the payment evidence.
Can I start trading before payment is accepted?
No. An evaluation can move forward only after Payment -> Verify -> Validator consensus -> Activation. Frontend state alone never activates an evaluation.
Which market is allowed for trading?
Bybit demo perpetual trading is the intended runtime. Spot trading is monitored as a rule violation path and must not be used for evaluation performance.
Which plans are currently active?
Active plans are Instant, Sprint, and Summit. Drawdown is static for every active plan. Surge and trailing drawdown plans are not available.
What are the core pass/fail limits?
Instant: 10% profit target, 4% daily loss, 6% overall loss, 0 minimum days. Sprint: 10% target, 4% daily loss, 6% overall loss, 5 minimum days. Summit: phase 1 target 8%, phase 2 target 5%, 5% daily loss, 10% overall loss, 5 minimum days per phase.
Can the same Bybit API keys be reused?
No. API keys are bound to one evaluation activation. If the same keys are submitted again, activation is blocked and the participant must use keys from a different subaccount.
Can one wallet run multiple active evaluations?
No. One wallet identity can have only one active evaluation at a time. This is a soft blocker against copy-trading or mirroring multiple evaluations from one account. After the active evaluation is completed, failed, or settled, the wallet can start another evaluation.
Payments and refunds
How HTN payments are verified and what happens when acceptance fails.
When is a payment considered accepted?
A payment is accepted only when the HTN rail confirms the transaction and validators reach the required consensus for payment acceptance.
What if the payment is on-chain but validators reject it?
The evaluation is not accepted. The system creates a refund flow to return the paid amount to the wallet identity bound to that payment session.
Can I verify the same paid session again?
Verification is retry-safe, but already accepted, failed, or refunded sessions must keep their final state. The site should not ask the participant to pay again for the same session.
Why can a payment stay pending?
A pending state means the rail or validator evidence is not final yet, for example insufficient confirmations, temporary node unavailability, or missing validator consensus.
Wallet login
Separate login flows for browser extension and mobile QR.
Are extension login and mobile QR login the same flow?
No. Extension login and mobile QR login are separate authentication flows. They share only the final wallet-session outcome model.
Does mobile QR login depend on the browser extension?
No. Mobile QR login is completed through the HTN gateway mobile auth flow and the mobile wallet signature request.
Does extension login depend on the HTN gateway?
No. Extension login uses the browser extension signature flow and does not use the mobile QR request channel.
Validators
What validators decide and why the app is not the final authority.
What do validators decide?
Validators decide payment acceptance, evaluation activation intent, runtime rule evidence, pass/fail outcomes, refund eligibility, and deterministic settlement authorization.
Can the web app accept a payment without validators?
No. The web app can prepare requests and display state, but payment acceptance must be backed by validator consensus.
Who performs activation actions?
Activation is validator-driven. The app prepares data; validators reach consensus on intent and use deterministic executor selection for any required runtime action.
Deterministic settlement and scale-up
How completed Instant evaluations should proceed.
Can I take settlement and scale up at the same time?
No. After an eligible Instant result, the participant chooses either deterministic settlement or account upgrade. The two outcomes are mutually exclusive.
Who authorizes deterministic settlement?
Settlement requires validator-backed result evidence and settlement recipient authorization. A frontend click alone is not sufficient.
Can settlement recipient signing use extension or mobile wallet?
Yes. Both channels can be supported, but they must remain separate signing flows with the same final settlement-recipient outcome.