Panel

KULLANICI ADI

AD SOYAD

E-POSTA

GSM NO

ROL

ÖZEL ROL Roller sekmesinde tanımlanan izin şablonlarından biri. Rol yoksa önce Roller sekmesinden oluşturun.

BAĞLI BİNANCE HESABI (viewer/özel rol için)

ADRES

ŞİFRE (boş bırakırsan değişmez)

DURUM

Boş bırakılırsa hesabın mevcut Demo API bilgisi korunur. Doldurup kaydederseniz hesap yeniden başlatılmadan hemen yeni anahtarla çalışmaya başlar.

Canlı seçilse bile Canlı API Key/Secret girilmemişse hesap güvenlik amacıyla otomatik olarak Demo/Testnet'te çalışmaya devam eder.

Boş bırakılırsa hesabın mevcut Canlı API bilgisi korunur.

Yeni Kayıt, Binance API Bilgisi Girildi, Hesap Aktif Edildi, Şifre Değiştirdi ve Hesap Sildi bildirimleri buraya gider (aynı bot token ile). Boş bırakılırsa yukarıdaki Telegram Chat ID (ana trading sohbeti) kullanılmaya devam eder.

Nasıl kurulur?

Telegram'da yeni bir kanal açın.
Ana bot'u (yukarıdaki Telegram Bot Token'a ait bot) bu kanala yönetici (admin) olarak ekleyin — yeni bir bot oluşturmanıza gerek yoktur, aynı bot kullanılır.
Kanalın chat ID'sini öğrenin (ör. kanaldaki bir mesajı @userinfobot'a iletin, ya da botun kanala attığı bir mesajı Telegram'ın getUpdates uç noktasından inceleyin). Kanal ID'leri genelde -100 ile başlar.
Chat ID'yi yukarıdaki alana yapıştırıp Kaydet'e basın.

Sinyal kararı Ana hesabın verisinden tek kaynaktan geliyor, pozisyon takibi (stop/TP) ise her hesabın kendi ortamından yapılıyor — bu yüzden hesaplar KARIŞIK modda (biri Canlı, biri Demo) çalışamaz. Bu işlem TÜM hesapları aynı anda tek moda geçirir.

Canlı API Key/Secret'ı girilmemiş hesaplar da otomatik Canlı moda alınır, ama Canlı anahtarı girilene kadar "Onay Bekliyor" durumunda kalır ve yeni işlem AÇMAZ (açık pozisyonları izlemeye devam eder). Anahtar tek tek hesap düzenleme ekranından girilebilir.

ROL ADI

YETKİLER

Yükleniyor...

Bu ekran, kapanan işlemlerin giriş anındaki kriter değerleri (RSI/ADX/Trend/Hacim/Extreme Mod) ile gerçek sonuç arasındaki ilişkiyi gösterir — hangi kombinasyonun daha çok kazandırdığını anlamak için kullanılır.

Canlı

Botun gerçek Binance hesaplarında açıp kapattığı işlemleri gösterir. PNL değerleri gerçek USDT tutarlarıdır (gerçek kaldıraç ve pozisyon büyüklüğüyle). Sadece bu kriter-analizi özelliği eklendikten sonra açılan işlemler dahildir — eski kayıtlar giriş anı kriter verisi içermediği için burada görünmez. Manuel (/join) ve harici (is_external=1) işlemler dahil değildir.

Backtest

Botla aynı sinyal mantığını geçmiş Binance verisiyle geriye dönük simüle eden, ScalpEngineBacktest adlı BAĞIMSIZ bir konsol aracının sonuçlarını gösterir. Bu araç admin panelin veya botun bir parçası DEĞİLDİR — ayrı bir sunucuda/ortamda elle çalıştırılır, sonuçlarını --db parametresiyle botun veritabanındaki AYRI bir tabloya (BacktestTradeHistory — canlı işlemlerin bulunduğu tablodan tamamen farklı, birbirine karışmaz) yazar; bu ekran o sonuçları okur. Yani "Backtest" sekmesine geçmek yeni bir test BAŞLATMAZ, sadece daha önce çalıştırılmış test sonuçlarını gösterir.

Backtest PNL değerleri gerçek USDT değil, kaldıraçsız fiyat hareketi yüzdesidir (ör. "1.80" = %1.80 fiyat hareketi). Gerçek pozisyon büyüklüğü/kaldıraç simüle edilmez — bu yüzden ekranda ayrıca bir "Kaldıraçlı Simülasyon" paneli çıkar (aşağıya bak).

Üstteki filtreler

Canlı / Backtest — veri kaynağını seçer (yukarı bak).
Tarih aralığı — Son 1/7/30/90 gün, Son 1 yıl, ya da "Özel Aralık" seçip iki tarih girerek istediğin herhangi bir aralığı raporla.
Hesap — belirli bir hesabın (ör. bir üyenin mirror hesabının) işlemlerine daralt.
Coin — belirli bir sembole (ör. sadece BTCUSDT) daralt.
Yenile — aynı filtrelerle veriyi tekrar çeker.
Backtest Verilerini Temizle — sadece BacktestTradeHistory tablosundan siler, CANLI işlemlerin bulunduğu tabloya hiç dokunmaz (farklı tablo). Butonun yanındaki başlangıç/bitiş tarih kutuları doldurulursa sadece o aralıktaki sonuçlar silinir (kapanış tarihine göre); boş bırakılırsa tüm backtest sonuçları silinir. Yeni bir backtest koşumundan önce eski sonuçları (tamamen ya da sadece belirli bir dönemi) temizlemek için kullanılır.

Backtest aracını çalıştırma parametreleri

ScalpEngineBacktest klasöründe, sunucuda şu komutlarla çalıştırılır:

dotnet run -- --days 30
dotnet run -- --days 30 --symbols BTCUSDT,ETHUSDT
dotnet run -- --days 30 --end 2026-08-12T00:00:00
dotnet run -- --days 30 --end 2026-08-12T00:00:00 --daily-universe
dotnet run -- --days 30 --end 2026-08-12T00:00:00 --live-vol-gate
dotnet run -- --days 30 --end 2026-08-12T00:00:00 --global-vol-gate
dotnet run -- --days 30 --end 2026-08-12T00:00:00 --mode Normal
dotnet run -- --days 30 --end 2026-08-12T00:00:00 --mode Agresif --adx-rise-tolerance 2
dotnet run -- --days 30 --end 2026-08-12T00:00:00 --adx-max 70
dotnet run -- --days 30 --end 2026-08-12T00:00:00 --adx-di-block 40
dotnet run -- --days 30 --end 2026-08-12T00:00:00 --stop-loss-pct 1.5
dotnet run -- --days 30 --end 2026-08-12T00:00:00 --di-tolerance 3
dotnet run -- --days 30 --end 2026-08-12T00:00:00 --rsi-oversold 25 --rsi-overbought 75
dotnet run -- --days 30 --end 2026-08-12T00:00:00 --tp1-target-pct 0.9
dotnet run -- --days 30 --end 2026-08-12T00:00:00 --global-vol-gate --min-global-volume 30000000
dotnet run -- --days 30 --end 2026-08-12T00:00:00 --ema15m-fast 20 --ema15m-slow 100
dotnet run -- --days 30 --end 2026-08-12T00:00:00 --ema1h-fast 20 --ema1h-slow 100
dotnet run -- --days 1 --end 2026-08-15T23:59:00 --no-cache
dotnet run -- --days 30 --end 2026-08-12T00:00:00 --cooldown-min 30
dotnet run -- --days 30 --end 2026-08-12T00:00:00 --fee-pct 0.1
dotnet run -- --days 30 --end 2026-08-12T00:00:00 --boundary-tolerance 1
dotnet run -- --days 30 --end 2026-08-12T00:00:00 --log-borderline borderline.csv
dotnet run -- --days 30 --end 2026-08-12T00:00:00 --scale-in --min-order-usdt 5 --order-size-usdt 20 --leverage 10
dotnet run -- --days 30 --end 2026-08-12T00:00:00 --scale-in --scale-in-trigger 0.3
dotnet run -- --days 30 --end 2026-08-12T00:00:00 --no-tp1-trail
dotnet run -- --days 30 --end 2026-08-12T00:00:00 --confirm-5m-candles 2
dotnet run -- --days 30 --end 2026-08-12T00:00:00 --no-2m-gate
dotnet run -- --days 90 --db "Server=...;Database=TradingBot;..."
dotnet run -- --days 30 --run-id manuel_test_1 --db "Server=...;Database=TradingBot;..."
dotnet run -- verify PROMUSDT 2026-08-12T01:32:00
dotnet run -- verify VELVETUSDT 2026-08-17T16:46:00 --testnet
dotnet run -- verify XRPUSDT 2026-08-19T16:05:00 --testnet --boundary-tolerance 1.5

