Solana Multi-Sender Rehberi: Airdrop, Batch, Snapshot

Solana üzerinde iş yapan herkes eninde sonunda aynı temel işlemle karşılaşır. Aynı anda çok sayıda cüzdana token göndermek gerekir. Airdrop, ekip ödemesi, affiliate dağıtımı, partner payı, KOL kampanyası: hepsi aynı operasyon, aynı veri şekli. Bu işi yapan araç bir multi-sender'dır.

Bu yazı multi-sender'ı merkeze alır. Snapshot ve batch-collector, ona tek bir fikir üzerinden bağlanan yardımcı araçlar: adres ve miktar içeren alıcı listesi. Üç farklı akış, tek bir temel işlem. Snapshot'ın ne olduğunu, airdrop'ın ne olduğunu zaten biliyorsan, asıl değer akış kalıplarında, tanımlarda değil.

Multi-sender aslında ne yapar

Girdi bir alıcı listesidir. CSV ya da JSON, her satırda bir cüzdan, adres ve miktar. Solana multi sender aracı bir çalıştırmada en fazla 1000 alıcı kabul eder ve veri şekli elinle yazsan aynı çıkardı:

// alıcı listesi şekli
[
  { address: "9xQ...", amount: 1500 },
  { address: "FbR...", amount: 250 },
  { address: "7Pz...", amount: 10 }
]

Handler listede tek tek dolaşır, her transferi gönderici keypair'iyle imzalar, ayarlı RPC üzerinden zincire iter. Public key'leri doğrular, miktarları token'ın decimals değerine göre normalize eder, alıcı tarafında Associated Token Account yoksa onu açar, her işlemi imzasıyla ya da hata sebebiyle kayda alır. Çıkış satır satır rapordur: hangi transfer indi, hangisi takıldı, cüzdandan toplam ne çıktı.

Mekanik kasıtlı olarak sıkıcıdır. İlginç olan kısım alıcı listesini neyin beslediğidir. Üç akış birbirinden tam orada ayrılır.

Akış A, snapshot'tan beslenen airdrop

Alıcı listesi zincirden gelir. Bir token seçersin, Solana token snapshot aracı ile o token'ı tutan her cüzdanı çekersin, listeyi süzersin, hayatta kalan satırları multi-sender'a verirsin. Snapshot'ın kendi mekaniği Solana holder snapshot rehberi içinde duruyor; burası elinde dosya olduktan sonrasını anlatır.

Süzme adımı snapshot'ın kendisinden daha kritiktir. Ham holder listesi, merkezi borsa sıcak cüzdanlarını, Raydium ve Meteora havuz hesaplarını, lending market'leri, vault'ları, yapısı gereği bakiye taşıyan smart contract'ları yakalar. O adreslere gönderirsen tokenlar ya borsa hazinesine düşer ya da iletme yetkisi olmayan bir program hesabında kilitli kalır. Düzeltme mekaniktir:

• Etiketli CEX sıcak cüzdan listelerinde geçen adresleri (Binance, Coinbase, Kraken, OKX, Bybit, Bitget, MEXC) çıkar.
• Havuz program sahiplerini (Raydium AMM, Meteora DLMM, Orca whirlpools) ve bilinen router adreslerini çıkar.
• SOL bakiyesi çok düşük, token bakiyesi de minik olan cüzdanları çıkar. Bu kombinasyon hem sybil sinyalidir hem de ATA rent kaybıdır.
• Minimum bakiye eşiği koy. Yüzde 0.0001'lik bir holder'a 5 token göndermek, çoğu zaman airdrop'ın kendisinden pahalıya patlar.

