Polkadot

Polkadot, birçok özel blockchain’i (“parachain”) merkezi bir Relay Chain’e bağlayan çoklu zincir bir ağ protokolüdür. Relay Chain, paylaşılan güvenlik, fikir birliği ve zincirler arası uyumluluk sunarken, parachain’ler paralel olarak çalışır ve Polkadot’un zincirler arası fikir birliği mesajlaşması (XCM) ile iletişim kurar. Tasarımı, zincirler arası ölçeklenebilirlik ve bileşilebilirliği tek bir ağ içinde hedefler.

Polkadot’un mimarisinde, parachain’ler, blokları collator’lar tarafından üretilen ve Relay Chain doğrulayıcıları tarafından doğrulanan uygulamaya özgü zincirlerdir. Relay Chain’e bağlanarak, parachain’ler doğrulayıcı setinin ekonomik güvenliğini devralır ve XCM üzerinden diğer zincirlerle mesaj alışverişi yapabilir. Ayrıca, köprüler Polkadot’u harici ağlara bağlayabilir—örneğin, Ethereum için Snowbridge; Bitcoin’e bağlantı ise yerel bir light-client köprüsüyle değil, Interlay gibi parachain’ler aracılığıyla sağlanır. Zincirler arası mesajlaşmanın operasyonel detayları için, ilgili XCM bölümüne bakınız.

DOT, Relay Chain üzerindeki ağın yerel token’ıdır. Polkadot’un tanımında, üç temel işlevi destekler: protokolün yönetişimi, ağ güvenliği için staking ve bond (tarihsel olarak zincirleri ekleme mekanizması).

Polkadot’un kaynak modeli “Polkadot 2.0” ile evriliyor. Uzun süreli slot kiralama yerine, projeler Relay Chain işlemcisini coretime (sanal çekirdeklerde süre) kullanarak elde eder. Coretime, sistem zincirlerine yönetişim tarafından tahsis edilirken, diğer zincirler açık piyasadan satın alır.

DOT, Polkadot Relay Chain’in yerel token’ıdır ve ağın temel işlevlerini destekler:

Staking ile ağın güvenliği (NPoS): DOT sahipleri, blokların sonlanmasına yardımcı olmak ve sistemi dürüst tutmak için doğrulayıcıları aday gösterebilir veya doğrulayıcı çalıştırabilir. Stake edilen DOT, doğrulayıcı davranışını teminat altına alır ve staking ödülleri kazandırır; hatalı davranışlar cezalandırılabilir (slashing). Mekanikler ve riskler için: Nominated Proof-of-Stake ve Slashing.

Zincir üstü yönetişim (OpenGov): DOT, çoklu “track” üzerinden referandum önermek ve oy vermek, oy gücü yetkilendirmek ve protokol güncellemelerine ve sistem zinciri kararlarına katılmak için kullanılır. Track'ler, teminatlar ve yetkilendirme detayları için: OpenGov ve Kullanıcılar yönetişime nasıl katılır…

Ağ ücretleri ve gerekli teminatlar: Relay Chain’deki işlemler, DOT olarak ödenen ücretleri tüketir ve hesaplar aktif kalabilmek için minimum bakiye (existential deposit) bulundurmalıdır. Bazı zincir içi eylemler de iade edilebilir DOT teminatı gerektirir (ör: kimlik). Ücret türleri ve teminatlar için: DOT'un zincir üstü yardımcı işlevleri…

Polkadot 2.0’da Relay Chain işlemcisi (“coretime”) edinme: Projeler, Relay Chain çekirdeklerinde yürütme süresini DOT ile coretime satın alarak elde eder; bu DOT’lar yakılır. Bu model, uzun süreli slot kiralama/crowdloan’ların yerini alır. Ekonomi ve uygulama yolları için: Polkadot 2.0’da ne değişiyor… ve Bir ekip nasıl zincir başlatır…

Sistem fonlaması için zincir üstü Hazine: Hazineye gelen (blok ödüllerinin bir kısmı, ücretler, tip’ler, slashing’ler), DOT cinsinden olup—yönetişimle—onaylanan tekliflere harcanabilir. Süreç ve kapsam için: Zincir üstü Hazine nasıl çalışır…

Zincirler arası hareketlilik ve ekosistem kullanımı: DOT, XCM ile Relay Chain ve Asset Hub gibi sistem parachain’ler arasında taşınabilir; zincirler arası transferlerde hem kaynak hem hedef zincirde ücret alınabilir. Bazı parachain’ler/uygulamalar DOT’u yerel olarak kabul eder; diğerleri ise köprülenmiş/sarılmış (wrapped) temsiller gerektirir. Ayrıntılar ve uyarılar için: Asset Hub ve DOT diğer ağlarla nasıl birlikte çalışır…

Belirli ücret modeli, minimumlar, teminatlar ve staking akışlarına bakmak için, “DOT’un zincir üstü yardımcı işlevleri (staking, ücretler, yönetişim ve teminatlar)?” bölümü ile devam edin.

