Güvenlik modelimiz

J Tools, token işlemlerini cüzdanının kontrolünü hiçbir zaman eline almadan yürütür. Cüzdanlarından gelen işlemler senin tarafında imzalanır, platform onları kurar ve gönderir, hepsinin arkasında da sunucu tarafındaki korumalar durur.

Kısa özet

#kisa-ozet

İpucu

Bağlı bir cüzdanın anahtarları o cüzdanın içinde kalır, ücret tutarı konusunda tarayıcıya asla güvenilmez ve gizli bilgiler log’ların dışında tutulur. Yönetici erişimi ikinci bir doğrulama adımıyla kilitlidir ve denetim kaydı, her kurcalamanın görüneceği şekilde kurulmuştur.

Tasarım gereği non-custodial

#tasarim-geregi-non-custodial

J Tools senden asla kurtarma ifadeni istemez ve fonlarını asla tutmaz. Bağlı bir cüzdan kullandığında her imza, cüzdan adaptörü üzerinden o cüzdanın içinde atılır ve ağa yalnızca imzalanmış işlem gider. Cüzdanın private key’i cüzdandan hiç çıkmaz.

J Tools sayfası

1J Tools'ta bir işlem hazırlarsın

İşlem cüzdanına gelir

Cüzdanın

2Cüzdanın işlemi gösterir

3Kendi cüzdanında onaylayıp imzalarsın

Bağlı cüzdanın anahtarları cüzdandan hiç çıkmaz

Yalnızca imza dışarı gider, anahtar asla

Solana

4İmzalı işlem Solana'ya yayınlanır

Bazı araçlar, hiçbir adaptörün bağlamadığı çok sayıda cüzdanla çalıştıkları için yapıştırdığın private key’lerle de imza atabilir: aralarında Paket İşlem, Çoklu Swap, Çoklu Gönderim, Bakiye Toplayıcı, relay araçları, Pump.fun Oluştur ve Bundle Al ve ücret çekme araçları var. Bu anahtarlar tarayıcı sekmende kalır, imzayı orada atar ve bize gönderilmez. Bir aracın private key kaynağına yapıştırılan anahtar 15 dakika sonra silinir. Bunları tek kullanımlık operasyon cüzdanları olarak gör. Sunucularımıza anahtar veren tek araç Holder Booster’dır: her çalıştırma için yeni bir dağıtıcı cüzdan oluşturur, holder cüzdanlarının anahtarlarını indirdiğin yedek dosyada tutar ve worker’ımız sen sekmeyi kapattıktan sonra da çalıştırmayı bitirebilsin diye yalnızca dağıtıcının anahtarını şifreli olarak gönderir. Bir sayfa senden kurtarma ifadeni (seed phrase) istiyorsa o biz değiliz.

Kurcalamayı belli eden bir denetim zinciri

#kurcalamayi-belli-eden-bir-denetim-zinciri

Yönetici işlemleri, yalnızca ekleme yapılabilen bir denetim log’una yazılır. Her satır, kendinden önceki satırın SHA-256 hash’i olan bir prev_hash taşır; kayıtlar böyle bir zincir gibi birbirine bağlanır. Bir satırı değiştirir ya da silersen ondan sonraki her hash eşleşmez olur ve değişiklik açıkça görünür. Log kayıtları parolaları ve oturum token’larını içermez.

RPC beyaz listesi ve hız limitleri

#rpc-beyaz-listesi-ve-hiz-limitleri

Tarayıcı ham bir Solana node’uyla konuşmaz. Yalnızca sabit bir okuma metotları listesine ve işlem gönderme ile simülasyona izin veren, IP başına istekleri sınırlayan bir ağ geçidinden geçer. RPC adresleri ve anahtarları sunucu tarafında kalır, yani tarayıcının sızdırabileceği bir şey yoktur. Hız limitleri her uç nokta için ayrı uygulanır ve gerçek istemci IP’si en sağdaki x-forwarded-for değerinden okunur; sahte bir header bu limiti atlatamaz.

Ücret hırsızlığına karşı koruma

#ucret-hirsizligina-karsi-koruma

Bir araç platform ücreti aldığında, komisyon için kaydedilen tutar kendi ücret ayarlarımızdan ya da platform cüzdanına zincirde gerçekten ulaşan SOL’dan gelir, tarayıcının gönderdiği bir sayıdan asla gelmez. Hiçbir yol istemcinin bildirdiği ücrete güvenmez. Herhangi bir şeyi onaylamadan önce tam dökümü (toplam, platform ücreti ve tahmini ağ ücreti) aracın ücret kartında görürsün. Referans değerler için uygulamadaki ücret özetine ya da Ücret tablosu sayfasına bak.

Dikkat

Ücretler hakkında. Her işlemin iki maliyeti vardır: validator’lara ödenen Solana ağ ücreti ve J Tools platform ücreti. Platform ücreti, onaylamadan önce uygulamada her zaman görünür ve sen imzalamadan hiçbir şey tahsil edilmez. Ücretler zamanla değişebilir, bu yüzden bir kez gördüğün sayıya değil, uygulamadaki özete güven.

Yönetici erişimi kilitli

#yonetici-erisimi-kilitli

Yönetici paneline ulaşmak için bir parola ve bir TOTP kodu gerekir ve ikisi de sunucuda zorunlu tutulur. Akış hiçbir şey ele vermeyecek şekilde kurulmuştur.

İkinci doğrulama Parola saklama Bilgi sızıntısı yok Oturumlar

TOTP zorunludur. Kodlar sunucu tarafında kontrol edilir ve art arda başarısız denemeler girişi bir bekleme süresi boyunca kilitler. Kilidin nedeni istemciye asla gönderilmez.

Yönetici parolaları yalnızca tek yönlü hash olarak saklanır ve ortam değişkenleriyle yapılandırılır. Panelde ya da API’de parola sıfırlama ekranı yoktur; parolayı değiştirmek yeni bir env değeri ve yeni bir deploy demektir.

Başarısız bir giriş; kullanıcı adı, parola ya da kod yanlış olsa da aynı genel mesajı döndürür ve bilinmeyen bir kullanıcı adının kontrolü, gerçek bir kullanıcı adınınki kadar sürer. Kilitlenen bir giriş yalnızca çok fazla deneme yapıldığını söyler, hangi sınırın aşıldığını asla söylemez. Giriş denemeleri hem IP hem de kullanıcı adı bazında hız limitine tabidir.

Oturumlar sunucu tarafındaki bir depoda; httpOnly, Secure ve SameSite=Strict çerezler ile rastgele kimliklerle tutulur. Oturum sabitlemeye (fixation) karşı her girişte yenilenir, boşta kalınca zaman aşımına uğrar ve yönetici başına sayısı sınırlıdır.

Her yerde OPSEC

#her-yerde-opsec

Operasyonel güvenlik, her uç noktada ve her sayfada geçerli sabit bir kuraldır. Gizli bilgiler, private key’ler ve tam token’lar log’ların dışında tutulur. İstemciye dönen bir hata yanıtı kısa bir mesaj taşır, çoğu zaman bir kodla birlikte; stack trace, iç dosya yolu ya da veritabanı ayrıntısı içermez, tüm resim sunucu log’larında kalır. Otomasyonun hazırladığı blog yazıları bir yönetici yayımlayana kadar taslak olarak kalır, yani bir kişi onay vermeden okuyuculara hiçbir şey ulaşmaz.