Kampanya kademeli olacaksa (büyük holder'a fazla, küçüğe az), kademe matematiğini liste multi-sender'a ulaşmadan önce burada yaparsın. Hak ediş, sybil süzgeci ve kademe şekillendirme için daha derin anlatım snapshot tabanlı airdrop rehberi içinde duruyor.

Akış B, elle hazırlanmış batch ödeme

Bu sefer liste zincirden gelmez. Sen yazdın. Ekip dağıtımı: 12 cüzdan, isimle eşleşmiş miktarlar. Affiliate ödemesi: son fatura döneminden 60 cüzdan. Co-marketing anlaşması için partner payı: 4 cüzdan, gün fiyatından token'a çevrilmiş dolar değerleri. KOL kampanyası kapanışı: 30 cüzdan, sözleşmedeki miktarlar.

Alıcı sayısı küçüktür. Satır başına miktar geniş bir aralıkta değişir. Liste bir spreadsheet'te, bir faturalama panelinde ya da bir sözleşme tablosunda yaşar, zincirde değil. Süzme adımı yoktur çünkü satırları zaten sen düzenledin. Aynı Solana multi sender aracına verirsin, çalıştırırsın, işlem raporunu muhasebe için arşivlersin.

Çoğu ekibin en sık kullandığı akış budur. Airdrop launch'ta olur. Ödeme her ay olur. Disiplin spreadsheet'tedir: tek doğru kaynak, sürüm takibi, çalıştırmadan önce onay.

Çalıştırmadan önce gönderici cüzdanın SOL bakiyesini, alıcı sayısı kere rahat bir transfer ücreti tahminiyle çarp, ihtiyaç duyulabilecek ATA rent'lerini de ekle. 400 satırlık bir ödemenin ortasında fee SOL'ü bitmesi en sık görülen toplu ödeme arızasıdır ve rapor dosyası tam olarak nerede durduğunu sana söyler.

Akış C, kurtarma ve temizlik

Bazen ters yöne göndermek gerekir. Çok kaynak, tek hedef. Şekli multi-sender'ın tersidir ve kendi aracı vardır: batch collector aracı. En sık görülen durumlar:

• Toz temizliği. Test için ya da kademeli alımlar için kullandığın yedek cüzdanlara dağılmış onlarca küçük bakiye.
• Hazine konsolidasyonu. Ücret, iade ya da rutin işlerden bakiye biriktirmiş operasyon cüzdanları.
• Talep edilmemiş airdrop'ların geri çekilmesi. Kontrol ettiğin cüzdanlara giden ama hiç dokunulmamış tokenlar.
• Migrasyon öncesi süpürme. v2 launch'ı ya da token swap'ı öncesinde, eski mint'teki tüm bakiyeleri köprüye girmek üzere tek noktaya çekme.

Mekanik olarak batch-collector kaynak cüzdan listesi (her birinde private key), tek bir hedef adres, opsiyonel cüzdan başı miktar ya da "hepsini topla" bayrağı ve kaynağın sonraki işlemler için fee ödeyebilmesi adına geride bırakılacak opsiyonel SOL rezervi alır. Listeyi gezer, her kaynaktan imzalar, bakiyeyi hedefe iter. Handler kapanış transferinin kendisinin de fee bütçesi olsun diye her kaynakta küçük bir SOL rezervi bırakır.

Hangi akış ne zaman

Üç akış dışarıdan benzer görünür (liste, araç, sonuç) ama girdi kaynağı ve sıklık farklıdır. Çalıştırmadan önce kendine uyan satırı seç.

Akış	Alıcı listesi kaynağı	Tipik ölçek	Sıklık	Ne zaman
Snapshot airdrop	Token holder snapshot, süzülmüş	500 ile 10000 arası	Launch ya da kampanya başına	Zincir bakiyeleriyle tanımlı bir topluluğa ulaşmak
Elle batch ödeme	Şirket içi spreadsheet ya da faturalama	5 ile 200 arası	Tekrarlayan (aylık, haftalık)	Operasyonel yükümlülükler: ekip, affiliate, partner
Kurtarma ve temizlik	Senin kontrolündeki cüzdanlar	10 ile 500 arası	Gerek duydukça, migrasyon ya da çeyrek kapanışı öncesi	Dağılmış bakiyeleri hazineye geri çekmek

j.tools üzerinden uçtan uca kurulum

Üç aracın ortak veri modeli var; akışlar arada çeviri adımı olmadan birbirine bağlanır.

1. Besleyici: holder gerekiyorsa Solana token snapshot aracını çalıştır. JSON dışa aktar, süzgecini uygula, alıcı listesini kur.
2. Dağıtım: listeyi Solana multi sender aracına ver. Token tipi SOL ya da SPL, SPL ise mint adresi, gönderici keypair, RPC endpoint. Çalıştır. İşlem raporunu sakla.
3. Toplama: ters yön için batch collector aracı. Private key'leriyle kaynak cüzdanlar, tek hedef, boşaltmak istiyorsan collect-all bayrağı.

Airdrop'u tek bir cüzdandan değil de iki operasyon cüzdanından parça parça gönderiyorsan (örneğin cüzdan başı günlük limitlerin altında kalmak için), many-to-many transfer aracı bu özel durumu doğrudan karşılar.

Sık yapılan hatalar

Multi-sender problemlerinin çoğu işlem raporunda sonradan görünür ve dört sebepten birine bağlanır.

Gönderici cüzdanın fee SOL'ü ortada biter. Her transfer lamport ister, ATA açılması daha fazla. Yeni ATA'lı 1000 satırlık bir çalıştırma sadece fee için ciddi SOL talep eder. Rapor belli bir noktaya kadar başarılı satırları gösterir, sonrasında art arda "insufficient funds" hataları sıralanır.

ATA varlığı önceden kontrol edilmemiş. Alıcıların yarısında o mint için ATA yoksa, her biri için rent ödersin (SPL Token programında ATA başına yaklaşık 0.00203 SOL, Token-2022'de biraz farklı). Snapshot'taki opsiyonel SOL bakiyesi alanını ön taramaya kullan; SOL'ü sıfır ve ATA'sı olmayan alıcılar pahalı olanlardır.

Yönlendirmesi olmayan extension'lı Token-2022. Bazı Token-2022 mint'leri ekstra işlem gerektiren extension'lar taşır (transfer hooks, confidential transfers, bazı transfer fee yapıları). Standart SPL transfer akışı bunlarda başarısız olur ya da beklenmeyen şekilde davranır. 500 satırlık bir çalıştırmada normal SPL token gibi davranmadan önce mint'in extension setini doğrula.

Multi-sender'ı KYC'li dağıtımın yerine koyma. Araç token taşır. KYC, coğrafi kısıtlama ya da yaptırım taraması yapmaz. Bir kampanya bu kontrolleri gerektiriyorsa, upstream'de yapar, sadece geçen listeyi multi-sender'a verirsin. Araç sana verilen her adrese sadakatle gönderim yapar, göndermemen gerekenler dahil.

Önce devnet'te prova et. Test mint'i çıkar, gönderici cüzdana devnet SOL al, beş test cüzdanından oluşan bir alıcı listesiyle multi-sender'ı çalıştır, raporu doğrula. Bozuk bir CSV sütununu devnet'te yakalamak bedavadır; aynı hatayı mainnet'te yakalamak birkaç yüz dolar boşa giden fee ve halka açık bir başarısızlıktır.

Hepsini birbirine bağlayan örüntü

Multi-sender temel işlemdir. Etrafına kurduğun akış asıl ayrımı yaratır. Temiz bir snapshot, süzülmüş bir alıcı listesi, prova edilmiş bir çalıştırma, arşivlenmiş bir işlem raporu: insanlara gerçekten ulaşan airdrop'larla, bütçesinin yarısını ölü cüzdanlara sessizce yakanlar arasındaki fark işte budur.

Dağıtım ve hazine operasyonları için daha fazla anlatım Solana rehberleri kategorisinde duruyor, token mekaniğine dair geniş akış Solana etiketli yazılarda.