DOT, uygulanmaya konulduğunda ~%8/yıl olan ve artık sabit ~120 milyon DOT/yıl olarak süren sabit yıllık ihraca sahiptir; bu, toplam arz arttıkça yüzdesel enflasyon oranının zamana bağlı olarak azalmasına neden olur. Her yılki ihracın %15’i doğrudan Hazine’ye, %85’i ise staking ödüllerine (her era ödenir) tahsis edilir. OpenGov (Referandum #1139) ile tanımlanan bu parametreler, ağın çalışma koduna entegre edilmiştir.

Emisyon temposu ve dağılımı: Yeni DOT’lar sürekli olarak oluşturulur ve her eranın sonunda (~24 saatte bir Polkadot’ta) muhasebeleştirilir; ardından staking ödül mekanizmasına uygun olarak doğrulayıcılara ve adaylara dağıtılır; Hazine’nin %15’lik payı doğrudan sistem hesabına basılır. Sabit ihrac modelinde, bu bölüşüm artık staking katılımına göre ayarlanmaz, önceki tasarıma kıyasla ödüllerde basitlik sağlar.

Brüt emisyonu dengeleyen yakımlar: Net arz artışını azaltan iki kaynak vardır: coretime satın alımları (Polkadot 2.0’da) yakılır ve Hazine de yönetişim ile fon yakabilir. Sonuçta, yıllık efektif enflasyon sabit ihraç (~120M DOT) eksi o yıl yakılan miktarlara eşittir.

Önceki modelden farkları: 2024 öncesinde, Polkadot yaklaşık %10 yıllık enflasyonu hedeflemiş ve ödüller “ideal” staking oranı çevresinde ayarlanmıştı, açık ise Hazine’ye (staking verimsizliği) akıyordu. Yeni model, bu ayarlamayı kaldırır ve yukarıda belirtilen sabit %15 Hazine payıyla değiştirir.

Sert üst sınır yok (yönetişime bağlı): DOT, protokolde maksimum arz sınırlaması olmayan bir token’dır. İhraç parametreleri zincir üstü yönetişimle değiştirilebilir; 2024–2025 güncellemeleri bu süreçle uygulanmıştır. Güncel ayarlar ve aktif değişiklik teklifleri için ilgili OpenGov referandumlarına bakınız.

2020 yeniden adlandırma (sadece birim değişikliği): 21 Ağustos 2020’de (“Denomination Day,” blok #1,248,328), DOT 1 eski DOT = 100 yeni DOT olacak şekilde yeniden adlandırıldı. Bu, değer veya sahiplikte değil birimlerde değişiklikti: bakiyeler ve fiyatlar 100× arttı, DOT başına temel birim (Planck) 10¹²’den 10¹⁰ Planck’a geçti. Ağın ekonomisinde başka bir değişiklik olmadı.

Staking (ağın güvenliğinin sağlanması): DOT, Nominated Proof-of-Stake (NPoS) altında ağa teminat olarak kilitlenebilir. Sahipler doğrulayıcı aday gösterebilir veya doğrulayıcı çalıştırabilir; ödüller per era ödenir ve hatalı davranışlar cezalandırılabilir (slashing). Polkadot’un doğrulayıcı seti Phragmén tabanlı algoritmalarla seçilir ve kullanıcılar, daha basit ve düşük miktarlı bir yol tercih ediyorlarsa aday havuzlarına da katılabilirler. Unbonding süreleri, slashing koşulları ve seçim detayları NPoS ve Slashing bölümlerinde ele alınmıştır.

Ücretler (işlem ödemeleri): Relay Chain’de işlemler, aktarılabilir bakiyeden (kilitli fondan değil) DOT ücretiyle ödenir. Ücretler, temel ücret, uzunluk ücreti ve ağırlık temelli ücret ile isteğe bağlı tip’ten (öncelik artırmak için) oluşur; bir tıkanıklık çarpanı, ücretleri son blok doluluk oranına göre yukarı/aşağı ayarlayabilir. Cüzdanlar genellikle imzalamadan önce tahmini ücreti gösterir.

Zincirler arası işlemlerde, hem kaynak hem hedef zincirde ücret kesilebilir. Örneğin, DOT’u Relay Chain ile Asset Hub arasında taşımak hedef zincirde de ücret doğurur ve “keep-alive” koruması uygulanmaz, bu nedenle bakiyenin hedef minimumun üstünde kalması gerekir.

Yönetişim (OpenGov): DOT, OpenGov’da referandum önermek ve oy vermek için kullanılır. Teklifler için karar teminatı gerekir; oylar ise conviction-weighted (zaman kilitli çarpanlı) bakiyelerle kullanılır. Kullanıcılar oy yetkisi devrederek (delegasyon) farklı track’lere temsilci atayabilirler. Pratik nasıl yapılır detayları, OpenGov bölümlerinde ele alınır.

Teminat ve minimum bakiyeler: Polkadot, bir hesabın aktif kalması için minimum serbest bakiye (existential deposit – ED) uygular. Serbest bakiye ED’nin altına düşerse, hesap silinir ve kalan toz yakılır. Güncel rehberde Relay Chain’de 1 DOT, Polkadot Asset Hub’da 0.01 DOT ED olarak belirtilir (değerler zincire göre değişebilir). Keep-alive kontrolleri, normal transferde istemeden reaping’i önler; teleports için bu koruma geçerli değildir.

Bazı özellikler, etkin kaldığı süre boyunca tutulup genellikle kaldırıldığında iade edilen ayrılmış teminatlar (bonds) gerektirir. Örnek: Artık People parachain’de yönetilen zincir üstü kimlik için iade edilebilir teminat ve bir kayıt ücreti gerekir; kimliği temizlemek teminatın kilidinin kaldırılmasını sağlar (fonlar People’da kalır, ardından geri taşınabilir). Yönetişimle ilgili teminatlar (ör: karar teminatı) Yönetişim başlığı altında ele alınmıştır.

Relay Chain, Polkadot’un merkezi zinciridir. Ağın paylaşılan güvenliğini ve küresel fikir birliğini sağlar; uygulama mantığı açısından bilinçli bir şekilde minimaldir: Birçok paralel zinciri barındırmak ve koordine etmek amacıyla vardır, kendi başına son kullanıcı özellikleri çalıştırmaz. Polkadot tasarımında Relay Chain, bağlı shard’lar (“parachain”) arasında tutarlı bir küresel durum sağlar.

Parachain’ler paralel çalışan ve Relay Chain’e bağlanan uygulamaya özgü zincirlerdir. Kendi durumları ve mantıkları vardır, ancak güvenliği Relay Chain doğrulayıcı setinden devralır. Collator olarak adlandırılan parachain düğümleri işlemleri toplar ve delille birlikte aday blokları üretir; ardından Relay Chain doğrulayıcıları, bu parachain durum geçişleri paylaşılan duruma kabul edilmeden önce erişilebilirlik ve geçerliliği kontrol eder. Bu ayrım, parachain’lerin uzmanlaşmasını sağlarken, Relay Chain fikir birliği, kesinlik ve koordinasyonu üstlenir.

Parachain’ler, Polkadot’un zincirler arası fikir birliği mesajlaşması (XCM) kullanarak birbirleriyle iletişim kurabilir; Relay Chain, yönlendirme/doğrulama katmanını koordine ederek zincirlerin veri ve varlıkları güvenle takas etmesini sağlar. XCM’nin derin mekanikleri XCM bölümünde ele alınır.

Polkadot’ta ayrıca çekirdek protokol işlevleri için sistem parachain’ler (sistem zincirleri) bulunur—ör: Asset Hub, fungible ve non-fungible varlıklar için—bu işlevleri Relay Chain dışına alır ve yine de paylaşılan güvenlikten yararlanır. Bu sistem zincirleri zincir üstü yönetişimle tahsis edilir.

Polkadot 2.0 ile projeler, Relay Chain işlemcisini çekirdekler (“coretime”) aracılığıyla elde eder. Sistem zincirlerine çekirdekler yönetişimle verilirken, diğer zincirler açık piyasada coretime satın alır; temelde ilişki değişmez: parachain’ler kendi mantıklarını çalıştırır, Relay Chain ise durum geçişlerini doğrular ve kesinleştirir.

XCM (Cross-Consensus Messaging), Polkadot’un fikir birliği sistemleri arasında (Relay Chain, parachain’ler ve köprüler üzerinden diğer ağlar) niyet bazlı mesajlar göndermek için dili ve standarttır. Ne olması gerektiğini tanımlar, belirli bir çalışma zamanı paletinden bağımsızdır. XCMP (Cross-Chain Message Passing), parachain↔parachain mesajlarının iletim protokolüdür; relay↔parachain trafiğinde UMP (yukarı) ve DMP (aşağı) kullanılır. Mesajlar asenkroniktir.

Transferler: iki yerel XCM kalıbı

• Teleport: varlık doğrudan güvendiğiniz iki lokasyon arasında, rezerv tutucu olmadan taşınır. Tipik kullanım: DOT’un Relay Chain ile Polkadot Asset Hub arasında taşınması. Teleport’lar iki zincirde karşılıklı güven ayarı gerektirir.
• Rezerv tabanlı transfer: Varlığın rezerv zinciri toplam arzı takip eder; kaynak temsilini kilitler/yakar, rezerv bakiyeyi ayarlar, hedef zincir temsili üretir/kredilendirir. Rezervi olmayan parachain’lere varlık taşırken tipik kalıptır.

Pratikte, birçok ekip güvenlik ve muhasebe netliği için rezerv transferi tercih eder; teleport’lar genellikle sadece sıkı şekilde güvenilen yollar için (DOT: Relay Chain ↔ Asset Hub) etkinleştirilir.

Kanallar ve yönlendirme: Parachain↔parachain mesajları kanallar üzerinden gider. Bugün çoğu ağ HRMP (Horizontal Relay-routed Message Passing) kullanır; bu, XCMP ile aynı arayüzü sunar ancak mesajları Relay Chain’de saklar; XCMP daha verimli nihai hedeftir. HRMP kanalları tek yönlüdür; tam iki yönlü bağlantı, her yön için bir kanal gerektirir ve iki zincirin de açıp kabul etmesi gerekir.

Ücretler, ağırlık ve yürütme: Bir XCM’in hedef zincirde “yürütme satın alması” gerekir (ağırlık, yani işlemci süresi için ödeme). Hangi varlıkların ücret olarak kabul edildiği ve ne kadar ağırlık gerektiği hedef zincirin politikasıdır. Standart extrinsic’ler arasında teleport_assets ve reserve_transfer_assets bulunur; hedefi, yararlananı, varlıkları ve ücret kalemini belirtir.

Kullanıcı düzeyinde davranış ve korumalar:

• Existential deposit & keep-alive: teleport’lar “keep-alive” korumasını uygulamaz. Hedef bakiyenizin ücret sonrası, ED’nin üstünde olduğuna emin olun yoksa hesap silinebilir. Teleport’lar ayrıca hedef zincirde de ücret içerir.
• Asenkroni & sıralama: teslimat anlık değildir; sıralama yalnızca kanal içinde garanti edilir.

Köprüler ve sarılmış DOT için, ilerleyen birlikte çalışabilirlik bölümüne bakınız.

Asset Hub, Polkadot’un sistem parachain’idir (daha önce “Statemint”) ve varlık oluşturma, tutma ve transfer işlevi (fungible token ve NFT’ler dahil) sunar. Düşük ücretleri ve Relay Chain’e göre daha düşük existential deposit’iyle genel fayda zinciridir ve ücretler ile teminatlar için yerel token olarak DOT kullanır. Asset Hub’da existential deposit 0.01 DOT’tur (Relay Chain’den 10 kat daha küçük) ve varlıklar, yeterli (tutmak için DOT gerekmez) veya yetersiz (DOT ED karşılanmalı) olarak işaretlenebilir.

Kullanım açısından Asset Hub, kullanıcı ve ekiplerin varlık oluşturabileceği, metadata yönetebileceği ve transfer gerçekleştirebileceği yerdir; resmi rehber, özellikle native olmayan token ve NFT işlemleri için kolaylık sunar. (Kusama Asset Hub’da akıllı kontrat çalıştırmak mümkündür; Polkadot’ta native EVM/PVM kontratları, Asset Hub yerine Polkadot Hub sistem zincirinde planlanmaktadır.)

DOT’u teleport etmek ne zaman mantıklıdır?

Teleport etmek, DOT için Relay Chain ↔ Asset Hub arasında yapılandırılmış güvenli XCM yoludur. DOT’a özellikle Asset Hub’da ihtiyacınız olduğunda faydalıdır, örneğin:

• Daha düşük ücret ödemek veya Asset Hub’daki yetersiz varlıkları tutmak için gereken 0.01 DOT existential deposit’i karşılamak için,
• Asset Hub üzerinde çalışan özellik ve uygulamaları kullanmak için.

Teleport öncesi bilinmesi gereken önemli davranışlar:

• Hedef zincirde bir ücret teleported miktardan düşülür; kalan miktar yine de ≥ hedef zincirin existential deposit’i olmalıdır, yoksa fonlar kaybolur.
• Teleport işlemleri “keep-alive” zorunluluğunu uygulamaz; iki tarafta da hesapları aktif tutmak istiyorsanız, kalan bakiyelerinizin her iki tarafta ED’nin üstünde kalmasını sağlamalısınız.
• Bir borsa (exchange) yatırma adresine direkt teleport yapmayınız (çoğu borsa teleport’ları tespit edemez).

Teleport ile rezerv tabanlı transferlerin mekanikleri ve genel çapraz zincir yönlendirme için, XCM/XCMP bölümüne bakınız. Planlı Asset Hub göçü veya bakım işlemleri sırasında teleport ve XCM transferleri geçici olarak kapatılabilir; güncel Destek bildirimlerinden durumu kontrol edin.

Amaç ve rol: Polkadot ve Kusama, ayrı token’lara sahip (DOT, KSM) bağımsız ağlardır, benzer kod tabanına inşa edilmiştir. Kusama “kanarya ağı”dır: yeni özelliklerin önce indiği ve daha hızlı ilerlediği canlı, ekonomik olarak gerçek bir ortamdır; Polkadot ise üretimde stabilite ve güvenilirliğe öncelik verir.

Yönetişim temposu: Her ikisi de OpenGov çalıştırır ancak Kusama genellikle karar–onay/uygulama arasında daha kısa zaman dilimleri (track bazında) kullanır, böylece yükseltmeler daha hızlıdır; Polkadot’ta süreler daha konservatifdir. Parametreler track bazlıdır ve yönetişimle değiştirilebilir.

Staking zamanlaması: Unbonding süresi Polkadot’ta ~28, Kusama’da ~7 gündür. Eralar—doğrulayıcı ödemesi yapılan dönemler—Polkadot’ta ~24 saat, Kusama’da ~6 saattir. Bu farklar ödül akışını ve unbonding sonrası fonların kilitli kalma süresini etkiler.

Minimum hesap bakiyesi (existential deposit): Hesabı aktif tutmak için, Polkadot 1 DOT, Kusama 0.000333333 KSM gerektirir (değerler yönetişimle değişebilir). Asset Hub parachain’lerinde ED daha da düşüktür.

Yükseltme yolu: Büyük protokol değişiklikleri ve yeni özellikler önce Kusama’da gerçek koşullarda test edilir; kanıtlandığında Polkadot’a taşınır. Bu yaklaşım, Kusama’da esneklik sağlarken Polkadot’u uzun vadede konservatif ve istikrarlı tutar.

Her iki ağ da aynı mimari modeli (Relay Chain + parachain) ve OpenGov araçlarını paylaşır; yukarıdaki farklar hedeflerden (hız vs stabilite) ve operasyonel parametrelerden (zamanlar, minimumlar) kaynaklanır, temel tasarımdan değil.

NPoS, Polkadot’un staking modelidir ve ağın güvenliğini iki rol sağlar: doğrulayıcılar blok üretip doğrular; adaylar seçtikleri doğrulayıcılara DOT desteği sağlar. Her ikisi de ödülleri ve, destekledikleri doğrulayıcı kural ihlal ederse ceza riskini paylaşır. Seçimler, aktif doğrulayıcı setini ve ona atanacak aday payını her era’da belirler.

Seçim döngüsü ve zamanlama: Polkadot’ta bir era ~24 saattir. Sonraki era’nın aktif doğrulayıcı seti, mevcut era’nın sonunda hesaplanır ve era değişiminde uygulanır; ödüller her era için hesaplanır.

Adaylar nasıl katılır: Aday bir kişi en fazla 16 doğrulayıcıyı destekleyebilir. Seçim algoritması adayı sadece seçtiği doğrulayıcıların bir alt kümesine atayabilir, amaç dengeli ve yeterli destekli bir set oluşturmak olduğundan; adayın seçtiği her doğrulayıcı nihai çözümde destek almayabilir.

Doğrulayıcılar nasıl seçilir (amaç ve algoritma): Doğrulayıcı seçimleri üç hedefi optimize eder: (1) seti güvenceye alan toplam hisseyi maksimize etmek, (2) seçilen herhangi bir doğrulayıcıya arka çıkan minimum hisseyi maksimize etmek ve (3) set genelinde hisse varyansını minimize etmek. Polkadot çözümleri off-chain olarak hesaplar ve bunları Election Provider vasıtasıyla zincire sunar; imzalı ve imzasız fazlar ile gerekirse zincir üstü yedek uygulanır. Ağ, Phragmén araştırmasına dayalı orantılı komite seçim kuralları kullanır ve eski sequential-Phragmén yerine çok aşamalı Election Provider mantığına geçmiştir.

Pay atama ve ödeme (kısa bakış): Kazananlar seçildiğinde, seçim çözümü aday payını seçilen doğrulayıcılara nasıl dağıtacağını belirler. Doğrulayıcılar her era’da etkinliğine göre, adaylar ise destek verdikleri doğrulayıcı(lar) üzerinden ödüller alır. Ödül yapısının operasyonel detayları staking başlıklarında ele alınır.

Hesap verebilirlik: Adaylar aktif olarak doğrulayıcıları desteklediği için, adaylar destekledikleri doğrulayıcı aktif setteyken belirli hatalarda slashing cezası alabilir. Koşullar ve oranlar için ilgili Slashing bölümüne bakınız.

Unbonding süreleri, havuzlar ve ödül mekanikleri için staking başlıklarına devam edin; bu giriş yalnızca seçim modeli ve validator seçimine odaklanır.

Slashing, bir doğrulayıcı fikir birliği kurallarını ihlal ettiğinde uygulanan zincir üstü cezadır. Ceza, doğrulayıcı slotuna atanmış hissenin belirli bir yüzdesinin yakılmasıdır (doğrulayıcının kendi katkısı + atanmış aday payı dahil). Ceza miktarı suça göre değişir; yakılan fonlar Polkadot Hazinesi’ne gider. Adaylar yalnızca destekledikleri doğrulayıcı söz konusu slotta seçildiğinde cezalandırılır.

Slashing’i tetikleyebilecek suçlar (örnekler): Polkadot, doğrulayıcı suçlarını sıralar ve her birine tipik bir karşılık ilişkilendirir. Temsili örnekler:

• Çifte imzalama (BABE/GRANDPA/BEEFY): Blok/vote’ların iki kez imzalanması. Ceza oranı %0.01–%100 arası, ciddiyete ve olayın kaç doğrulayıcıyı kapsadığına göre; doğrulayıcı devre dışı bırakılır.
• Geçersiz parachain blok desteği: Para-doğrulayıcı geçersiz bir bloğu destekledi. %100 slashing; zincir üstü engelleme.
• Geçersiz oya destek: İkincil doğrulayıcı geçersiz blok için oy kullandı. %2 slashing; engelleme.
• Geçerli bloğa karşı oy: Geçerli bloğa karşı oy kullanıldı. %0 slashing (hisse kaybı yok) ancak engelleme uygulanır.

Ulaşılamama vs slashing: Rutin kesintiler genellikle (doğrulayıcı durdurularak) forced chilling ile sonuçlanır, slashing olmaz. Polkadot’ta “offline” için slashing ancak ağ seviyesinde bir olayda—ör: aktif doğrulayıcı setinin ≥%10’u aynı anda çevrimdışına kaldığında düşünülür. Destek dökümanları, “uzun süreli” offline (yaklaşık 4 saat) tipik olarak chilling ile, slashing’siz sonuçlandığını bildirir.

Kim, ne kadar öder: Slashing, doğrulayıcı slotunun görünür stake’inin yüzdesi olarak uygulanır (öz fon + atanmış aday payları dahil). Adayların kaybı, suçlu doğrulayıcıya destek oranına göre orantılıdır; diğer doğrulayıcıya destek veren stake etkilenmez. Yüzde modeli, ölçeklendirilebilir kayıpları ve çeşitlendirilmiş desteklemeyi teşvik eder.

Uygulama, gecikme, geri alma: Polkadot, birçok slashi ~28 gün (bir unbonding süresi) erteler. Bu süre zarfında, yönetişim slashi iptal edebilir (örneğin bir protokol hatasından ötürüyse); aksi halinde ceza, unbonding sonrası fonlar çekilmeden önce uygulanır.

Yakılan fonlar nereye gider: Yakılan DOT’ların tamamı, OpenGov yönetiminde ağ inisiyatiflerini finanse eden zincir üstü Hazine’ye eklenir.

Doğrulayıcı seçimi ve stake atama için NPoS, unbonding ve havuzlar için staking başlıklarına bakınız.

Staking’i bıraktığınızda, kilitli DOT “unlocking” (kilit çözülüyor) olarak işaretlenir ve yalnızca 28 günlük unbonding süresi sonunda çekilebilir. Ardından Withdraw Unbonded işlemiyle fonlarınızı aktarılabilir hale getirmelisiniz. (Kusama’da bu süre 7 gündür.)

İstisna: Fast Unstake. Hesabınız son 28 era boyunca hiç aktif doğrulayıcıya maruz kalmadıysa, Fast Unstake ile 28 günlük bekleme süresinden muaf olabilirsiniz. Maruz kaldıysanız, normal süreyi beklemeniz gerekir.

Staking havuzları ile direkt adaylık

Giriş gereksinimi & ödül uygunluğu:

• Doğrudan adaylık (solo): Ödül almak için kilitlediğiniz miktarın, dinamik minimum aktif adaylık eşiğini aşması gerekir; bu eşik zamanla değişir.
• Aday havuzları: Küçük sahiplerin katılımını kolaylaştırmak için tasarlanmıştır; resmi dökümanlar, 1 DOT ile bile havuzda ödül kazanılabileceğini belirtiyor (havuzun büyüklüğü ve etkinliğine bağlı olarak).

Kontrol & custody:

• Doğrudan: Doğrulayıcıları kendiniz seçersiniz.
• Havuz: DOT’lar hesabınızda kalır (kilitli), ancak havuzun adaylayanı doğrulayıcıları seçer; yanlış seçim ödüllerinizi etkileyebilir ve yine slashing riskini paylaşırsınız.

İşleyiş (katılma, geçiş, çıkış):

• Unbonding süresi: Her iki yöntem de Polkadot’ta aynı 28 günlük sürede unbonding’i gerçekleştirir. Havuzda çıkış da 28 gün bekleme gerektirir.
• Havuz değişimi: Önce unbonding gerekir (Polkadot’ta 28 gün; bu sürede ödül yok).
• Unbonding süresinde yeniden kilitleme: Direkt adaylar, 28 gün bitmeden istedikleri anda yeniden kilitleme yapabilir; havuz üyeleri unbonding süresinde re-bond yapamaz.
• Ödül yönetimi: Havuz üyesi unbond yaptığında, bekleyen ödüller çıkış sırasında otomatik olarak aktarılabilir bakiyeye yansır. Bazı havuzlar otomatik birikimli ödül (auto-compound) sunar; isteğe bağlıdır.

Güncel rehberde, havuzda stake ederken OpenGov’da oy kullanılabilir ve yönetişim için kilitli token’larla havuza katılım mümkün olduğu belirtilir. (Bu, eski kısıtlamalardan farklıdır.)

Doğrulayıcı davranışına bağlı ceza uygulamaları için Slashing’e bakınız.

Existential deposit (ED) ve hesap minimumları:

• Relay Chain ED: Bir Polkadot hesabını aktif tutmak için 1 DOT gerekir. Serbest bakiye 1 DOT altına inerse, hesap silinir (reaping) ve kalan toz yanar.
• Asset Hub ED: Polkadot Asset Hub’da 0.01 DOT (zincir bazında ve yönetişimle ayarlanır). Oradaki varlıklar yeterli (tutmak için DOT gerekmez) veya yetersiz (DOT ED karşılanmalı) olabilir.

Keep-alive koruması: Polkadot-JS gibi cüzdanlarda varsayılan olarak “keep alive” aktiftir: Hesabınızı ED altına düşürecek transfer engellenir. İsterseniz kapatıp tüm bakiyeyi gönderebilir ve gönderici hesabı sildirebilirsiniz.

Relay Chain’de ücret modeli:

Polkadot ağırlık bazlı ücret sistemi kullanır. Bir işlemin ücreti:

• Temel bileşen (her extrinsic için genel masraf)
• Uzunluk ücreti (byte uzunluğuna göre artar)
• Ağırlık ücreti (çağrının işlem yüküne göre artar)
• İsteğe bağlı tip (kullanıcıya ait, öncelik için)
• Dinamik ücret çarpanı son blok yoğunluğuna göre ücreti hafifçe yukarı/aşağı ayarlar.

Ücret nasıl görülür/hesaplanır: Cüzdanlar ve SDK’lar imzalamadan önce tahmini tutarı gösterir (ör: polkadot.js’de paymentInfo). Ücret, aktarılabilir bakiyeden kesilir (bonded fondan değil).

Pratik notlar:

• Reaping edilen hesabı tekrar aktive etmek: Zincirin ED’si kadar (ör: Relay Chain’de 1 DOT) aktarım yapmak yeterlidir.
• Zincire özel ED: ED zincire göre değişir; Asset Hub’daki ED, Relay Chain’den daha düşüktür. Güncel değerleri resmi destek dökümanlarından kontrol edin.
• Çapraz zincir hareketler: XCM operasyonlarında (ör: teleport) hedef zincirde de ücret alınır ve keep-alive uygulanmaz; hedefte ücret sonrası bakiye ED’yi karşılamalıdır. Mekanik için XCM bölümüne bakınız.

Staking ile bağlantılı minimumlar ve unbonding süreleri için staking bölümlerine bkz.; burası hesap düzeyinde ücretler ve minimumlara odaklanır.

OpenGov, Polkadot’un zincir üstü yönetim sistemidir. Teklifler (“referandumlar”) bağlayıcıdır: Bir referandum geçtiğinde, uygulama süresi sonunda otomatik olarak zincirde hayata geçer. Birden çok referandum paralel olarak yürütülebilir.

Track’ler ve origin’ler: Her referandum, bir origin’e (işlem için gerekli ayrıcalık seviyesi) karşılık gelen bir track üzerinde sunulur. Her track şu kriterlere sahiptir: gerek duyulan karar teminatı, zaman aralıkları (hazırlık/karar/onay/uygulama), onay/destek eğrileri (karşılanması gereken eşikler) ve genellikle belirli anda karar aşamasında olabilecek madde kapasitesi. Yüksek ayrıcalıklı track’ler (ör: Root) daha yüksek eşikler ve daha uzun sürelerle çalışır; düşük etkili track’ler (ör: Small Tipper) daha hafiftir.

Bazı çağrılar, Polkadot Fellowship tarafından beyaz listeye alınabilir ve Whitelisted Caller track’i üzerinden, referandum geçtikten sonra daha hızlı parametrelerle yürütülebilir. Track davranışları ve örnekler OpenGov “origins” rehberinde dokümante edilmiştir.

Oylama ve conviction: Token sahipleri, DOT ile Evet/Hayır/Çekimser oy kullanır. Seçimlik olarak conviction voting (zaman kilidi çarpanı) uygulanabilir; daha uzun süre kilitlenen token daha yüksek oy gücü sağlar; kilitler referandum bitince başlar, seçilen conviction periyodu sonunda açılır. OpenGov, farklı referandumlarda farklı conviction seviyeleriyle oy kullanılmasına imkân tanır.

Delegasyon ve çoklu delegasyon: Doğrudan oy vermek yerine sahipler, oy yetkisi devredebilir. OpenGov, track bazında (çoklu-)delegasyonu destekler: farklı track’ler için farklı temsilcilere farklı miktar ve conviction ile yetki verebilirsiniz. Oy veya mevcut delegasyon varsa, track’te yeni delegasyon yapılmadan önce bunlar temizlenmelidir. Resmi arayüzler, delegasyon ayarlarken track seçiciler ve conviction ayarı sunar.

Referandum yaşam döngüsü (özetle):

• Sunum & hazırlık süresi – Bir referandum track’e iletilir; oylama açılır, ancak oylar outcome’a hazırlık süresi sonrası dahil edilir. Karar teminatı maddeyi karar aşamasına yükseltmek için gereklidir.
• Karar süresi – Madde aktif olarak değerlendirilir. Kabul için track’in onay ve destek eğrilerinin karşılanması gerekir.
• Onay süresi – Eşikler belirli minimum süre boyunca karşılanmaya devam etmelidir.
• Yürütme süresi – Onay sonrası, çağrı kuyruğa alınır ve track’in yürütme gecikmesinden sonra zincir üstü otomatik olarak yürütülür.

Her DOT sahibi OpenGov’da katılabilir: Teklif (referandum) sunabilir, doğrudan oy verebilir veya oy gücünü devredebilir. Etkinlik, origin’i (ayrıcalık seviyesi), gereken karar teminatı, eşikler ve zaman pencerelerini tanımlayan track’lerde gerçekleşir. Track parametreleri yönetişimle belirlenir ve değiştirilebilir.

Teklif (referandum oluşturma):

1. Uygun track’i seçin – yapmak istediğiniz eylemin yetkisine uygun (ör: yüksek etki için Root, Hazine için Tipper/Spender track’leri).
2. Referandumu gönderin ve karar teminatının yatırıldığından emin olun; bu teminat zincirde izlenir ve hazırlık süresinden sonra maddeyi karar aşamasına taşımak için gerekir. Teminatlar UI’da referandum başına görünür ve kurallara tabi olarak iade edilir.

Gereksinimler: İşlem ve track’in karar teminatı için yeterli DOT bulunan bir Polkadot hesabı. Zincir üstü kimlik opsiyoneldir, ancak güvenilirlik için genellikle tercih edilir; kimlik için People parachain’de iade edilebilir teminat ve kayıt ücreti gerekir.

Oy verme (doğrudan katılım):

• Seçenekler: Evet, Hayır, Çekimser, Bölünmüş (Evet/Hayır’a böl), Bölünmüş-Çekimser (Evet/Hayır/Çekimser böl).
• Conviction voting: Oy gücünü katlamak için DOT’u daha uzun kilitleyebilirsiniz; kilitler referandum bitince başlar ve seçilen conviction sonunda açılır. Kilitler üst üste gelir, böylece aynı bakiye birden çok oyu veya stake’i destekleyebilir. Referandum sürerken oyunuzu çekebilir ve anında kilidi açabilirsiniz; aksi halde, süre dolduktan sonra kilitleri temizleyin.

Stake veya havuzda olan DOT ile oy kullanılabilir: OpenGov, solo staking veya havuz aracılığıyla stake edilmiş DOT ile oy vermeyi destekler; havuzlu hesapların da katılımı mümkündür.

Delegasyon (track bazında, çoklu delegasyon): Her madde için oy vermek istemiyorsanız, oy gücünü devredebilirsiniz. OpenGov, track bazında çoklu delegasyona imkân verir: Her track için farklı temsilci, miktar ve conviction ayarlanabilir. Track’te süresi bitmemiş oy veya mevcut delegasyon varsa, öncelikle bunları temizlemelisiniz. Delegasyon resmi arayüzlerden (Polkadot-JS, Polkassembly, Nova, PolkaGate) yönetilebilir.

Pratik araçlar:

• Polkadot-JS UI: Teklif sunma, oy verme, delegasyon ve süresi biten referandum kilitlerini temizleme.
• Polkassembly/Subsquare/Nova/PolkaGate: Referandum keşfi, oy kullanma (Bölünmüş/Çekimser dahil), track bazında delegasyon yapılandırma.

Eşikler, zaman pencereleri ve teminat miktarları için bir teklif verirken veya delegasyon yaparken ilgili track’e bakın; bu parametreler track’e göre farklıdır ve yönetişimle değiştirilebilir.

Hazine, OpenGov kontrolünde zincir üstü bir fon havuzudur. Gelirler otomatik olarak gelir ve sadece yönetişimin onayladığı eylemlerle harcanabilir; varlıklar sistem hesabında tutulur, herhangi bir dış hesap tarafından doğrudan taşınamaz.

Hazine nasıl fonlanır (gelirler):

• İşlem ücretleri: Her extrinsic’in %80’i Hazine’ye, %20’si blok üreticilere gider.
• DOT ihracı: Yıllık enflasyonun %15’i Hazine’ye aktarılır.
• Slashing’ler: Doğrulayıcı hatalarından kesilen pay Hazinede birikir.
• Doğrudan transferler: Kullanıcılar Hazine hesabına varlık gönderebilirler (nadir, ör: geri ödeme).

Harcamalar nasıl çalışır (giderler):

• Hazine teklifleri (spend): Yönetişim, belirli bir yararlanıcıya fon aktaracak referandumları onaylar. Ödemeler spend döneminde gerçekleşir; her spend dönemi sonunda harcanmayan fonların bir kısmı yakılır.
• Tipler: Small/Big Tipper track’lerinde hızlı, küçük ödemeler.
• Bountie’ler ve alt-bounty’ler: Tek seferlik “ana” bounty fonu ayrılır, küratörler daha sonra alt-bounty’ler ile belirli iş veya etkinliklere ödeme yapar—uzun süreli çoklu ödeme gereken yerler için uygundur. Küratör teminat yatırır, küratör ücreti alabilir ve ödemeleri belirli süre içinde yönetir.

Treasury harcamaları için kullanılan yönetişim track’leri: OpenGov, Hazine ödemelerini kendi origin ve parametrelerine sahip altı track ile yönetir: Treasurer, Big/Medium/Small Spender ve Big/Small Tipper. Daha büyük harcamalar için daha katı track’ler ve daha yüksek eşik/kapasite uygulanır; tipler küçük ödüller içindir.

Çoklu varlık destekli Hazine: Asset Hub’da varlığı eklenen ve ücreti yönetişimce belirlenen diğer varlıklar (ör: USDT/USDC) ile de Hazine fonu tutulup harcanabilir. Onaylı çoklu varlık harcamaları varlık, zincir ve tutarı belirtir; hedef bazlı ödeme ve manuel talep pencereleri desteklenmektedir.

Alt-hazineler (bütçe devri): Yönetişim, ana Hazine’nin bir kısmını ilgili kolektiflere veya sistem zincirlerine bağlı alt-hazinlere ayırabilir. Her alt-hazine, kendi kural setiyle ödeme yapar ve ana track’lerde çok sayıda münferit referandum ihtiyacını azaltır.

Hazine teklifleri oluşturma, oy verme veya delegasyon için OpenGov bölümlerine bakınız.

Polkadot Fellowship, protokolün çalışma zamanı ve teknik standartlarını denetleyen zincir üstü teknik topluluktur. Polkadot’un Collectives sistem zincirinde çalışır ve hem zincirde hem de halka açık repolarda (ör: RFC’ler) çalışmaları koordine eder. Fellowship hem Polkadot hem Kusama runtime’larını yönetirken, protokol değişikliklerine engel değildir—her DOT sahibi OpenGov’da Root track ile çalışma zamanı yükseltmesi önerebilir.

Üyelik ve dereceler: Fellowship üyeleri dereceli üyelik taşır ve topluluk içi oylamada dereceler teknik değerlendirmede sorumluluk ve ağırlık belirtir. Collectives zinciri için açık panolar, üye derecelerini ve Fellowship aktivitelerini gösterir.

Beyaz listeye alma & Whitelisted Caller track’i: Zaman kritik veya düşük riskli, iyi denetlenmiş eylemler için (çoğunlukla runtime sürümleri), Fellowship belirli bir çağrı hash’ini beyaz listeye alabilir. Bu, OpenGov’da Whitelisted Caller track’ini aktifleştirir ve referandum geçtikten sonra o çağrıya Root yetkisiyle yürütme imkânı tanır. Track, Root’a göre daha hızlı zamanlar ve farklı onay/destek eğrileri sunar, böylece kritik maddeler için kontrollü hızlı yol açar.

Yükseltmeler nasıl yürütülür: Polkadot’ta runtime yükseltmeleri yalnızca Root veya Whitelisted Caller referandumlarıyla yürütülür. Fellowship’in rolü, yükseltmeleri gözden geçirmek ve uygun bulursa hızlı track’ten geçmeleri için beyaz listelemektir; aksi halde yükseltmeler klasik Root sürecinden ilerler.

Açık geliştirme: Teknik teklif ve tasarım çalışmaları Fellowship’in açık RFC deposunda izlenir; Fellowship sinyalleri (onay/red) ve zincir üstü kararlar token sahipleri/oy verenler için görünürdür.

Agile Coretime (blok alanı olarak piyasa)

Polkadot 2.0, uzun vadeli slot kiralama ve crowdloan’ların yerine coretime piyasası getiriyor. Projeler, Relay Chain “core”ları üzerinde iki şekilde işlem süresi satın alınır:

• Toplu Coretime: Her biri yaklaşık 28 günlük (“region”) dönem (5.040 dilim), özel Coretime zincirinde satılır. Sahiplik bir tür non-fungible varlık olarak kaydedilir ve devredilebilir/satılabilir.
• Anlık Coretime: İhtiyaç anında havuzdan kısa süreli kapasite alınabilir (kullandıkça öde).

Her dönem satışları, azalan fiyatlı “lead-in” (Dutch tarzı) ile yapılır; “düzenli fiyat” zamanla yönetişim kurallarıyla talebe ayarlanır. Bölge için ikincil bir piyasa tasarımda yer alır. Coretime gelirleri onaylı Fellowship RFC’siyle yakılır. Net ihraç, brüt ihraçtan yakımı çıkarılmış haliyle olur.

Maliyet etkisi: Ekipler, sadece ihtiyaçları kadar kapasiteyi satın alır, fiyatlama daha öngörülebilir, çok yıllık kilitleme gerekmez. Agile Coretime faaliyete geçtiğinden beri Polkadot’ta açık artırmalar/crowdloan’lar kaldırıldı.

Async Backing (verimlilik ve gecikme iyileştirmeleri)

Asenkron Backing, parachain blok üretimini son Relay Chain bloğundan ayırır; collator’lar çoklu aday blokları sırayla hazırlayıp destek/ekleme işlemlerini üst üste getirebilir. Pratikte:

• parachain’ler her ~6 sn blok üretebilir (önceden 12 sn)
• işlem penceresi (~0.5 sn’den ~2 sn’ye) genişletilir, ~4 kat daha büyük bloklar mümkün olur
• başlı başına ~8 kat, PoV-reclaim ile ~10 kat daha yüksek throughput sağlar (gerçek kanıt boyutları baz alınır)

Bu değişiklikler 2024’te (önce Kusama, sonra Polkadot) yayına alındı.

Performans etkisi: Yüksek ve sürekli TPS, daha hızlı dahil edilme; ekstra kapasiteye ihtiyaç duymayan zincirler istediği zaman geçiş yapabilir.

Elastic Scaling (bir zincirde birden çok core kullanımı)

Elastic Scaling, tek bir zincirin birden çok core’u paralel kullanmasını (dikey ölçekleme) sağlar; önceden her parachain tek core kullanırdı. Bu, async backing ve yeni collator/doğrulayıcı parametreleriyle birleşerek throughput’u daha da artırır ve gecikmeyi azaltır. Ağustos 2025 itibarıyla Elastic Scaling’in ana ağa uygulanmak üzere OpenGov ile tamamlanması hedeflenmektedir (önce Kusama, sonra Polkadot).

Performans etkisi: Ağır yük altındaki rollup/parachain’ler iş yükünü birden çok core’a böler, çoklu zincire bölünmeden kapasiteyi artırır.

Etkilerin özeti:

• Maliyet ve planlama: Tahmini, piyasa tabanlı coretime, uzun vadeli kiralamanın yerini alır; ekipler aylık bölge veya anlık dilim satın alır; coretime gelirlerinden elde edilen yakımlar ihraç dengesini sağlar.
• Verim ve gecikme: Async backing blok sıklığını ve kapasitesini artırır; elastic scaling çoklu çekirdekli işleme ile ek kazanç sağlar. Birlikte, Polkadot’un paylaşılan güvenlik modelini değiştirmeksizin sürekli throughput’u artırır.

1. Zincirinizi inşa edin:

   • Polkadot SDK (Substrate + Cumulus) kullanın ve parachain template’inden başlayın. Bu, size FRAME tabanlı runtime, collator node ve hazır XCM kancaları sunar.
   • Blok üretimini ve temel XCM’i doğrulamak için yerel bir Relay Chain’e bağlanın; yerel parachain bağlama için resmi tutorial mevcuttur.

2. Testnet’te ispat & ParaID alın:

   • Paseo’da (coretime özellikli topluluk testnet’i) güncellemeleri ve XCM’i test edin.
   • Hedef relay chain’de registrar’dan ParaID’i rezerve edin: önce reserve çağrısı (zincire özel teminat öder), ardından register ile doğrulama kodu (WASM) ve genesis head sağlanır. Teminatlar registrar paletinde zincire göre ayarlanır. (Testnet’te tam sabitler dökümanda; mainnet’te değerler yönetişimle belirlenir.)

3. Coretime alın (Polkadot 2.0):

   • Toplu Coretime (bir “Bölge”): Belirli bir core üzerinde 5.040 dilimlik ~28 günlük bölgeyi, Coretime zincirinde satın alın. Sahiplik zincir üstü izlenir ve devredilip satılabilir; satışlar azalan fiyat yaklaşımıyla yapılır.
   • Anlık Coretime: İhtiyaç anında havuzdan alınan kısa, talebe dayalı kapasite.
   • Muhasebe: Coretime satış geliri Fellowship RFC-0010’a göre yakılır, ekipler satın alma için DOT bütçeler; kilitleme/crowdloan yoktur.

4. Relay Chain’de kaydedin & etkinleştirin:

   • ParaID, runtime WASM ve genesis head hazırsa, kayıt işlemini yapın ve zincirinizi etkinleştirin. Polkadot’ta, tipik proje kaydı registrar ile yapılır; sistem zincirler (örn. Coretime, Asset Hub) genellikle OpenGov ile (çoğunlukla Whitelisted Caller track’i) kaydedilir; örnek: Coretime chain registration referandumu.

5. Ağınızı işletin:

   • Collator’lar: En az iki güvenilir collator çalıştırın; yük arttıkça sayıyı ve coğrafi dağılımı artırın. (Doğrulayıcılar Relay Chain’dedir; parachain’ler collator sağlar.)
   • XCM & HRMP: Diğer zincirlerle (ör: Asset Hub) HRMP kanalı açın ve XCM’i yapılandırın (kabul edilen ücret varlıkları, rezerv konumları). DOT yönlendirmelerinde, Asset Hub’ın DOT rezervi olarak kullanılmasına yönelik güncel rehbere dikkat edin.
   • Güncellemeler: Runtime güncellemelerini kendi zincirinizin yönetişimiyle yürütün; Relay Chain dahil etme sırasında doğrular. (Relay-level parametreler ve OpenGov mekanikleri için yönetişim bölümlerine bakınız.)

6. Rollup’lar vs parachain’ler (“rollup” buraya nasıl oturur):

   • Ekipler genellikle “rollup”ları SDK ile parachain olarak uygular (Relay Chain üzerinde çözülüp doğrulanır), böylece erişilebilirlik/geçerlilik ve XCM’den yararlanır. Eğer rollup-as-a-service mevcut bir parachain üzerinde yapılacaksa, coretime’ı siz almaz, host ile koordinasyon yaparsınız; Relay bağlantılı yol yine yukarıdaki adımları takip eder. (Mimari seçim proje bazlıdır.)

Minimum gereksinimler (kontrol listesi)

Teknik:

• Polkadot SDK runtime (WASM) + chain spec, genesis head ve ParaID.
• Collator düğümleri, RPC uç noktaları, izleme/telemetri.
• XCM yapılandırması ve en az bir HRMP entegrasyon kanalı.

Ekonomik:

• Coretime (Toplu veya Anlık) ve işlem ücretleri için DOT bütçesi; coretime harcamasının yakıldığını bilin.
• ParaID rezerv/kayıt teminatı (zincire göre değişir).

Yönetişim temas noktaları:

• Sıradan registrar bazlı kayıt işlemlerinde kendi zinciriniz dışında ek bir yönetişim gerektirmez; sistem zincirler OpenGov ile dahil edilir (ör: Coretime chain registration).

Yerel DOT vs sarılmış/türetilmiş DOT:

• Yerel DOT Polkadot’un kendisinde (Relay Chain ve Asset Hub gibi sistem zincirlerde) bezer. Polkadot içinde DOT, XCM ile ya teleport (Relay ↔ Asset Hub arası) ya da rezerv tabanlı transferle diğer parachain’lere taşınır. Yönetişim DOT’un rezerv konumunu XCM konfigürasyonlarında Relay Chain’den Asset Hub’a taşımaktadir; parachain’ler bundan sonra Asset Hub’ı DOT’un rezervi olarak görmelidir.
• Sarılmış/türetilmiş DOT Polkadot dışında (ör: Ethereum’da) veya EVM parachain içinde ERC-20 uyumlu biçimde bulunur. Moonbeam’de DOT, xcDOT ismiyle çıkar; bu bir XC-20’dir: Ana DOT mülkiyeti rezerv zincirde kilitlenir, ERC-20 arayüzü yerelde kullanılır.

Polkadot içi XCM vs harici ağlara köprüler:

• XCM (ekosistem içi): Relay Chain ile parachain’ler arasında varlık transferi için kullanılan mesajlaşma standardıdır. DOT için güvenli yol Relay ↔ Asset Hub’da teleport ile etkindir; diğer parachain’lere transferde genellikle rezerv tabanlı model ile hareket edilir, rezerv zincir toplam arzı izler.
• Köprüler (ekosistem dışı): Ethereum gibi ağlara erişmek için, Polkadot Bridge Hub üzerinde köprüler kullanır. Snowbridge resmi, light-client tabanlı Polkadot↔Ethereum köprüsüdür. Bugün, Asset Hub’ın ForeignAssets paletinde köprülenmiş ERC-20 üretilir, sonra hedef parachain’e XCM rezerv transfer ile gönderilir; böylece XCM ve köprü birlikte çalışır.

Moonbeam ile EVM uyumluluğu (XC-20’ler):

• XC-20 standardı: Moonbeam’de, zincirler arası varlıklar ERC-20 (ve Permit) arayüzü sunan XC-20 olarak yüzeye çıkar. DOT için bu xcDOT’dur. Geliştiriciler, Polkadot rezerv yönetimini arka planda bırakarak standart Ethereum araçlarıyla XC-20’ler ile etkileşir.
• Yerel vs harici XC-20’ler: Rezervi Moonbeam olan token’lar “yerel” XC-20’dir; DOT gibi varlıklar, rezervi (Relay/Asset Hub) dışında tutularak Moonbeam’de harici XC-20 olur ve ERC-20 biçimiyle dolaşır.

Pratik notlar:

• Ne zaman hangisini kullanmalı: DOT’u Asset Hub ile parachain’ler arası taşırken XCM kullanın. Dış ağlara (ör: Ethereum) varlık taşımak için köprü kullanın (ör: Snowbridge); köprülenmiş token’lar, yerel DOT’tan farklı güven/risk yapısına sahiptir.
• Süregelen güncellemeler: DOT’un rezerv lokasyonunun Asset Hub’a taşınması aktif bir değişikliktir; parachain ve uygulamalar, XCM yapılandırmasını güncelleyerek aktarım ve muhasebenin tutarlı kalmasını sağlamalı. Kullanıcı rehberi Polkadot Support ve forumda yayımlanıyor.

Polkadot, İsviçre merkezli kar amacı gütmeyen Web3 Foundation (W3F) tarafından başlatılmıştır; kuruluşun amiral gemisi projesi Polkadot’tur. W3F’nin kurucusu, 2016’da orijinal Polkadot whitepaper’ını yazan Dr Gavin Wood’dur.

Protokol ve runtime’ın geliştirilmesini, Polkadot’u 2020’de ana ağa taşıyan mühendislik ekibi Parity Technologies üstlenmiştir.

Polkadot’un kurucu ekibi genellikle Gavin Wood, Robert Habermeier ve Peter Czaban olarak anılır. W3F’nin lansman duyurusunda Robert Habermeier Polkadot kurucu ortağı ve çekirdek geliştirici, Peter Czaban ise Polkadot ve Web3 Foundation kurucu ortağı olarak gösterilmiştir.

W3F, birkaç yıllık geliştirme sonrası canlı Polkadot ağını 26 Mayıs 2020’de kullanıma açmıştır; sonraki aşamalarla kontrol token sahiplerine devredilmiş ve DOT ihracı zincir üstünde başlatılmıştır. Arz mekanikleri ve redenominasyon önceki bölümlerde ele alınmıştır.