--days N — kaç gün geriye test edileceği (varsayılan 90).
--symbols X,Y,Z — sadece belirli coinlerle test et (hızlı deneme için).
--end tarih — test aralığını "şu ana göre kayan" değil, SABİT bir tarihe göre hesaplar, böylece aynı komut her koşumda birebir aynı sonucu verir (tekrarlanabilir).
--start tarih — isteğe bağlı (07.09.2026 eklendi, kullanıcı talebi: "backtest e başlangıç ve bitiş tarih saat aralığını verebileceğim bir form eklermisin"). Verilirse --days'in yerini alır — aralığın başlangıcı DOĞRUDAN bu tarih/saat olur (--end'e ya da "şu an"a kadar). Verilmezse (varsayılan) hiçbir şey değişmez, --days ile eskisi gibi hesaplanır. Admin panelin "BAŞLANGIÇ TARİHİ" alanıyla aynı.
--daily-universe — coin evrenini "çalıştırıldığı anki" listeyle sabit uygulamak yerine, botun her gün kaydettiği GERÇEK günlük coin listesini kullanır (survivorship bias azaltılmış, daha gerçekçi sonuç).
--live-vol-gate — VOL-R'ye (kapanan 5dk mumun hacim oranı) ek olarak, o an oluşmakta olan mumun GERÇEK canlı-projeksiyonlu hacim oranını (P-VOL) da zorunlu şart yapar. Verilmezse (varsayılan) sadece VOL-R aranır — aynı dönemi iki şekilde çalıştırıp P-VOL'un gerçekten katkısı olup olmadığını karşılaştırmak için kullanılır.
--p-vol-threshold N — isteğe bağlı (04.09.2026 eklendi, kullanıcı talebi: "P-VOL değerini canlıda değiştirebiliyor olmam, 0 yazarsam devre dışı olmasını istiyorum, aynı şekilde backtest tarafında da"). --live-vol-gate açıkken P-VOL oranının aşmak zorunda olduğu eşiği belirler (SADECE Normal modda uygulanır, Agresif her zaman muaf). Varsayılan 1.0 — canlı bottaki admin panel "Bot Kriterleri" > "P-VOL Eşiği" ayarıyla (BotConfig.PVolThreshold) AYNI, eski sabit davranışla birebir eşdeğer. 0 girilirse şart TAMAMEN DEVRE DIŞI kalır — --live-vol-gate verilmiş olsa bile. Önceden bu eşik canlı botun koduna SABİT yazılmıştı, admin panelden hiç değiştirilemiyordu.
--vol-r-threshold N — isteğe bağlı (05.09.2026 eklendi, kullanıcı talebi: "backtest te p-vol var, hesap ayarlarında p-vol var ama VOL-R'ye [ayarlanabilir bir eşik] yok, kontrol eder misin? ... evet yapalım"). VOL-R'nin (en son KAPANMIŞ 5dk mumun hacim oranı, MA20'ye göre) geçmesi gereken eşik. --p-vol-threshold'dan BAĞIMSIZ, AYRI bir şart — --live-vol-gate'e bağlı DEĞİL, HER ZAMAN uygulanır, ve P-VOL'un aksine moddan bağımsızdır (Normal ve Agresif'i AYNI ŞEKİLDE etkiler, Agresif muafiyeti YOK). Varsayılan 1.0 — canlı bottaki admin panel "Bot Kriterleri" > "VOL-R Eşiği" ayarıyla (BotConfig.VolRThreshold) AYNI, eski sabit davranışla birebir eşdeğer. 0 girilirse şart TAMAMEN DEVRE DIŞI kalır. Önceden bu eşik hem canlı bot hem backtest motorunun koduna SABİT (1.0) yazılmıştı, admin panelden hiç değiştirilemiyordu.
--rsi5-tolerance N — isteğe bağlı (10.09.2026 eklendi, kullanıcı sorusu: "biz zaten RSI 5dk için sonrasında N tane mum onayı bekliyoruz, bu durumda (RSI15+10)/(RSI15-10) aralık kontrolü gereksiz olmuyor mu?" + takip talebi "bunu hesap ayarlarında parametrik yapalım ve backtest e ekleyelim"). EXTREME sinyalinde ("5m Teyidi"), RSI5'in RSI15'e göre kalması gereken aralık: SHORT için RSI5 ∈ [RSI15-N, RSI15], LONG için RSI5 ∈ [RSI15, RSI15+N]. --confirm-5m-candles'dan FARKLI bir şart: o, tespitten SONRAKİ mumların RENGİNE bakan İLERİYE dönük bir teyit; bu ise tespit ANINDAKİ RSI5 DEĞERİNE bakan GERİYE dönük bir momentum-uyum kalite filtresi — aynı şeyi iki kez kontrol etmiyorlar. Hem Normal hem Agresif modu AYNI ŞEKİLDE etkiler. Varsayılan 10.0 — canlı bottaki admin panel "Bot Kriterleri" > "RSI5 Teyit Aralığı" ayarıyla (BotConfig.Rsi5RangeTolerance) AYNI, eski sabit davranışla birebir eşdeğer. 0 girilirse şart TAMAMEN DEVRE DIŞI kalır. Önceden bu aralık hem canlı bot hem backtest motorunun koduna SABİT (±10) yazılmıştı, admin panelden hiç değiştirilemiyordu.
--global-vol-gate — canlı bottaki CoinGecko global hacim filtresinin (bir coinin o günkü global hacmi 20M USDT'nin altındaysa sinyal engellenir) backtest karşılığını uygular. Verilmezse (varsayılan) bu filtre hiç uygulanmaz. CoinGecko'nun geçmiş veri servisine sembol×gün başına ayrı istek attığı için (sonuçlar diske önbelleklenir) İLK koşumda ciddi şekilde yavaşlatabilir; sonraki koşumlarda önbellek sayesinde hızlanır. Coin bazında geçmiş veri bulunamazsa (ör. yeni/az bilinen coin) o sembol için filtre uygulanmaz — canlı bottaki "veri yoksa engelleme yok" davranışıyla tutarlıdır.
--mode Normal|Agresif — isteğe bağlı: verilmezse (varsayılan) her sembol hem Normal hem Agresif modda taranır. Verilirse SADECE o mod taranır, koşum süresi de kısalır (Normal'de E-15D/15dk EMA trend uyumu ZORUNLU, Agresif'te bu şart aranmaz). "Sadece Agresif modu test etmek istiyorum" gibi durumlarda kullanışlıdır.
--adx-rise-tolerance N — ADX yükseliş toleransını (ADX bir önceki ölçüme göre en fazla ne kadar hızlı yükselebilir) değiştirir. GÜNCELLEME (04.09.2026): önceden bu SADECE Agresif modu etkiliyordu (adı --agresif-adx-tolerance'tı, Normal modun toleransı HER ZAMAN sabit +2'ydi) — artık canlı bottaki (16.08.2026'dan beri birleştirilmiş, tek admin-tunable) davranışla hizalandı: TEK bir değer HEM Normal HEM Agresif modu AYNI şekilde etkiler. Varsayılan 2.0 (canlı bottaki admin panel "Bot Kriterleri" ayarıyla AYNI, admin panelden değiştirilebilir — bu bayrak sadece backtest'i o değerden FARKLI bir değerle test etmek için var). GÜNCELLEME (04.09.2026): bu değer artık backtest'teki (ve canlı bottaki) "kaba ADX" ön-kontrolünü de aynı anda kontrol ediyor — önceden o ayrı bir sabit +5 idi, bu ayardan bağımsızdı ve 5'in üstündeki değerleri sessizce geçersiz kılıyordu. Düşük değer (ör. 1.5) daha SIKI — "hâlâ ivmelenen" (henüz tükenmemiş) harekete karşı mean-reversion işlem açılmasını daha çok engeller; yüksek değer (ör. 3, 4) daha GEVŞEK — daha çok sinyal ama daha riskli. Aynı dönemi farklı değerlerle koşup CSV'leri karşılaştırarak en dengeli değeri bulmak için kullanılır.
--adx-max N — isteğe bağlı, varsayılan kapalı (üst sınır yok, eski davranış). ADX bu değerin ÜSTÜNDEYSE sinyal engellenir — --adx-rise-tolerance'dan FARKLI olarak bu bir hız/yükseliş şartı değil, MUTLAK seviye şartı, ve hem Normal hem Agresif modu aynı şekilde etkiler. Çok yüksek ADX (ör. 70+, "Aşırı Güçlü") genelde trendin hâlâ çok güçlü/olgunlaşmamış olduğunu gösterir — mean-reversion (karşı yön) bahis için riskli bir rejim olabilir. Doğru eşiği bulmak için farklı değerlerle (60, 70, 80) koşup CSV'leri karşılaştırmak amacıyla eklendi.
--adx-di-block N — isteğe bağlı, varsayılan kapalı. ADX bu değerin ÜSTÜNDE VE DI+/DI- o anki galip tarafı gösteriyorsa, galip tarafın TERSİNE (mean-reversion) sinyal engellenir: SHORT için DI+ > DI- iken (güçlü, teyitli YÜKSELİŞ trendine karşı kısa açılmasın), LONG için DI- > DI+ iken (güçlü, teyitli DÜŞÜŞ trendine karşı uzun açılmasın). --adx-max'ten farkı: bu şart YÖN bilgisini de kullanır, sadece mutlak ADX seviyesine değil hangi tarafın DI üstünlüğüne de bakar. Mevcut "DI toleransı" şartı sadece DI'nin ne kadar HIZLI değiştiğine bakar, hangi tarafın üstün olduğuna bakmaz — bu parametre o boşluğu kapatır. Hem Normal hem Agresif modu etkiler. Doğru eşiği (35, 40, 45...) bulmak için farklı değerlerle koşup CSV'leri karşılaştırmak amacıyla eklendi.
--di-tolerance N — isteğe bağlı (18.08.2026 eklendi), varsayılan 5.0 (eski sabit değerle AYNI, geriye dönük uyumlu). "DI toleransı" şartının eşiği: SHORT sinyalinde DI+'nin, LONG sinyalinde DI-'nin bir önceki mumdan bu yana en fazla ne kadar YÜKSELEBİLECEĞİ — hâlâ ivmelenen/tükenmemiş harekete karşı mean-reversion işlem açılmasını engellemek için. --adx-rise-tolerance'ın DI karşılığı: o ADX'in yükseliş hızını sınırlarken, bu DI'nin yükseliş hızını sınırlar. --adx-di-block'tan farkı: o ADX+DI'nin MUTLAK galip yönüne bakar, bu ise DI'nin ne kadar HIZLI değiştiğine bakar (yön farketmeksizin). Düşük değer (ör. 3) daha SIKI (daha az sinyal, daha korumalı), yüksek değer (ör. 7, 10) daha GEVŞEK. Hem Normal hem Agresif modu aynı şekilde etkiler. GÜNCELLEME (04.09.2026): önceden bu ayarın canlı botta HİÇ karşılığı yoktu (canlı sabit +5'e kilitliydi, admin panelden değiştirilemiyordu) — artık canlı bottaki admin panel "Bot Kriterleri" > "DI Toleransı" ayarıyla (BotConfig.DiTolerance) AYNI, bu bayrak sadece backtest'i o değerden FARKLI bir değerle test etmek için var. Doğru eşiği bulmak için farklı değerlerle (3, 5, 7) ayrı --out dosyalarına koşup CSV'leri karşılaştırmak gerekir.
--rsi-oversold N / --rsi-overbought N — isteğe bağlı (04.09.2026 eklendi, kullanıcı talebi: "admin panele eklediğim hesap ayarlarında olup backtest çalıştırda olmayan kriterleri de ekler misin"). EXTREME sinyalin RSI15 tetik eşiği: RSI bu OVERSOLD değerinin ALTINDAYSA LONG, OVERBOUGHT değerinin ÜSTÜNDEYSE SHORT adayı oluşur. Varsayılanlar 20/80 — canlı bottaki admin panel "Bot Kriterleri" > "RSI15 Eşikleri" ayarıyla (BotConfig.RsiOversoldThreshold/RsiOverboughtThreshold) AYNI. Önceden bu eşikler backtest motorunda SABİT KODLUYDU — admin panelden değiştirilse bile backtest'e hiç yansımıyordu.
--tp1-target-pct N — isteğe bağlı (04.09.2026 eklendi, aynı talep). TP1 hedefi yüzdesi. Varsayılan 0.7 — canlı bottaki admin panel "Bot Kriterleri" > "TP1 Hedefi %" ayarıyla (BotConfig.Tp1TargetPercent) AYNI. TP2-TP5 KASITLI OLARAK parametrik yapılmadı (canlı botta da admin panelden değiştirilemiyor, sabit %1.4/%2.1/%3.0/%3.5). Önceden backtest motorunda SABİT KODLUYDU.
--min-global-volume N — isteğe bağlı (04.09.2026 eklendi, aynı talep). CoinGecko günlük global hacim eşiği (USDT). İKİ yerde kullanılır: (1) --global-vol-gate açıkken sinyal filtresinde, (2) --daily-universe KAPALIYKEN varsayılan coin evrenini oluştururken. Varsayılan 20.000.000 — canlı bottaki admin panel "Bot Kriterleri" > "Min. Global Hacim Eşiği" ayarıyla (BotConfig.MinGlobalVolumeUsdt) AYNI. Önceden backtest motorunda SABİT KODLUYDU.
--ema15m-fast N / --ema15m-slow N — isteğe bağlı (04.09.2026 eklendi, kullanıcı talebi: "Trend 15dk / Trend 15dk (Canlı) / Trend 1h bunlarda parametrik olsun hem canlıda hem backtestte"). "Trend 15dk" ve "Trend 15dk (Canlı)" göstergelerinde VE Normal moddaki ZORUNLU trend-uyum şartında (E-15D) kullanılan hızlı/yavaş EMA periyotları. Varsayılanlar 50/200 — canlı bottaki admin panel "Bot Kriterleri" ayarıyla AYNI. Önceden SABİT KODLUYDU. Hızlı periyot yavaş periyottan küçük olmak ZORUNDADIR (aksi halde "HATA" ile reddedilir).
--ema1h-fast N / --ema1h-slow N — isteğe bağlı (aynı tarih/talep). "Trend 1h" göstergesinin hızlı/yavaş EMA periyotları — bu gösterge SADECE bilgi amaçlıdır, sinyal kararını (E-15D gibi) ETKİLEMEZ. Varsayılanlar 50/200, aynı kısıt (hızlı < yavaş) geçerlidir.
--require-trend-15m-agresif — isteğe bağlı (04.09.2026 eklendi, kullanıcı talebi: "biz agresif modda şuan bunları kriter olarak canlıda kullanmıyoruz, backtest içinde kullanılsın yada kullanılmasın gibi bir checkbox yapsan"). Bayrak, değer almaz. "Trend 15dk" (E-15D) şartı normalde SADECE Normal modda ZORUNLUDUR — Agresif mod bu şarttan hem canlı bottа hem backtestte her zaman muaftır. Bu bayrak verilirse SADECE bu backtest koşumu için aynı trend-uyum şartı Agresif moda da uygulanır (deneysel A/B karşılaştırma amaçlı — Agresif'e trend şartı eklemenin sonucu iyileştirip iyileştirmediğini ölçmek için). Varsayılan kapalı (verilmezse Agresif eski gibi muaf kalır). Canlı botu HİÇ etkilemez — canlı bu bayrağı hiç okumaz, Agresif'te her zaman muaf kalmaya devam eder.
--require-p-vol-agresif — isteğe bağlı (04.09.2026 eklendi, kullanıcı talebi: "P-vol extreme agresif modda devrede mi?" sorusuna cevaben, sonra "evet yapalım" onayı) — --require-trend-15m-agresif ile BİREBİR AYNI desen. Bayrak, değer almaz. P-VOL şartı normalde SADECE Normal modda ZORUNLUDUR — Agresif mod bu şarttan hem canlı bottа hem backtestte her zaman muaftır (bu, --p-vol-threshold eşiğinden BAĞIMSIZ, ayrı bir mod kuralıdır). Bu bayrak verilirse SADECE bu backtest koşumu için aynı P-VOL şartı Agresif moda da uygulanır — --live-vol-gate açık DEĞİLSE hiçbir etkisi yoktur (P-VOL şartı zaten hiç uygulanmıyor). Varsayılan kapalı. Canlı botu HİÇ etkilemez.
--stop-loss-pct N — isteğe bağlı (18.08.2026 eklendi), varsayılan kapalı. 19.08.2026 GÜNCELLEMESİ: canlı bot artık ATR bazlı %2.0-%2.5 kelepçeli stop kullanmıyor — stop mesafesi SABİT %1.3'e çevrildi (kullanıcı talebi: "anki volatiliteye göre değişen mantığı iptal edelim"). Backtest aracı da bu bayrak VERİLMEDİĞİNDE artık aynı sabit %1.3'ü varsayılan olarak kullanıyor (eski ATR mantığı tamamen kaldırıldı, artık hiçbir modda çalışmıyor). Bu parametre verilirse stop mesafesi HER sinyalde belirtilen FARKLI sabit yüzdeye ayarlanır (ör. --stop-loss-pct 1.5 → giriş fiyatının %1.5 uzağı) — yani artık "ATR yerine sabit kullan" değil, "varsayılan %1.3 yerine BAŞKA bir sabit yüzde dene" parametresi. TP1-5 seviyeleri bu parametreden ETKİLENMEZ, hep sabit kalır (%0.9/%1.8/%2.5/%3.0/%3.5) — sadece stop mesafesi değişir. Doğru değeri bulmak için aynı dönemi farklı yüzdelerle (ör. 1.0, 1.3, 1.5, 2.0) ayrı --out dosyalarına koşup CSV'leri karşılaştırmak gerekir.
--no-cache — backtest aracı her sembol+interval+tarih aralığı için indirdiği veriyi diskte (cache/ klasöründe) saklar, aynı aralık tekrar istenirse ağa hiç gitmeden o dosyayı kullanır. Bu parametre verilirse cache OKUNMAZ, Binance'ten HER ZAMAN taze veri çekilir (cache yine de güncellenir). Normal koşumlarda gerekmez — sadece YAKIN TARİHLİ/GÜNCEL bir olayı doğrularken kullan (ör. "bugün olan bir işlem neden böyle sonuçlandı"): verinin ilk indirildiği anda henüz tam kesinleşmemiş olma ihtimaline karşı, diskte bayat bir kopyayla sonsuza kadar çalışılmasını önler.
--cooldown-min N — canlı bottaki "bir işlem kapandıktan sonra aynı coinde bir süre yeni sinyal aranmaz" cooldown kuralının (AccountContext.SaveCooldown) backtest karşılığı. Varsayılan 60 (canlı bottaki en yaygın süreyle aynı) — bir pozisyon (SL/TP/zaman aşımı fark etmeksizin) kapandığında o sembolde N dakika boyunca yeni sinyal aranmaz. 0 verirsen kapanır (kapanışın hemen ardından yeni sinyal aranabilir, eski davranış).
--fee-pct N — isteğe bağlı (19.08.2026 eklendi, komisyon/kayma/fonlama hiç hesaba katılmıyordu — her sinyal tam olarak hesaplanan fiyattan açılmış/kapanmış varsayılıyordu). Verilirse HER işlemin ham kâr/zarar yüzdesinden bu sabit yüzde düşülür — gerçek Binance Futures işlemindeki komisyon (maker/taker, VIP/BNB indirimine göre değişir), kayma (bottun hedeflediği tetik fiyatı ile piyasa emrinin gerçek dolum fiyatı arasındaki fark) ve fonlama ücretinin (8 saatte bir, pozisyon o ana denk gelirse) TEK bir sabit gidiş-dönüş tahminidir; üçünü ayrı ayrı modellemek gerçekçi olmayan bir hassasiyet iddiası olur. Varsayılan 0 (kapalı, eski davranış). Örnek: --fee-pct 0.1 → her işlemden %0.1 düşülür. Gerçek maliyetini tahmin etmek için: taker komisyonu (VIP seviyene göre genelde %0.02-%0.05 arası, giriş+çıkış için x2), tahmini kayma ve olası fonlama ücretini toplayıp gir. Bu parametre pnl/pnl_usdt kolonuna yazılmadan ÖNCE uygulanır, yani admin panelindeki kaldıraç simülatörü dahil bu değeri okuyan HER görünüm otomatik olarak maliyet-düşülmüş sonucu gösterir.
--out dosya.csv — sonuç CSV'sinin dosya adını belirler (verilmezse otomatik zaman damgalı bir isim kullanılır, ör. backtest_results_20260812_180000.csv). Aynı dönemi farklı parametrelerle (ör. --live-vol-gate açık/kapalı) iki ayrı dosyaya yazıp elle karşılaştırmak için kullanışlıdır.
--db "..." — sonuçların yazılacağı veritabanı bağlantısı (verilmezse appsettings.json'dan otomatik okunur).
--run-id "kimlik" — isteğe bağlı (03.09.2026 eklendi, kullanıcı talebi: "yeni bir Backtest yapmak istediğimde tüm verileri silmem gerekiyor. Bana geçmiş test sonuçlarını görüntüleyebileceğim çalıştırılmış parametre satırınında bulunduğu bir rapor gerekiyor"). Bu koşumun BacktestTradeHistory'ye yazdığı satırları etiketler — admin panelin "Kriter Analizi" → Backtest görünümündeki "Geçmiş Backtest Koşumları" bölümünde ayrı bir koşum olarak listelenip filtrelenebilir/silinebilir hâle gelir, kullanıcı artık her yeni koşumdan ÖNCE tüm tabloyu silmek ZORUNDA değildir. Verilmezse otomatik olarak yyyyMMdd_HHmmss biçiminde üretilir — admin panelden ("Backtest Çalıştır" sekmesi) başlatılan koşumlarda bu kimlik ZATEN otomatik verilir (dosya adlandırması için kullanılan aynı kimlik, bkz. --log-borderline dosya yolu), yani admin panel kullanıcısının bu bayrakla hiç uğraşması gerekmez. Koşumun TÜM CLI parametreleri (--db bağlantı dizesi MASKELENEREK, asla ham hâliyle) ayrıca run_params sütununa kaydedilir — bu özellik eklenmeden ÖNCE yazılmış satırlarda ikisi de NULL kalır, admin panelde "Etiketsiz (Eski)" TEK bir grup olarak gösterilir. GÜNCELLEME (03.09.2026, İKİNCİ DÜZELTME — kullanıcı bulgusu: "Backtest verilerini temizle dediğimde bu veriler de silindi"): koşumun özeti (parametre satırı + istatistikler) artık AYRI, KALICI bir tabloya (BacktestRuns) da yazılır — admin panelin "Backtest Verilerini Temizle" butonu SADECE ham işlem satırlarını siler, bu özet tabloya HİÇ dokunmaz, yani "Geçmiş Backtest Koşumları" raporu artık o butondan etkilenmez (sadece bir koşumun "Görüntüle" ile açılan İşlem Listesi'ndeki işlemleri, ham satırlar silindiyse boş görünür). Tek bir koşumu (hem ham satırları hem kalıcı özetini) tamamen kaldırmak için admin panelin o koşuma özel "Sil" butonu kullanılmalı.
verify SEMBOL tarih — tek bir sembol + tek bir an için tüm kriter değerlerini ekrana döker, gerçek bir Telegram sinyaliyle manuel karşılaştırmak için kullanılır.
--testnet — isteğe bağlı (17.08.2026 eklendi). Veriyi Binance Futures MAINNET (varsayılan, fapi.binance.com) yerine TESTNET'ten (testnet.binancefuture.com) çeker — canlı bot şu an testnet'e bağlı olduğu için (Ayarlar > Binance ortamı), bu bayrak olmadan backtest MAİNNET verisiyle, canlı ise TESTNET verisiyle karşılaştırılmış olur; bu iki ortamın fiyat/mum verisi (donuk mum olmasa bile) belirgin şekilde FARKLI olabilir (VELVETUSDT 17.08.2026 vakası: aynı 15dk mum, iki ortamda tamamen farklı OHLC, RSI15 18,6 vs 35,2 çıkmıştı — --testnet ile eklenince canlıyla virgülüne kadar eşleşti). Cache mainnet'ten ayrı bir klasörde (cache/testnet/) tutulur, birbirine karışmaz. Sadece "sinyal mantığı canlıyla tutarlı mı" sorusunu doğrulamak için kullanılmalı — testnet fiyat hareketi gerçek piyasayı temsil etmediği için gerçek strateji/kârlılık değerlendirmesinde KULLANILMAMALI. Bot mainnet'e geçtiğinde bu bayrağa gerek kalmaz.
--boundary-tolerance N — isteğe bağlı (20.08.2026 eklendi, XRPUSDT vakası: canlıda ADX tam sınırda (60.0) tetiklenen bir sinyal, backtest'in kendi bağımsız yeniden hesapladığı ADX sınırın az üstüne çıktığı için backtest'te hiç görünmedi). ADX tavanı (--adx-max), ADX yükseliş toleransı ve DI toleransı kontrollerine EK bir pay tanır — ör. --boundary-tolerance 1 verilirse bu üç eşiğin hepsi 1.0 puan daha gevşek uygulanır. Varsayılan 0 (kapalı, eski davranış birebir korunur). DİKKAT: bu parametre TÜM sembolleri aynı anda gevşetir, sadece "bilinen tek bir kaçırılan aday"ı değil — deneylerde bu, başka sembollerde daha önce haklı olarak elenen zayıf adayların da işleme girmesine (ve genelde net PNL'i kötüleştirmesine) yol açabiliyor. Gerçek raporlama koşumlarında KULLANILMAMALI, sadece "belirli bir sembolün kaçırılma marjı ne kadar" sorusunu nokta atışı test etmek için (verify ile birlikte) kullanılmalı.
--log-borderline dosya.csv — isteğe bağlı (20.08.2026 eklendi, aynı XRPUSDT vakası). RSI eşiği tetiklenip ADX tavanı/toleransı ya da DI toleransı gibi bir eşikten ÇOK KÜÇÜK bir farkla (≤1.0 puan) reddedilen adayları ayrı bir CSV'ye kaydeder — bu satırlar SİNYAL DEĞİLDİR, PNL simülasyonuna hiç girmezler, ana sonucu (--out) hiçbir şekilde etkilemezler; sadece "az kalsın yakalanıyordu" teşhis bilgisidir. DB bağlantısı varsa aynı satırlar BacktestBorderlineCandidates tablosuna da otomatik yazılır ve bu ekranda ("Kriter Analizi" → Backtest görünümü) "Sınırda Kaçırılanlar" bölümünde görünür. --boundary-tolerance'tan farkı: bu sadece TEŞHİS amaçlıdır, hiçbir sinyal kararını değiştirmez (--boundary-tolerance ise gerçekten daha çok sinyal ürettirir).
--scale-in — isteğe bağlı (22.08.2026 eklendi, kullanıcı talebi: "işlem onayı geldiğinde minimum USDT ile aç, tutuyorsa kademeli arttır"). Varsayılan KAPALI (eski davranış, hiçbir etkisi yok). Açıldığında, SADECE Agresif moddaki işlemler minimum işlem büyüklüğüyle (--min-order-usdt) açılır; fiyat TP1 hedefinin YARISI kadar lehe giderse pozisyon TEK seferde normal büyüklüğe (--order-size-usdt) tamamlanır — çoklu kademe değil, tek adım. Eklendiğinde TP1-TP5 ve stop seviyeleri YENİ ağırlıklı ortalama girişe göre yeniden hesaplanır (orijinal % mesafeler korunur). Normal moddaki işlemler bu bayraktan HİÇ etkilenmez. DİKKAT: gerçek sembol-bazlı Binance minimumu (MIN_NOTIONAL/LOT_SIZE) modellenmez — --min-order-usdt ile verilen sabit tahmin kullanılır, canlı botta gerçek minimum sembolden sembole değişir. DÜZELTME (23.08.2026): backtest'te tutarlı biçimde sabit boyuttan daha iyi sonuç verdiği doğrulandıktan sonra bu özellik CANLI BOTA da taşındı — orada aç/kapat ve minimum USDT ayarı "Hesap Ayarları" → "Bot Kriterleri" kartındaki "🔺 Kademeli Pozisyon Büyüklüğü" bölümünden yönetilir (bu backtest bayrağıyla AYNI mantık, ama ayrı bir ayar seti: GET/POST /api/admin/trading-criteria üzerindeki scaleInEnabled/scaleInMinOrderUsdt, BotConfig.ScaleInEnabled/ScaleInMinOrderUsdt). Canlıdaki sürüm, buradaki gibi sabit bir tahmin yerine borsanın GERÇEK sembol-bazlı MIN_NOTIONAL'ını kontrol eder ve gerekirse otomatik olarak buna yükseltir. DÜZELTME (23.08.2026, kullanıcı talebi: "mirror hesaplarda farklı kademeli tutarlar vermek istemiyorum, ana hesabın ayarlarını kullansınlar. Önemli olan ana hesap ne yapıyorsa mirror hesaplarda eskisi gibi aynısı yapsın"): ilk versiyon SADECE ana hesapla sınırlıydı, artık DEĞİL — karar (uygulanıp uygulanmayacağı) yine SADECE ana hesabın Agresif/EXTREME durumuna göre veriliyor, ama karar "evet" ise TÜM hesaplar (ana + mirror) aynı anda minimum boyutla açılıp KENDİ normal boyutlarına (kendi OrderSizeUsdt/PremiumOrderSizeUsdt'lerine) büyütülüyor; her hesabın büyütme tetiği kendi pozisyon takip döngüsünde bağımsız çalışır (TP/stop takibinin zaten hep çalıştığı gibi), merkezi bir senkronizasyona ihtiyaç duymaz. Sonuçlar hem CSV'ye (scaled_in/effective_entry/pnl_usdt_scaled kolonları) hem DB'ye yazılır — bu ekranda ("Kriter Analizi" → Backtest görünümü) İşlem Listesi'nde her işlemin GERÇEK kademeli-boyut sonucu, sabit-boyut Kaldıraçlı Simülasyon tahmininin yanında ayrıca gösterilir. Koşum sonunda konsola kademeli strateji ile sabit-boyut stratejisinin toplam USDT karşılaştırması da yazdırılır.
--min-order-usdt N — --scale-in ile birlikte kullanılır, varsayılan 5. Pozisyonun İLK açıldığı marj (USDT) — Binance Futures'ın tipik minimum işlem büyüklüğü tahminiyle uyumlu bir varsayılan, gerçek sembol-bazlı minimum değil.
--order-size-usdt N — --scale-in ile birlikte kullanılır, varsayılan 20 (admin panelin Kaldıraçlı Simülasyon panelindeki varsayılan işlem büyüklüğüyle aynı). Pozisyona ekleme tetiklendiğinde TAMAMLANACAK normal/hedef marj (USDT) — --premium-order-size-usdt VERİLMEZSE her işlem bu TEK değere büyür.
--premium-order-size-usdt N — EKLENDİ (18.09.2026, kullanıcı talebi: "DI-bağımlı farklılaşmayı backtest'e ekleyebilir miyiz" — RENDERUSDT/PENDLEUSDT vakası, bkz. Hesap Ayarları'ndaki Base/Premium Lot notu). İSTEĞE BAĞLI, varsayılan YOK (verilmezse canlıdaki Base/Premium ayrımı backtest'e HİÇ yansımaz — --order-size-usdt tek/sabit hedef olarak kullanılır, eski davranış). Verilirse: her sinyalin AÇILIŞ anındaki kendi DI değerleriyle canlı bottakiyle BİREBİR aynı "diOk" kontrolü yapılır (DI'nin ≥2.0 puan değişmesi VE ilgili DI<49) — sağlanırsa kademeli büyütme bu (Premium) değere, sağlanmazsa --order-size-usdt (Base) değerine büyür. Sadece --scale-in işaretliyken bir etkisi vardır.
--leverage N — --scale-in ile birlikte kullanılır, varsayılan 10 (admin panelin Kaldıraçlı Simülasyon panelindeki varsayılan kaldıraçla aynı). Miktar hesaplaması (marj × kaldıraç ÷ fiyat) bu değeri kullanır.
--scale-in-trigger N — isteğe bağlı (03.09.2026 eklendi, kullanıcı talebi: "kademeli arttırmanın giriş seviyesini ayarlayabileceğim bir ayar olsun"). --scale-in ile birlikte kullanılır, varsayılan 0.5 (eski sabit davranışla AYNI — TP1 yolunun YARISI). 0-1 arası bir ORAN: pozisyona ekleme, fiyat girişten TP1'e giden yolun bu oranını kat ettiğinde tetiklenir — küçük değer (ör. 0.3) büyütmeyi ERKENE çeker (daha az kesinleşmiş bir harekette büyütür), büyük değer (ör. 0.8) GECİKTİRİR (fiyat TP1'e daha çok yaklaşmadan büyütmez). Admin panelin "Bot Kriterleri" > "Kademeli Pozisyon Büyüklüğü" > "Tetik Oranı" ayarıyla AYNI DB anahtarını (scale_in_trigger_ratio) paylaşır; bu bayrak verilmezse o ayarın DB değeri varsayılan alınır (diğer DB-varsayılanlı bayraklarla — --confirm-5m-candles, --no-2m-gate — AYNI desen).
--scale-in-fill-slippage-pct N — isteğe bağlı (06.09.2026 eklendi, kullanıcı bulgusu — STRKUSDT vakası: "canlı ile backtest çok tutarsız... evet bulalım ve bir önlem alalım"). --scale-in ile birlikte anlamlıdır. Varsayılan 0 (eski davranış — ekleme, HER ZAMAN teorik tetik fiyatından kaymasız/gecikmesiz doluyor varsayılır). Kök neden: canlı bot kademeli büyütmede GERÇEK Binance ortalama dolum fiyatını kullanır (bkz. Program_https_v245.cs TryScaleInPosition/addFillPrice) — bu, fiyatın tetik anıyla gerçek emir dolumu arasında geçen sürede biraz girişe geri çekilmesinden dolayı backtest'in varsaydığından FARKLI çıkabiliyor (STRKUSDT'de canlı ağırlıklı giriş 0.0316050, backtest 0.0315946 çıkmıştı — bu küçük fark, yeniden hesaplanan stop seviyesini kaydırıp canlının erken durup backtest'in aynı fiyat hareketinde hayatta kalmasına yol açmıştı). 0-1 arası bir ORAN: ekleme dolum fiyatının, teorik tetik fiyatı ile orijinal giriş arasındaki mesafenin bu kadarı kadar girişe doğru geri çekilmiş varsayılmasını sağlar (yön LONG/SHORT farketmeksizin otomatik doğru tarafa uygulanır). CANLIDA KARŞILIĞI YOKTUR (canlı zaten gerçek dolum fiyatını kullandığı için bu yaklaşıklamaya ihtiyacı yoktur) — SADECE backtest'in dolum varsayımını gerçeğe yaklaştıran deneysel bir modelleme ayarıdır; TEK bir vakadan türetildiği için "kesin doğru" bir değer yoktur, farklı oranlarla deneyip canlı sonuçlarına en çok yakınsayanı bulmak kullanıcıya bırakılmıştır.
--legacy-scale-in-stop — isteğe bağlı (03.09.2026 eklendi, kullanıcı bulgusu — ALGOUSDT vakası: "%0.08'lik ham fiyat hareketiyle Kademeli -0.62 USDT, Sabit tahmini -0.16 USDT gösteriyor, Sabit nasıl daha az zarar etmiş olabilir?"). --scale-in ile birlikte anlamlıdır (o kapalıyken hiçbir etkisi yoktur). Varsayılan KAPALI (düzeltilmiş davranış): pozisyona ekleme tetiklendiğinde stop, yeni (ağırlıklı ortalama) girişe göre yeniden hesaplanır ama ekleme ÖNCESİNDEKİ stoptan DAHA SIKI (fiyata daha yakın) hale GETİRİLEMEZ — çünkü ekleme kâr yönünde (TP1'e doğru) tetiklendiği için ortalama giriş lehte bir noktaya kayıyor, bu da eski (düzeltilmeden önceki) mantıkla stop'u da fiyata yaklaştırıp küçük/sıradan bir geri çekilmede bile pozisyonu erken, büyümüş miktarla orantısız büyük zararla durdurabiliyordu. Bu bayrak AÇILDIĞINDA o ESKİ (hatalı, hiç kelepçelenmemiş) davranış bilerek yeniden üretilir — SADECE eski sonuçları yeniden üretmek/karşılaştırmak içindir, gerçek raporlama koşumlarında KULLANILMAMALI. DİKKAT: aynı hata canlı botta da (kademeli büyütme fonksiyonunda) bulunup düzeltildi; GÜNCELLEME (03.09.2026, kullanıcı talebi: "canlı içinde bu eklemeleri parametrik yapalım") — canlıdaki düzeltme de artık bu bayrakla AYNI mantıkta, ayrı bir DB-backed anahtarla ("Bot Kriterleri" > "Kademeli Pozisyon Büyüklüğü" > "Eski (Hatalı): Kademeli Sonrası Stop Daralabilir") A/B edilebilir — bu backtest bayrağı ile canlıdaki checkbox birbirinden BAĞIMSIZDIR, biri diğerini etkilemez.
--reverse-candle-exit N — isteğe bağlı (17.09.2026 eklendi, kullanıcı talebi: "işlem açıldıktan sonra kademeli ekleme yapıldıktan sonra üst üste n kadar ters 5dk mum kapanırsa işlem otomatik olarak kapansın"). --scale-in ile birlikte anlamlıdır — SADECE pozisyona GERÇEKTEN ekleme yapıldıktan (scale-in tetiklendikten) SONRA devreye girer, öncesinde hiçbir etkisi yoktur. "Ters mum": mumun KENDİ açılış/kapanışına göre pozisyon yönüne ters kapanması (SHORT'ta kapanış>açılış/yeşil, LONG'ta kapanış<açılış/kırmızı) — önceki mumla veya trendle kıyaslama yapılmaz. Bu koşulu üst üste (ara vermeden) sağlayan 5dk mum sayısı N'e ulaşınca işlem o mumun kapanış fiyatıyla REVERSE_CANDLE nedeniyle kapatılır; araya UYUMLU (ters olmayan) bir mum girerse sayaç sıfırlanır. Varsayılan 0 = KAPALI (kullanıcı talebi: "default değer 0 yani kapalı durumda gelsin"). --scale-in-trigger/--confirm-5m-candles/--no-2m-gate ile AYNI desen: bu bayrak CLI'dan verilmezse (kullanıcı talebi: "backtest canlıda değer ne ise otomatik alsın"), admin panelin "Bot Kriterleri" ayarını (reverse_candle_exit_count DB anahtarı) otomatik kullanır — canlı bot da AYNI DB anahtarını okur, ikisi arasında elle senkronize edilmesi gereken ayrı bir değer YOKTUR.
--no-2m-gate — isteğe bağlı (02.09.2026 eklendi, kullanıcı talebi: "2dk mum onayı hala mantıklı mı karar veremiyorum, panelde aç/kapa yapalım, backtest'te test edip sonucuna göre karar veririm"). EXTREME sinyali tespit edilirken RSI5m aralık kontrolüne EK OLARAK aranan "son kapanan 2 dakikalık mumun rengi de yönle uyuşsun" şartını KAPATIR (varsayılan: bu şart aranır). DİKKAT — --confirm-5m-candles ile KARIŞTIRILMAMALI: o, tespit SONRASI ayrı bir onay aşamasıdır (N adet 5dk mum onayı); bu ise tespit ANINDA aranan tek bir 2dk'lık ön-şarttır — ikisi aynı anda, birbirinden bağımsız çalışabilir. Admin panelin "Bot Kriterleri" > "2 Dakikalık Mum Onayı Aransın" ayarıyla AYNI DB anahtarını (require_2m_candle_gate) paylaşır; bu bayrak verilmezse o ayarın DB değeri varsayılan alınır. Canlı botta da AYNI ayar kullanılır (EXTREME sinyalin "5dk Teyidi" gate'inin bir alt-şartı).
--no-tp1-trail — isteğe bağlı (27.08.2026 eklendi, kullanıcı talebi: "daha dinamik bir durum yaratmak mümkün mü" → seçilen seçenek "TP1 sonrası gerçek anlamda trailing"). Varsayılan (bu bayrak VERİLMEZSE) TP1 vurulduktan sonra, TP2'ye ulaşılana kadar fiyat yeni bir zirve (LONG) / dip (SHORT) yaptıkça stop AYNI %90 formülüyle (Giriş + (Zirve-Giriş)×0.9) o yeni zirveye göre SÜREKLİ yeniden hesaplanır ve SADECE lehe yönde çekilir (asla gevşetilmez) — böylece fiyat TP1'i geçip TP2'ye doğru ilerlemeye devam ederse ekstra kâr da kilitlenir. Bu bayrak VERİLİRSE eski (tek seferlik) davranışa dönülür: TP1 vurulduğu anda stop bir kez %90 seviyesine sıçrar, sonra TP2'ye kadar SABİT kalır — fiyat ne kadar ileri gidip gelirse gelsin güncellenmez. Aynı dönemi bu bayrak açık/kapalı iki ayrı --out dosyasına koşup CSV'leri karşılaştırarak sürekli trailing'in gerçekten katkısı olup olmadığı test edilebilir. Backtest'te (TradeSimulator.cs, tp1Trail parametresi) kâr oranını artırdığı doğrulandıktan sonra CANLI BOTA da (varsayılan AÇIK olarak) uygulandı — orada zaten 500ms'de bir çalışan "hızlı pozisyon izleme" döngüsüne eklendi, sadece anlamlı bir iyileşme (≥%0.05) olduğunda gerçek borsa stop güncellemesi tetiklenir (rate-limit/gereksiz emir riskini önlemek için), ve mirror hesaplara da aynı anda senkronize edilir. Canlı botta bu davranışı kapatmak için ayrı bir anahtar YOKTUR — sadece backtest'te karşılaştırma amaçlı mevcuttur.
--confirm-5m-candles N — isteğe bağlı (31.08.2026 eklendi, kullanıcı talebi: "işlem onayı aldıktan sonra 2 tane 5dk'lık mum onayı almadan işlem açmasın"). Varsayılan 0 (kapalı, eski davranış — sinyal kriterleri geçer geçmez işlem AYNI ANDA açılır). N verilirse, kriterleri geçen bir aday HEMEN işleme dönüştürülmez: sinyalin ÜZERİNE gelen N tane ARDIŞIK KAPANAN 5dk mumun kendi rengi (Close vs Open) sinyal yönüyle uyumlu OLMAK ZORUNDADIR (LONG → hepsi yeşil, SHORT → hepsi kırmızı). Hepsi uyuşursa işlem N'inci mumun kapanış fiyatından açılır — stop/TP seviyeleri bu YENİ fiyata göre aynı yüzdelerle yeniden kurulur (RSI/ADX/DI/VWAP gibi teşhis alanları orijinal sinyal anındaki değerler olarak kalır). Herhangi bir mum uyuşmazsa (veya veri N mum kadar ilerlemeden biterse) aday TAMAMEN reddedilir, işlem hiç açılmaz. Amaç: sinyal anındaki ham RSI/ADX/VWAP teyidine ek olarak, fiyatın GERÇEKTEN de birkaç mum boyunca sinyal yönünde devam ettiğini görmeden pozisyona girmemek — erken/yanlış dönüşlere karşı ek bir süzgeç. Kullanıcının istediği değer 2; farklı değerlerle (1, 2, 3) ayrı --out dosyalarına koşup CSV'leri karşılaştırarak gerçek katkısı ölçülebilir. Sadece ana backtest koşumunu etkiler — verify komutu (tek-an teşhis) bu geciktirmeyi uygulamaz.
--max-concurrent-positions N — isteğe bağlı (05.09.2026 eklendi, kullanıcı talebi: "hesap ayarlarında parametrik bir ayar yapalım aynı şekilde backtest e de ekleyelim. default 10 set edelim" — admin panelin "Günlük Kırılım" tablosuna eklenen "En Fazla Eşzamanlı" sütununun ortaya çıkardığı bilgiden sonra). Varsayılan 10 — canlı bottaki admin panel "Bot Kriterleri" > "Maks. Eşzamanlı Açık İşlem (Global)" ayarıyla (BotConfig.MaxConcurrentPositions) AYNI. ÖNEMLİ MİMARİ FARK: canlı botta bu tavan GERÇEK ZAMANLI kontrol edilir (yeni sinyal, o anki açık pozisyon sayısına bakılarak anında kabul/red edilir) — backtest'in ana döngüsü ise her sembolü BAĞIMSIZ ve SIRAYLA (bir sembolün TÜM tarih aralığı bitmeden diğerine geçmeden) taradığı için gerçek zamanlı/entegre bir "şu an kaç pozisyon açık" bilgisine sahip DEĞİLDİR. Bu yüzden tavan burada, TÜM sembollerin sinyalleri toplandıktan SONRA ayrı bir KRONOLOJİK SÜPÜRME (sweep) geçişiyle uygulanır: adaylar giriş zamanına göre sıralanır, o anda zaten bu kadar pozisyon "açık" (kapanmamış) ise yeni aday REDDEDİLİR ve sonuçtan (CSV/DB/özet raporların TAMAMINDAN) tamamen çıkarılır — sanki canlı botun global tavanı o anda işlemi hiç açtırmamış gibi. Sonuç olarak GERÇEK zamanlı bir gate'ten ayırt edilemez (aynı sinyal kümesi + aynı kronolojik sıra + aynı tavan kuralıyla aynı adaylar kabul/red edilir), ama uygulanışı ayrı bir son-işleme adımıdır. DAVRANIŞ DEĞİŞİKLİĞİ: bu özellik eklenmeden önce backtest'te hiçbir eşzamanlılık tavanı YOKTU (sınırsız); bu bayrak hiç verilmese bile artık varsayılan 10 ile SESSİZCE uygulanır — eski (sınırsız) davranışı yeniden üretmek için çok yüksek bir değer (ör. 999) girilebilir.

Backtest sonucunu nasıl yorumlamalı? (canlı ile birebir eşleşme beklenmemeli)

EKLENDİ (03.09.2026, kullanıcı vakası: AKEUSDT'de canlı bir SHORT açtı ama backtest aynı dönemi taradığında bu işlemi hiç üretmedi — verify ile incelendi, RSI15/ADX/DI canlıyla neredeyse birebir çıktı, tek fark ADX toleransının backtest'in KENDİ bağımsız hesabında eşiği sadece +0,19 puan aşmasıydı — --boundary-tolerance 0.3 ile tekrar denendiğinde sinyal gerçekten tetiklendi, "SONUÇ=SİNYAL AÇILIR"). Bu vaka, backtest sonuçlarını okurken akılda tutulması gereken genel bir gerçeği gösteriyor:

Backtest, canlı botun aynı kopyası DEĞİL — aynı kuralları geçmiş veriye bağımsız olarak yeniden uygulayan ayrı bir hesaplama. RSI/ADX/DI gibi göstergeler canlıda gerçek zamanlı akıştan, backtest'te ise geçmiş mumların toplu halde yeniden işlenmesinden hesaplanıyor — ikisi neredeyse hep aynı sonucu verir, ama eşiklerin (ADX toleransı, DI toleransı, ADX tavanı vb.) TAM sınırında kalan işlemlerde binde/yüzde birkaç puanlık ondalık farklar bazen bir tarafta sinyali açtırıp diğerinde engelleyebilir. Bu bir hata değil, iki bağımsız hesaplamanın doğal, kaçınılmaz bir sonucu.

Bu yüzden bir backtest sonucunu (Kriter Analizi tablosu, CSV, ya da Geçmiş Backtest Koşumları özeti) okurken:

Tek tek işlem eşleşmesi arama. "Canlı şu işlemi açtı, backtest de birebir aynı dakikada açmış mı" diye trade-trade karşılaştırmak yanıltıcı — sınırda kalan birkaç sinyal beklenir, tek başına bir sorun işareti değildir.
Toplam tabloya güven — win rate, toplam PNL%, işlem sayısı, saatlik/moda göre kırılım gibi AGREGE metrikler stratejinin genel karakterinin makul bir yaklaşığıdır. Yeterince büyük bir örneklemde (haftalar/aylar, onlarca-yüzlerce işlem) bu sınır-etkisiyle kaybedilen/kazanılan birkaç işlem istatistiksel olarak birbirini büyük ölçüde götürür, sistematik bir yanlılık yaratmaz.
Ne zaman gerçekten endişelenmeli: backtest'in bulduğu işlem sayısı canlıdan BÜYÜK farkla azsa/çoksa (birkaç işlem değil, kat kat fark), ya da win rate/toplam PNL canlıdan çok uzaksa — bu tek bir sınır vakasından değil gerçek bir mantık farkından kaynaklanıyor olabilir (yanlış mum besleniyor, parametre uyuşmazlığı, veya verify komutuna admin panelin gösterdiği Türkiye yerel saati doğrudan UTC sanıp vermek — verify argümanı HER ZAMAN UTC'dir, admin paneldeki Açılış/Kapanış saatinden 3 saat çıkarman gerekir). O zaman verify ile derinlemesine incelemeye değer.
Backtest'i en güvenilir kullandığın yer: farklı parametreleri BİRBİRİNE göre kıyaslamak (ör. --adx-rise-tolerance 2 mü 3 mü daha iyi, --stop-loss-pct 1.3 mü 1.5 mi) — çünkü iki backtest koşumu AYNI yöntemle hesaplandığı için aralarındaki fark güvenilir, canlıyla birebir eşleşmesi şart değildir.

Kısacası: backtest sonucunu "stratejimin genel eğilimi bu" olarak oku, "canlının yaptığı her işlemin birebir kopyası" olarak değil.

P-VOL katkısını ölçme (VOL-R tek başına mı, +P-VOL mü daha iyi?)

Aynı dönemi iki kez, sadece --live-vol-gate açık/kapalı olacak şekilde ayrı dosyalara koşup CSV'leri karşılaştır:

dotnet run -- --days 30 --end 2026-08-12T00:00:00 --out sadece_volr.csv
dotnet run -- --days 30 --end 2026-08-12T00:00:00 --live-vol-gate --out volr_pvol.csv

Birincisi sadece VOL-R şartıyla, ikincisi VOL-R + gerçek P-VOL şartıyla AYNI dönemi test eder. İki CSV'nin işlem sayısı ve kazanma oranı farklıysa, P-VOL'un sinyal kalitesine gerçekten katkısı var demektir.

Kaldıraçlı Simülasyon paneli

Sadece Backtest görünümünde çıkar. Backtest PNL'i (kaldıraçsız % hareket) üstteki Kaldıraç ve İşlem Büyüklüğü alanlarına göre TAHMİNİ bir USDT kazanç/kayba çevirir — komisyon, fonlama ücreti ve likidasyon riski hesaba katılmaz, gerçek sonuçtan farklı olabilir. Farklı kaldıraç/büyüklük varsayımlarını hızlıca denemek için kullanılır.

Örnek senaryo

"Son 30 günde Agresif mod gerçekten Normal moddan daha mı iyi kazandırıyor?" sorusunu test etmek istersen: sunucuda dotnet run -- --days 30 --end 2026-08-12T00:00:00 --daily-universe --db "..." çalıştır, bitince buraya dönüp üstten Backtest + Son 30 gün seçip Yenile'ye bas — alttaki özet ve tablo Normal/Agresif kırılımını gösterir.

RSI eşiği tetiklenen (isExtreme) HER aday burada kayıtlı — sadece gerçekten açılan işlemler değil (17.08.2026 güncellemesi).

Kriter sütunu

Hangi şartın (ADX toleransı/tavanı, DI toleransı, VWAP, hacim, ATR, trend, 5dk teyit, veri tazeliği) adayı reddettiğini gösterir.

Açıklama sütunu

(10.09.2026 güncellemesi) O şartı NEDEN sağlamadığını gerçek sayılarla anlatır — "Mevcut" (o an ölçülen ham değer) ve "Olması gereken" (geçmek için gereken sınır) satırları halinde (ör. "Mevcut: ADX 33.7 | Olması gereken (maks): 32.7 → 1.0 puan aşıldı") — "bu coin neden açılmadı" sorusunu backtest'e gerek kalmadan doğrudan cevaplar.

5dk Grafik sütunu

Sadece kriter geçen ("✅ Kriter Geçti") satırlarda görünen "Grafik" butonu, sinyalin tetiklendiği mumdan "5dk Mum Onayı" penceresinin sonuna kadar olan gerçek 5dk'lık mum grafiğini açar. Grafikteki mavi kesikli çizgi ("Sinyal Mumu") kriterlerin geçtiği mumun başlangıcını, turuncu kesikli çizgi ("Onay Sonu") ise onay penceresinin bittiği anı gösterir (varsayılan 2 ardışık mum = 10dk, satırda farklı bir gereken sayı varsa ona göre ayarlanır). Bağlam için pencerenin öncesine/sonrasına birkaç mum daha eklenir. Alttaki rozet grafiğin mainnet mi testnet mi veriden geldiğini belirtir. Bu grafik SADECE fiyat hareketini gösterir — kesin ONAY/RED/İLERLİYOR sonucu hem "5dk Mum Onayı" sütununda hem de Açıklama metninde ayrıca yazılıdır.

Mum verisi

O anki RSI15/ADX'i besleyen KAPANAN 15dk mumun tam OHLC'si de ayrıca kayıtlı (canlı bot o an gerçekte hangi veriyi gördü sorusu için).

Bu güncellemeden ÖNCEKİ kayıtlarda kriter kırılımı yok (Kriter sütununda "—" görünür, Açıklama da "—" gösterir), sadece açılan/tazelik-engelli sinyaller mevcuttur. 10.09.2026'dan ÖNCEKİ kayıtlarda kriter kırılımı VAR ama Açıklama'daki sayısal ayrıntılar (DI/hacim/EMA ham değerleri) yoktur — bu durumda Açıklama kritere özel genel bir cümleye düşer.

www.scalpengine.com ana sayfasına gelen isteklerin IP bazında günlük özeti. Sadece ana sayfa (kök adres) yüklemeleri sayılır — admin panelin/üye panelinin arka planda sürekli çektiği API verileri dahil değildir, bu yüzden rakam gerçek ziyaretçi trafiğine karşılık gelir.

AI BotConsole

Admin Panel

	#	Ad Soyad	Kullanıcı Adı	E-posta	GSM	Hesap	Trading Talebi	API Bilgisi	Rol	Durum	2FA	Son Giriş	İşlem
Yükleniyor...

"Süre", giriş anından çıkış anına kadardır. Çıkış "Çıkış Yap" ile, şifre değişimi/hesap silme ile ZORLA, ya da aynı hesapla başka bir yerden yeni bir girişle (tek aktif oturum kuralı) olabilir. Hâlâ "Aktif" görünen bir kayıt, kullanıcı sekmeyi kapatıp gittiyse (Çıkış Yap'a basmadan) token'ın 24 saatlik geçerlilik süresi dolana ya da bir sonraki girişine kadar bu şekilde kalabilir.

Kullanıcı	Hesap	Rol	Giriş Zamanı	Çıkış Zamanı	Süre	IP Adresi	Cihaz / Tarayıcı
Yükleniyor...

Admin panelden gönderilmiş tüm mesajların (tekil veya "Tüm Kullanıcılara") geçmişi — en yeniden en eskiye. "Görüntülendi" sütunu, o mesajı kaç farklı kullanıcının ana sitede kapattığını gösterir. Silme kalıcıdır; silinen bir mesaj henüz kapatılmamışsa ilgili kullanıcının ekranında bir daha görünmez.

	Tarih	Gönderen	Alıcı	Mesaj	Görüntülendi
Yükleniyor...

#	Rol Adı	Yetkiler	Oluşturulma	İşlem
Yükleniyor...

	Hesap	Durum	Tip	Base Lot	Premium Lot	Trend Lot	Kaldıraç	Max Extreme	Max Trend	Extreme İzni	Extreme Mod	Trend İzni	Kademeli İzni	Mod	İşlem
Yükleniyor...

Canlı botun EXTREME sinyal üretiminde kullandığı temel eşikler — tüm hesaplar (Ana + Mirror) için ortaktır, hesap bazlı değildir. Değişiklik en geç ~60 saniye içinde canlı taramaya yansır.

RSI15 AŞIRI SATIM EŞİĞİ (LONG tetik) --rsi-oversold RSI bu değere eşit/altına inerse LONG EXTREME sinyali doğar. Varsayılan: 20

RSI15 AŞIRI ALIM EŞİĞİ (SHORT tetik) --rsi-overbought RSI bu değere eşit/üstüne çıkarsa SHORT EXTREME sinyali doğar. Varsayılan: 80

ADX YÜKSELİŞ TOLERANSI --adx-rise-tolerance ADX'in bir önceki muma göre izin verilen yükseliş miktarı. Varsayılan: 2.0

DI TOLERANSI --di-tolerance DI+/DI-'nin bir önceki muma göre izin verilen yükseliş miktarı. Varsayılan: 5.0

P-VOL EŞİĞİ --p-vol-threshold ⚠ SADECE Normal modda aktif — Agresif her zaman muaf, bu değeri değiştirmek Agresif'i etkilemez. 0 = tamamen devre dışı (Normal dahil). Varsayılan: 1.0

VOL-R EŞİĞİ --vol-r-threshold Hem Normal hem Agresif modu AYNI ŞEKİLDE etkiler (P-VOL'un aksine mod istisnası yok). 0 = tamamen devre dışı. Varsayılan: 1.0

VOL-R TAVANI --vol-r-ceiling Hem Normal hem Agresif modu AYNI ŞEKİLDE etkiler. 0 = tamamen devre dışı (tavan yok). Varsayılan: 0

HIZLI RADAR MODU --hotradar-mode Hesap bazlı Extreme Mod'dan (canlı giriş kararı) bağımsızdır — sadece Hızlı Radar önizlemesinin hangi kriter setini taklit edeceğini seçer. Varsayılan: Normal.

HIZLI RADAR AYRI EŞİK KULLANSIN --hotradar-use-own-thresholds Kapalıyken (varsayılan) Hızlı Radar yukarıdaki RSI15/VOL-R eşikleriyle birebir aynıdır. Açılırsa Hızlı Radar SADECE aşağıdaki 3 alanı kullanır, gerçek EXTREME giriş sinyali etkilenmez.

HIZLI RADAR — RSI15 AŞIRI SATIM --hotradar-rsi-oversold SADECE yukarıdaki anahtar açıkken kullanılır. Varsayılan: 20

HIZLI RADAR — RSI15 AŞIRI ALIM --hotradar-rsi-overbought SADECE yukarıdaki anahtar açıkken kullanılır. Varsayılan: 80

HIZLI RADAR — VOL-R EŞİĞİ --hotradar-vol-r-threshold SADECE yukarıdaki anahtar açıkken kullanılır. 0 = tamamen devre dışı. Varsayılan: 1.0

RSI5 TEYİT ARALIĞI --rsi5-tolerance RSI5'in RSI15'e göre kalması gereken ±aralık ("5m Teyidi"). N-mum onayından bağımsız, ayrı bir şart. 0 = tamamen devre dışı. Varsayılan: 10

ADX TAVANI --adx-max Bu değerin üstündeki ADX, EXTREME sinyali engeller. Varsayılan: 60

TREND 15DK — HIZLI EMA --ema15m-fast "Trend 15dk" / "Trend 15dk (Canlı)" ve Normal moddaki zorunlu trend-uyum şartının (E-15D) hızlı EMA periyodu. Varsayılan: 50

TREND 15DK — YAVAŞ EMA --ema15m-slow Aynı şartın yavaş EMA periyodu — hızlı EMA'dan büyük olmalı. Varsayılan: 200

TREND 1H — HIZLI EMA --ema1h-fast "Trend 1h" göstergesinin hızlı EMA periyodu — SADECE bilgi amaçlı, sinyal kararını etkilemez. Varsayılan: 50

TREND 1H — YAVAŞ EMA --ema1h-slow Aynı göstergenin yavaş EMA periyodu — hızlı EMA'dan büyük olmalı. Varsayılan: 200

STOP LOSS % --stop-loss-pct Otomatik EXTREME sinyallerin sabit stop mesafesi. Varsayılan: %1.3

TP1 HEDEFİ % --tp1-target-pct Otomatik EXTREME sinyallerin ilk kâr alma hedefi. Varsayılan: %0.7 (27.08.2026'da %0.9'dan düşürüldü — buradaki alan boşsa/hiç kaydedilmemişse bu yeni varsayılan kullanılır, daha önce kaydedilmiş bir değer varsa o öncelikli kalır)

AYNI SEMBOL BEKLEME SÜRESİ (dk) --cooldown-min Bir işlem kapandıktan sonra aynı coinde yeni işlem aranmadan önce beklenen süre. Varsayılan: 10dk

GÜVENLİK KİLİDİ SÜRESİ (dk) --lock-pause-minutes Bir coinde stop-loss ile zararda kapanan işlemden sonra (eşik kadar STOP olunca) o coin için tüm hesaplarda yeni işlem açmanın durduğu süre. Diğer coinler etkilenmez. 0 = kilit fiilen kapalı. Varsayılan: 120 dk (2 saat)

GÜVENLİK KİLİDİ EŞİĞİ (STOP sayısı) --lock-threshold Aynı coinde kaç STOP-loss (art arda, 4 saat içinde) sonrası kilit devreye girsin. 1 = ilk stopta hemen kilitlenir. Varsayılan: 1

MİN. GLOBAL HACİM EŞİĞİ (USDT) --min-global-volume CoinGecko taramasına girecek minimum günlük global hacim. Varsayılan: $20.000.000

ŞOK MODU EŞİĞİ (%) BTC'nin o an oluşan 15 dakikalık mumu açılıştan bu yana bu yüzdeden fazla hareket ederse Şok Modu devreye girer: en fazla 2 aktif işlem ve sadece RSI < 15 veya RSI > 90 fırsatları. BTC sakinleşince (hareket < %0.5 ve son 3 mum dar) kendiliğinden kapanır. Varsayılan: %1.5

ŞOK MODU GİRİŞ PENCERESİ (15dk mum sayısı) Son N adet 15dk mumun birikimli net hareketi eşiği geçerse de Şok Modu açılır (8 = 2 saat). Tek mum eşiği geçerse yine açılır. Varsayılan: 8

ŞOK MODU ÇIKIŞ PENCERESİ (15dk mum sayısı) Çıkış: o anki mum < %0.5 VE son N mumun net hareketi eşiğin yarısının altında (3 = 45 dk). Varsayılan: 3

ŞOK MODU MİN. AÇIK KALMA (dk) Birikimli pencere ile açılan Şok Modu en az bu kadar dakika açık kalır; eşik civarında fiyat oynarken aç-kapa yapmasını önler. Tek mum şoku ile açılan mod bundan etkilenmez. 0 = kapalı. Varsayılan: 15

ŞOK MODU YENİDEN AÇILMA BEKLEMESİ (dk) Şok Modu kapandıktan sonra bu kadar dakika boyunca yalnızca birikimli pencere ile yeniden açılamaz. Büyük bir tek mum şoku bu beklemeyi yok sayıp modu hemen açabilir. 0 = kapalı. Varsayılan: 30

COINGECKO DEMO API KEY (opsiyonel — 429 hatalarını önler)

CoinGecko'nun ücretsiz "Demo API Key"i (coingecko.com/en/developers/dashboard, kredi kartsız) — dakikada 30 istek garantili kota sağlar, anonim istek limitine takılıp "429 Too Many Requests" hatası almayı önler. Boş bırakılırsa anonim (anahtarsız) istek atılmaya devam edilir.

GÜNLÜK KÂR HEDEFİ (%) (backtest karşılığı yok) Hesap bazlı: bir hesabın o günkü gerçekleşen net kârı, o hesabın günün başındaki (00:00) bakiyesinin bu yüzdesine ulaşınca SADECE o hesapta yeni işlem açılması durur (açık pozisyonlar etkilenmez). Ertesi gün 00:00'da otomatik sıfırlanır. Varsayılan: %10.0

🔺 Kademeli Pozisyon Büyüklüğü

Açık iken: Agresif moddaki EXTREME sinyaller pozisyonu önce MINIMUM boyutla açar; fiyat girişten TP1'e giden yolun yarısını kat ettiğinde pozisyon TEK adımda "normal" boyuta büyütülür. Backtest'te sabit boyuta göre tutarlı biçimde daha iyi sonuç verdi. Karar SADECE ana hesabın durumuna göre verilir (mirror hesapların kendi Normal/Agresif ayarı etkisizdir), ama karar verildiğinde TÜM hesaplar (ana + mirror) aynı şekilde minimumla açılıp kendi normal boyutlarına büyütülür — her hesap kendi normal boyutunu (OrderSizeUsdt/PremiumOrderSizeUsdt) korur, sadece açılış anı ve büyütme mantığı ortaktır.

Aktif --scale-in

AÇILIŞ (MİNİMUM) BOYUTU (USDT) --min-order-usdt Pozisyonun ilk açıldığı minimum USDT tutarı. Borsanın gerçek asgari işlem tutarının (MIN_NOTIONAL) altında kalırsa, sembol atlanmaz — miktar otomatik olarak borsa minimumuna yükseltilir. Varsayılan: 5

GÜVENLİK SINIRI (ZORUNLU MARGIN TAVANI, USDT) (backtest karşılığı yok) Borsa minimumu yüzünden yukarı yuvarlanan miktarın gerçek margin karşılığı bu tutarı aşarsa, sürpriz büyük pozisyon açılmasın diye işlem HİÇ AÇILMAZ (METAUSDT/TSLAUSDT gibi pahalı/tam-birim semboller için). Varsayılan: 50

TETİK ORANI (TP1 YOLUNUN YÜZDE KAÇI) --scale-in-trigger Fiyat, girişten TP1'e giden yolun bu ORANINI (0-1 arası, ör. 0.5 = yarısı) kat ettiğinde pozisyon minimumdan normal boyuta büyütülür. Küçültmek büyütmeyi erkene çeker (daha erken ama daha az kesinleşmiş bir harekette), büyütmek geciktirir. Varsayılan: 0.5

KADEMELİ ONAY MUMU SAYISI --scale-in-confirm-candles Fiyat tetik seviyesine ulaştığında ekleme ANINDA yapılmaz — bu kadar ARDIŞIK 5dk mumun KAPANIŞININ hâlâ tetik seviyesinin ötesinde olması beklenir. Amaç: ekleme tam yerel bir tepe/dipte yapılıp hemen ardından fiyat dönünce oluşan yanlış zamanlama riskini azaltmak. 0 = kapalı (varsayılan, fiyat dokunur dokunmaz hemen eklenir).

KADEMELİ ONAY MUMU: AKTİF MUMU SAYMA --scale-in-confirm-exclude-entry-candle

İşlem açıldığı anda aktif olan 5dk mum, varsayılan olarak onay sayımına dahil edilir. Bu işaretlenirse, o mum sayıma hiç dahil edilmez — onay sayımı bir sonraki tam mumdan başlar. Varsayılan: işaretsiz (mevcut davranış, değişiklik yok).

İşlem açıldığı anda aktif olan 5dk mum, varsayılan olarak onay sayımına dahil edilir. Bu açılırsa, o mum sayıma hiç dahil edilmez — onay sayımı bir sonraki tam mumdan başlar. Varsayılan: kapalı (mevcut davranış).

KADEMELİ EKLEME: STOPU GEVŞETME --scale-in-no-loosen

Kademeli ekleme sonrası stop normalde yeni ortalama girişe göre (%1.3) yeniden kurulur; TP1 sonrası girişin üstüne kilitlenmiş stop varsa bu onu geri gevşetir. İşaretlenirse yeni stop, mevcut stoptan daha kötü olamaz (TP1 öncesi davranış değişmez). Backtest'te ayrıca (onay mumu > 0 ise) ekleme, eşik fiyatı yerine eklemenin yapıldığı anki gerçek fiyattan dolmuş sayılır. Varsayılan: işaretsiz (mevcut davranış).

TP2'DE 2. KADEMELİ EKLEME

Açıksa: ilk kademeli ekleme yapılmış bir işlemde TP2 vurulduktan sonra, aşağıdaki tutar kadar ek teminat (x kaldıraç) piyasa emriyle eklenir. Ortalama giriş borsadan okunur, TP3-TP5 yeni ortalamaya göre yeniden hesaplanır; stop değişmez. İşlem başına bir kez uygulanır. Her hesap (ana + yansıtılan) aynı tutarı ekler. Varsayılan: kapalı.

2. EKLEME TUTARI (USDT, teminat)

TP2 SONRASI STOP MESAFESİ % (TP2'nin gerisi) TP2 vurulunca stop, TP2 fiyatının bu yüzde kadar gerisine kurulur (LONG aşağı, SHORT yukarı). Küçük değer = daha çok kâr kilitli ama gürültüyle erken stop riski. Varsayılan 0,3 (eski davranış).

TP3 SONRASI STOP MESAFESİ % (TP3/TP4'ün gerisi) TP3 (ve TP4) vurulunca stop, vurulan hedefin bu yüzde kadar gerisine kurulur (LONG aşağı, SHORT yukarı). Varsayılan 0,2 (eski sabit davranış).

240DK BAŞABAŞ KORUMASI --breakeven-240

İşlem 240 dk açık kalıp TP1 vurulmadıysa stop girişe çekilir; 240 dk daha TP1 gelmezse işlem kapatılır. Kapatılırsa bu iki aşama çalışmaz, işlem stop/TP ile sonuçlanana kadar açık kalır. TP1 sonrası 240dk koruması etkilenmez. Varsayılan: işaretli (mevcut davranış).

TP1 STOP KİLİDİ: KORUMACI GİRİŞ --tp1-protective-entry

Kademeli ekleme yapılmış işlemlerde TP1 sonrası stop hem ilk girişten hem de ortalama girişten hesaplanır; daha korumacı olan (LONG'ta yüksek, SHORT'ta düşük) seçilir. Böylece "kâr kilidi" stopu ortalama girişin zarar tarafında kalıp TP1 sonrası saniyeler içinde zararla patlamaz. Kademeli ekleme yoksa etkisizdir. Varsayılan: işaretli.

KADEMELİ ONAY MUMU SÜRESİ --scale-in-confirm-minutes Kademeli Onay Mumu Sayısı bu süredeki mumlarla sayılır. Düşük süre = onay daha hızlı tamamlanır (TP1'e çok hızlı ulaşan işlemlerde onay TP1'den önce bitebilir) ama daha gürültülüdür. Sayı 0 ise etkisi yoktur. Varsayılan: 5 dakika (mevcut davranış).

KADEMELİ SONRASI TERS MUM İLE OTOMATİK KAPAT (ADET) --reverse-candle-exit Pozisyona ekleme (scale-in) GERÇEKLEŞTİKTEN sonra, pozisyon yönüne ters kapanan ÜST ÜSTE bu kadar 5dk mum gelirse işlem otomatik kapatılır ("ters mum" = mumun kendi açılış/kapanışına göre pozisyona ters yönde kapanması). Araya uyumlu bir mum girerse sayaç sıfırlanır. 0 = kapalı (varsayılan). Ekleme hiç yapılmamışsa bu ayarın hiçbir etkisi yoktur.

ÜYELİKTE TEK KULLANIMLIK E-POSTAYI ENGELLE

Kayıt sırasında e-posta alan adı; yerleşik liste + herkese açık "disposable-email-domains" listesi (24 saatte bir otomatik güncellenir) ve aşağıdaki ek listeyle karşılaştırılır. Eşleşirse kayıt reddedilir. Mevcut e-posta doğrulama linki zorunluluğu ayrıca devam eder. Varsayılan: işaretli.

EK ENGEL LİSTESİ (alan adları)

İZİN LİSTESİ (hiçbir zaman engellenmesin) İzin listesi, yerleşik/otomatik liste ve ek engel listesinin hepsinden önceliklidir. Alt alan adları da kapsanır (x.ornek.com → ornek.com).

TERS MUM KURALI: EKLEMEDEN SONRA BEKLEME (DK) --reverse-candle-delay Ters mum ile otomatik kapatma kuralı, kademeli eklemeden bu kadar dakika SONRA devreye girer; bekleme süresince gelen ters mumlar sayılmaz. 0 = bekleme yok (ekleme anından itibaren çalışır). Varsayılan: 60 dk.

TERS MUM EŞİĞİNDE YAPILACAK İŞLEM --reverse-candle-mode "Pozisyonu Kapat" eski davranıştır. "Sadece Stopu Çek" pozisyonu KAPATMAZ, stopu son ters mumun kapanış fiyatına çeker (sadece daha sıkı bir stopsa) ve sayaç sıfırlanıp izlemeye devam eder — bir sonraki eşikte tekrar tetiklenebilir. Mirror hesaplara da aynı şekilde uygulanır.

TRAILING GECİKME SÜRESİ (sn) --trailing-delay-seconds TP1 vurulduktan sonra trailing stop'un stop'u sıkılaştırmaya başlamadan önce bekleyeceği süre. Bu sürede fiyat lehte ilerliyorsa (veya gürültü seviyesinde duruyorsa) stop'a dokunulmaz; gerçek bir geri çekilme (≥%0.05) görülürse veya süre dolarsa trailing hemen (ulaşılmış en iyi zirveyi kullanarak) devreye girer. TÜM hesapları etkileyen tek global ayardır. 0 = eski davranış (gecikmesiz, anında trailing). Varsayılan: 10.

TP1 SONRASI STOP KİLİDİ % --tp1-stop-lock-pct TP1 vurulduğu AN stop'un Giriş ile TP1 arasının yüzde kaçına kilitleneceği (ör. 90 = stop, TP1'e sadece %10 pay bırakacak şekilde sıkılaştırılır; düşürürseniz stop TP1'den daha uzakta/gevşek kalır). Bu İLK kilit, yukarıdaki TRAILING GECİKME SÜRESİ'nden ETKİLENMEZ — o ayar sadece TP1'den SONRAKİ ek sıkılaştırmayı geciktirir. TÜM hesapları etkileyen tek global ayardır. Varsayılan: 90 (mevcut, değişmeyen davranış).

KADEMELİ SONRASI STOP-LOSS % --scale-in-stop-pct Kademeli ekleme GERÇEKLEŞTİĞİ anda yeni (ağırlıklı ortalama) girişe göre stop'un kaç yüzde mesafeye çekileceği. Boş bırakılırsa (varsayılan) eski davranış aynen sürer: stop, orijinal girişin stop oranını (yukarıdaki genel STOP LOSS %'i; örn. %1,3) yeni girişe uygular — yani "boş" = stop YOK demek değildir, varsayılan oran (orijinal giriş stop oranı) kullanılır. Bir değer girilirse, kademeli ekleme sonrası stop artık HER ZAMAN bu yüzdeyi kullanır — ör. büyüttükten sonra riski daha da sıkılaştırmak veya normal volatiliteye daha fazla tolerans tanımak için. TÜM hesapları etkileyen tek global ayardır. SADECE ScaleInEnabled açıkken VE gerçekten bir ekleme tetiklendiğinde etkisi vardır.

Eski (Riskli): Kademeli Sonrası Stop %1,3 Sınırını Aşabilsin --legacy-scale-in-stop

Doğrusu: stop, kademeli ekleme sonrası da her zaman botun sabit %1,3 max-risk kuralını (BotConfig.StopLossPercent) yeni (ağırlıklı ortalama) girişe göre korur — "sıkılaşması" burada riski ARTIRMAZ, tasarlanan orana geri dönmek anlamına gelir. Bu bayrak açıkken ise 03.09.2026'da eklenen ESKİ "asla sıkılaştırma" kelepçesi geri gelir: stop, ekleme öncesindeki mutlak fiyatta SABİT kalır — kademeli ekleme girişi yukarı kaydırdığı için bu, riski %1,3 tasarım sınırının ÇOK üzerine çıkarabilir (AKEUSDT örneğinde %8,27'ye, ~30 USDT'lik pozisyonda ~-27 USDT'lik olası zarara kadar). SADECE karşılaştırmalı/deneysel test amaçlı; artık "güvenli" seçenek DEĞİL. Gerçek parayla işlem açan canlı botu etkiler. Emin değilsen kapalı bırak.

TP1 Sürekli Trailing'i Kapat (Canlı) --no-tp1-trail

TP1 vurulduktan sonra (TP2'ye kadar) fiyat yeni bir zirve/dip yaptıkça stopun sürekli (500ms döngüsünde mikro adımlarla) o zirveye göre yeniden hesaplanıp lehe çekilmesi özelliği. Bu ayar, backtest aracındaki --no-tp1-trail ile AYNI şeyi canlıda yapar. Varsayılan (işaretsiz) durumda özellik AÇIKTIR — testlerinizde bu bayrağı KAPALI tutuyorsanız ve canlıyla birebir aynı senaryoyu karşılaştırmak istiyorsanız, backtest'te de --no-tp1-trail'i işaretsiz (kapalı) bırakın. Gerçek parayla işlem açan canlı botu etkiler.

Eski (Hatalı): TP1 Trailing'de Kademeli-Sonrası Girişi Kullan --legacy-tp1-trail-blended-entry

Doğrusu: TP1-sonrası %90 trailing formülü (Giriş + 0.9×(Zirve-Giriş)), kademeli ekleme yapılmış işlemlerde "Giriş" olarak ekleme ÖNCESİNDEKİ orijinal girişi kullanır — backtest aracı (TradeSimulator.cs) zaten HER ZAMAN böyle çalışıyordu, "kâr oranını artırdı" doğrulaması bu şekilde yapılmıştı. Bu bayrak açıkken ise canlının ŞU ANA KADARKİ (backtest'ten SAPAN) davranışı geri gelir: "Giriş" olarak kademeli ekleme SONRASI (ağırlıklı ortalama, zirveye çok daha yakın) giriş kullanılır — bu, zirveden izin verilen geri çekilme payını yapay olarak daraltıp normal/sıradan bir dalgalanmada bile pozisyonu erken durdurabilir (bkz. AKEUSDT vakası). SADECE karşılaştırmalı/deneysel test amaçlı; gerçek parayla işlem açan canlı botu etkiler. Emin değilsen kapalı bırak.

📈 Borsa Minimumuna Otomatik Yükselt (Normal Emirler)

Kapalıyken (varsayılan): normal boyuttaki bir emir (OrderSizeUsdt/PremiumOrderSizeUsdt/TrendOrderSizeUsdt) borsanın gerçek asgari işlem tutarının (MIN_NOTIONAL) altında kalırsa, Binance emri REDDEDER — işlem açılmaz. Açık iken: Kademeli açılıştaki AYNI otomatik yükseltme mekanizması normal emirlere de uygulanır — sembol atlanmaz, miktar borsa minimumunu karşılayacak şekilde yukarı yuvarlanır. SADECE canlı botu etkiler — bkz. yukarıdaki not, backtest'te bir karşılığı yok.

Aktif (backtest karşılığı yok)

GÜVENLİK SINIRI (ZORUNLU MARGIN TAVANI, USDT) (backtest karşılığı yok) Borsa minimumu yüzünden yukarı yuvarlanan miktarın gerçek margin karşılığı bu tutarı aşarsa, sürpriz büyük pozisyon açılmasın diye işlem HİÇ AÇILMAZ. Kademeli açılıştaki "Güvenlik Sınırı" ile AYNI mantık ama BAĞIMSIZ bir ayar (normal emir boyutu kademelininkinden farklı olabileceği için ikisi ayrı ayrı ayarlanabilir). Varsayılan: 50

⏱️ LOT_SIZE Önbellek Süresi

İşlem açılışında miktar hassasiyeti (LOT_SIZE) ve limitleri (MaxQuantity, MinNotional) artık her seferinde canlı çekilmek yerine, sembol bazlı bu süre kadar önbellekte tutuluyor — art arda gelen sinyallerde gereksiz borsa çağrısı önlenir. Bu veriler Binance'te çok nadir değişir; değişse bile Binance emri kendi tarafında ayrıca doğruladığı için yanlış ama kabul edilen bir işlem riski oluşmaz, sadece emir reddedilip loglanır.

ÖNBELLEK SÜRESİ (SANİYE) (backtest karşılığı yok) Bu süre boyunca aynı sembol için borsaya tekrar sorulmaz. Bot her restart edildiğinde önbellek otomatik olarak boşalır. Varsayılan: 45

Önbellek içeriği henüz yüklenmedi.

🕯️ 5dk Mum Onayı (EXTREME)

Hem canlı botun EXTREME sinyallerini (Trend/Breakout etkilenmez) hem de ScalpEngineBacktest aracının CLI varsayılanını yönetir. EXTREME kriterleri geçtikten sonra işlem hemen açılmaz — aday "onay bekliyor" durumuna geçer (bildirim gönderilmez, sadece konsol logu) ve ardışık kapanan bu kadar 5dk mumun rengi (LONG→yeşil, SHORT→kırmızı) yönle uyuşmazsa aday tamamen reddedilir; uyuşursa işlem o anki güncel fiyatla açılır. Backtest aracı çalıştırıldığında --confirm-5m-candles bayrağı CLI'dan VERİLMEZSE buradaki değeri varsayılan olarak kullanır; CLI'dan açıkça verilirse (sadece backtest tarafında) CLI önceliklidir.

ONAY BEKLENECEK 5DK MUM SAYISI --confirm-5m-candles 0 = kapalı (eski davranış, sinyal anında açılır — hem canlı bot hem backtest için). N ne olursa olsun her zaman N tane YENİ KAPANAN 5dk mum aranır (tespit anında oluşmakta olan mum hiçbir zaman sayılmaz). Kullanıcının test etmek istediği değer: 2

KAÇIRMA HAKKI --confirm-5m-miss-tolerance Bekleme sırasında yanlış renkli bir mum geldiğinde, adayı ANINDA iptal etmek yerine bu kadar "kaçırma hakkı" tanınır — onay sayısı sıfırlanmaz, sadece o mum ilerlemeye katkı vermez. Haklar bu değeri AŞARSA aday tamamen iptal edilir. 0 = eski davranış (ilk yanlış mumda anında iptal). Varsayılan: 1.
Örnek (SHORT, onay=2, hak=1): 1. mum YEŞİL gelir → hak kullanılır (1/1), onay sayısı 0'da kalır, AYNI mum tekrar denenmez — sıradaki (2.) muma geçilir. 2. mum KIRMIZI → onay 1/2. 3. mum KIRMIZI → onay 2/2, işlem açılır. (2. mum de yanlış gelseydi hak sınırı aşılır, aday tamamen iptal edilirdi.)

2 Dakikalık Mum Onayı Aransın kapatılırsa → --no-2m-gate

Açıkken (varsayılan), EXTREME sinyali İLK TESPİT edilirken RSI5m aralık kontrolüne EK OLARAK son kapanan 2 dakikalık mumun da yönle uyuşması (LONG→yeşil, SHORT→kırmızı) zorunludur — uyuşmazsa sinyal "onay bekliyor" aşamasına bile geçmeden reddedilir. Kapatılırsa bu ek şart aranmaz, tek onay mekanizması yukarıdaki "Onay Beklenecek 5dk Mum Sayısı" olur. ScalpEngineBacktest aracında da aynı bayrağı deneyip karşılaştırabilirsin.

Canlı Mum Verisi DB'ye Kaydedilsin candle_cache_enabled

SAKLAMA SÜRESİ (GÜN) candle_cache_retention_days

Açıkken (varsayılan), bot her sinyal teşhisi yazarken o coinin kapanmış 15dk ve 5dk mumlarını da kaydeder. Backtest'te "Canlı - Backtest Sonuçlarını Doğrulama Modu" / "Canlının gördüğü mumları kullan" seçiliyken Binance'ten indirilen mumların üzerine bu kayıtlar yazılır. Kapatılırsa yeni kayıt yapılmaz (mevcut kayıtlar saklama süresi dolana kadar kalır).

🧮 Maks. Eşzamanlı Açık İşlem (Global)

Bir hesabın (Ana veya herhangi bir Mirror) açık pozisyon sayısı (Extreme+Trend+Breakout TÜMÜ birlikte) bu değere ulaştığında o hesapta yeni işlem açılmaz. "Hesap Düzenle" ekranındaki hesap bazlı "Maks. Extreme Pozisyon" / "Maks. Trend Pozisyon" ayarlarından FARKLIDIR ve onları değiştirmez — bu, TÜM hesaplar için geçerli, ek bir global tavandır (ikisinden hangisi önce dolarsa işlemi o durdurur). ScalpEngineBacktest aracının --max-concurrent-positions CLI bayrağı verilmediğinde de bu değeri varsayılan olarak kullanır.

MAKS. EŞZAMANLI AÇIK İŞLEM --max-concurrent-positions

2FA Doğrulama Kodunu 24 Saat Hatırla

Açıkken (varsayılan), 2FA'sı açık bir hesap son 24 saat içinde bir kodu başarıyla doğrulamışsa, o hesap tekrar giriş yaptığında kod YENİDEN istenmez (şifre doğruysa direkt girer). Kapatılırsa her girişte, en son ne zaman doğrulandığına bakılmaksızın, HER ZAMAN yeni bir kod istenir. Bu ayar hangi hesapların 2FA kullandığını DEĞİŞTİRMEZ — sadece kodun ne sıklıkla sorulacağını belirler.

Burada bir liste tanımlarsan bot artık SADECE bu coinleri tarar ve bu coinler dışında hiçbir sembol için sinyal üretmez ya da işlem açmaz (tüm hesaplarda geçerli, hesap bazlı değil). Liste boş bırakılırsa (varsayılan) kısıtlama olmaz, bot eskisi gibi tüm hacimli coinleri tarar. Sembolleri virgül, boşluk veya yeni satırla ayırarak yazabilirsin — "USDT" ekini yazmazsan otomatik eklenir (ör. "BTC" → "BTCUSDT"). Değişiklik en geç ~60 saniye içinde canlı taramaya yansır.

Buraya eklenen coinler taranmaya ve Canlı Tarama Listesi'nde görünmeye devam eder — sadece bu coinlerde YENİ İŞLEM açılması engellenir (yukarıdaki izinli listeden farkı budur: o taramayı kısıtlar, bu sadece işlem açmayı). Tüm hesaplarda geçerlidir, hesap bazlı değildir. Backtest de bu listeyi AYNEN uygular (canlı ile tutarlı sonuç). Sembolleri virgül, boşluk veya yeni satırla ayırarak yazabilirsin — "USDT" ekini yazmazsan otomatik eklenir. Değişiklik en geç ~60 saniye içinde yansır.

Dikkat: BTCUSDT, ETHUSDT ve HUSDT bu listede varsayılan olarak bulunur (asla işlem açılmaması için). Bu 3 sembolü listeden çıkarırsan bot artık onlarda da gerçek işlem açabilir.

Botun her gün gerçekten taradığı GLOBAL hacimli coin evreninin günlük dökümü — hesap bazlı değil, tek bir evren. Bir gün bir coinin listede olması o gün en az bir kez taranan evrende göründüğü anlamına gelir, o coinde işlem açıldığı anlamına gelmez (açılan işlemler için "İşlem Listesi" veya "Sinyal Analiz" sekmelerine bakın). Kayıt bu özelliğin eklendiği tarihten (~18.08.2026) itibaren birikmeye başlamıştır, öncesi için veri yoktur.

HESAP (Kanal)

KOMUT

Kullanılabilir komutlar

Açıklamasını görmek (ve KOMUT kutusuna doldurmak) için yukarıdan bir komuta tıkla.

Coin / Sembol

Hesap

Başlangıç

Bitiş

Zaman	Seviye	Hesap	Mesaj
Yükleniyor...

Günlük Özet

En Çok Kazandıran / Kaybettiren Coinler

Yukarıdaki tarih aralığı/hesap/Canlı-Backtest seçimine göre, sembol bazında sıralanmış ilk 10 kazandıran ve ilk 10 kaybettiren coin. Backtest'te sıralama ve tutar, Detaylar panelindeki "Net Kazanç" ile AYNI hesaba (--scale-in GERÇEKTEN tetiklendiyse gerçek kademeli sonuç, tetiklenmediyse kaldıraç × işlem büyüklüğü) göre USDT cinsinden gösterilir; Canlı'da ise gerçek Binance net sonucu (zaten kesinleşmiş USDT) kullanılır.

En Çok Kazandıranlar

En Çok Kaybettirenler

Sınırda Kaçırılanlar

RSI eşiği tetiklendi ama ADX tavanı/toleransı ya da DI toleransı gibi bir eşik çok küçük bir farkla (≤1 puan) kaçırıldı — bunlar SİNYAL DEĞİL, sadece "az kalsın yakalanıyordu" adayları. Sadece backtest aracı --log-borderline ile çalıştırıldıysa dolu olur.

Bu tablo ile 5dk Mum Onayı'nı karıştırma: 5dk Mum Onayı KANITLANMIŞ bir strateji filtresidir (daha az ama daha kaliteli işlem açtırdığı test edildi). Buradaki marjlar ise --boundary-tolerance ile ilgili — bir strateji iyileştirmesi DEĞİL, canlı ile backtest'in aynı anı bağımsız yeniden hesaplarken yuvarlama/veri farkıyla az sapabildiğini telafi eden bir ÖLÇÜM DÜZELTMESİDİR. Açmak backtest'e daha fazla sinyal yakalatır ama bunlar illa "daha iyi" sinyaller değildir — körlemesine açmak yerine adayları teker teker (verify komutuyla) inceleyip karar vermek önerilir.

"Gerekli Eşik" değerini girdim, neden hâlâ kazanç görmüyorum? "Gerekli Eşik" kolonu size SADECE reddedilme sebebi olan tek sayısal eşiği (ADX tavanı/toleransı ya da DI toleransı) geçirecek minimum değeri gösterir — bu, adayın gerçek bir sinyale dönüşeceğini garanti etmez, çünkü bu hesap şunları HİÇ kontrol etmez: (1) o coin/yön o an cooldown/kilit altında olabilir, (2) eşzamanlı pozisyon limiti (--max-concurrent-positions) o an dolu olabilir, (3) sinyal 5dk mum onayı (--confirm-5m-candles) bekliyorsa fiyat tersine dönüp onayı hiç geçmeyebilir. "Kaçırılmasaydı" sütunu ise artık HER ÜÇÜNÜ de hesaba katıyor — koşumun gerçek scale-in/5dk onayı ayarlarını kullanıyor, kilit altındaki veya onayı geçmeyen adaylarda kolonu boş bırakıyor, VE hipotetik giriş anında zaten pozisyon limiti dolu olan adayları da aynı şekilde boşaltıyor. Kısacası: eşiği gerektiği kadar açmak gerekli ama yeterli değildir — "Kaçırılmasaydı" sütununda bir değer görüyorsan ve o adayın eşiğini genişletip yeniden test edersen, artık bu üç kapıdan biri yüzünden sürpriz bir sapma yaşama ihtimalin çok düşük. Yine de üstelik önceki mesajımızdaki bulgu gösteriyor ki (bkz. koşum geçmişi karşılaştırması) sınırdaki adaylar genelde ZATEN zayıf sinyaller olduğu için, toleransı gevşetmek çoğu zaman kazancı artırmak yerine ek kayıp getiriyor. En güvenilir yol: adayları "Kaçırılan Kapılar", "Gerekli Eşik" ve "Kaçırılmasaydı" sütunlarına bakarak teker teker inceleyip (özellikle marj çok küçükse, ör. ±0.5 civarı), sadece GERÇEKTEN güçlü görünen birkaç adayı hedefleyen küçük/ölçülü bir ayar denemek ve sonucu "Önceki Koşum (Marj)" ile karşılaştırmaktır — toplu/kör bir tolerans artışı yerine.

İşlem Listesi

–

Kapanan işlemler, en yeniden en eskiye (en fazla 20 işlem). Detayları görmek için satıra tıkla.

Zaman	Hesap	Sembol	Yön	Durum	İlerleme	Detay
Yükleniyor...

Geçmiş Backtest Koşumları

Her satır bir koşumu (run) temsil eder — çalıştırıldığı TAM parametre satırıyla birlikte. Artık yeni bir koşumdan önce tüm veriyi silmek ZORUNLU değil: koşumlar birbirinden ayırt edilebiliyor, istediğini "Görüntüle" ile İşlem Listesi'nde tek başına incele, istemediğini "Sil" ile SADECE o koşumu kaldır. Bu liste AYRI, kalıcı bir tabloda tutulur — yukarıdaki "Backtest Verilerini Temizle" butonu (ham işlem satırlarını siler) bu listeyi SİLMEZ; yalnızca "Görüntüle" ile açılan İşlem Listesi'ndeki işlemler o zaman boş görünür (koşumun özeti/parametreleri hâlâ burada kalır). "Etiketsiz (Eski)" grubu, bu özellik eklenmeden ÖNCE yazılmış, hiçbir koşuma ayrıştırılamayan (ve bu yüzden hâlâ "Temizle" ile silinebilen) satırları temsil eder.

Aynı tarih aralığını birden fazla kez test edersem veriler karışır mı? Hayır — koşum kimliği (run_id) test ettiğin tarih aralığına göre değil, koşumu BAŞLATTIĞIN ANA göre üretilir (saniye hassasiyetinde). Yani "1-3 Eylül"ü iki ayrı zamanda çalıştırsan bile her koşum kendi ayrı kimliğiyle, bu tabloda AYRI birer satır olarak durur — sayıları birbirine karışmaz, her koşumun kendi İşlem/Kazanan/PNL toplamı izole kalır. Tek dikkat: İşlem Listesi'ni "Görüntüle" ile filtrelemeden (yani tüm backtest verisi görünümündeyken) incelersen, birden fazla koşumun işlemlerini YAN YANA, karışık görürsün (aynı dönemi test ettiysen sonuçlar da neredeyse birebir aynı çıkacağından "aynı işlem 2 kere mi kaydedilmiş" gibi görünebilir — değil, 2 ayrı koşumun kendi satırları). Karışıklığı önlemek için incelerken her zaman ilgili koşumun "Görüntüle" butonuna bas.

Fiyatın hangi seviyelerde yoğun kaldıraçlı pozisyon likidasyonuyla karşılaşabileceğini gösteren tahmini bir harita (Coinglass'ın "Liquidation Heatmap"iyle aynı mantık).

Bu GERÇEK pozisyon verisi değildir. Hiçbir borsa (Binance dahil) açık pozisyonların hangi kaldıraçla açıldığını halka açık paylaşmaz. Burada gösterilen, Binance'in ücretsiz herkese açık Open Interest ve Long/Short hesap oranı verilerine, yaygın perakende kaldıraç kullanımına dayalı bir VARSAYIMLA (5x/10x/20x/25x/50x/75x/100x/125x kademeleri) uygulanan tahmini bir modeldir. Fikir verir, kesin değildir.

Otomatik yenile (45sn)

Likidite Eşiği: 0.00 (0 = tümü görünür, 1'e yaklaştıkça sadece en yoğun bantlar kalır)

Renk yoğunluğu = tahmini likidasyon büyüklüğü (koyu mor: düşük → krem: yüksek) Güncel Fiyat (altı Long, üstü Short) Sağ Panel: Short Riski (üst) Long Riski (alt)

Kaynak Borsalar:

Sorgula'ya basarak haritayı yükleyin.

İşlem Listesi

Kapanan işlemler, en yeniden en eskiye (en fazla 20 işlem). Detayları görmek için satıra tıkla.

Son Ziyaretler

IP bazında en yeniden en eskiye, seçilen aralıktaki son 100 ziyaret.

Son 1 Saat

RAM Kullanımı (%) · her mum ~5 ölçüm

Ağ Trafiği (Kbps) — ↑ Alınan (üst) / ↓ Gönderilen (alt)

İstek Ölçümü · botun dakikada attığı HTTP istekleri (son 60 dk)

Son Ölçümler

Gerçek Günlük Coin Evreni --daily-universe Canlı Hacim Kapısı (P-VOL) --live-vol-gate Global Hacim Kapısı --global-vol-gate Cache Kullanma (taze veri) --no-cache Testnet Verisi --testnet Sınırda Kaçırılanları Logla --log-borderline Canlı - Backtest Sonuçlarını Doğrulama Modu --live-snapshot-verify Giriş fiyatını canlıdan al --live-entry Sadece "Canlı - Backtest Sonuçlarını Doğrulama Modu" ile kullanılır Canlının gördüğü mumları kullan --candle-db 2 Dakikalık Mum Onayı Aransın kapatılırsa → --no-2m-gate Agresif Modda da Trend 15dk Şartı Aransın --require-trend-15m-agresif Agresif Modda da P-VOL Şartı Aransın --require-p-vol-agresif

Ana anahtar "Kademeli Pozisyon Büyüklüğü" işaretli değilse bu bölümdeki ayarların hiçbiri etkili olmaz. Sıra: ne zaman eklenir → onay mumu → ekleme sonrası stop → 2. ekleme.

Kademeli Pozisyon Büyüklüğü --scale-in Eski (Riskli): Kademeli Sonrası Stop %1,3 Sınırını Aşabilsin --legacy-scale-in-stop

Sadece kademeli ekleme gerçekleşmişse çalışır. Adet 0 ise kural kapalıdır; bekleme ve mod ancak adet > 0 iken etkilidir.

TP1 sonrası trailing/kilit ve 240dk başabaş koruması.

TP1 Sürekli Trailing'i Kapat --no-tp1-trail

Backtest Klasörü

ScalpEngineBacktest projesinin (ScalpEngineBacktest.csproj'un bulunduğu) klasör yolu — bu makinede, botun erişebildiği bir yol olmalı. Bir kere ayarlaman yeterli.

Yapıştır ve çalıştır — formu doldurmadan. Tam dotnet run -- ... komutunu (veya sadece --days 1 ... bayrak kısmını) aşağıya yapıştırın. Yukarıdaki formla İLGİSİZDİR, doğrudan çalıştırılır. --out/--run-id vermezseniz otomatik eklenir.

Henüz bir backtest çalıştırılmadı.

AI BotConsole

Passkey

2FA

Kullanıcı

Emin misiniz?

Hesap Ayarları

Tüm Hesapları Canlı/Demo Yap

Yeni Rol

Trading Ayar Talebi

Mesaj Gönder

Üye Bilgileri

Kriter Analizi — Nasıl Çalışır?