Solidus Yönetişimi

Solidus protokolünün nasıl geliştiği: teklif süreci, oylama mekaniği, hazine yönetimi, komite yapısı ve merkeziyetsizleşme zaman çizelgesi.

Genel Bakış

Solidus yönetişimi aşamalı bir sistemdir. Aşama 1’de, kurucu ekip protokol yükseltmelerini ve hazine tahsisini kontrol eder. Ağ büyüdükçe ve merkeziyetsizleştikçe yönetişim hakları genişler. Tam DAO yönetişimi — hiçbir tek varlığın ayrıcalıklı kontrole sahip olmadığı — bir Aşama 4 hedefidir.

Bu belge, yönetişim sistemini mainnet lansmanında (Aşama 2) var olacağı şekliyle açıklar. Daha önceki aşamalarda daha hafif bir yönetişim vardır; sonraki aşamalar DAO’ya daha fazla yetki devreder.

Solidus İyileştirme Teklifleri (SIP’ler)

Tüm protokol değişiklikleri, parametre güncellemeleri ve hazine tahsisleri, SIP (Solidus Improvement Proposal / Solidus İyileştirme Teklifi) süreci aracılığıyla ilerler.

SIP Türleri

Çekirdek SIP’ler, mainnet lansmanından itibaren 90 günlük protokol istikrar penceresi geçene kadar hiç sunulamaz. İlk 3 ayda çekirdek protokol değişikliği yoktur.

SIP Yaşam Döngüsü

IDEA → DRAFT → REVIEW → DISCUSSION → VOTE → IMPLEMENTATION → ACTIVATION

Tartışma uzatması: Bir SIP, tartışmanın son 7 gününde 50’den fazla yorum alırsa, tüm endişelerin ele alınmasını sağlamak için tartışma dönemi otomatik olarak 14 gün daha uzatılır.

SIP Şablonu

## SIP-XXXX: [Title]
 
**Type:** Core / Standard / Treasury / Informational / Emergency
**Status:** Draft / Review / Discussion / Vote / Approved / Rejected / Implemented
**Proposed by:** [DID or pseudonym]
**Created:** YYYY-MM-DD
**Discussion:** [Link to governance forum thread]
 
### Summary
[One paragraph. What does this change and why?]
 
### Motivation
[Why is this change needed? What problem does it solve?]
 
### Specification
[Precise description of the change. For parameter changes: current value → proposed value.
For protocol changes: before/after pseudocode or protocol comparison.]
 
### Rationale
[Why this approach over alternatives? What alternatives were considered?]
 
### Backwards Compatibility
[Is this a breaking change? What is the migration path?]
 
### Security Considerations
[Does this change the threat model? What new attack vectors does it introduce or close?]
 
### Implementation
[Link to reference implementation, or description of what implementation requires.]
 
### References
[Supporting research, prior art, related SIPs.]

Oylama Mekaniği

Kim Oy Verebilir

Oylama hakları, stake edilen SLDS ile orantılıdır. Oy manipülasyonu için son dakika stake edinimini önlemek için, bir oylama başlamadan en az 7 gün önce SLDS stake etmiş olmanız gerekir.

Oylama ağırlığı formülü:

voting_weight = staked_SOLID × sqrt(days_staked / 30)

Stake edilen günlerin karekökü, uzun vadeli katılımcıları kısa vadeli oy verenlere göre ödüllendirir, ancak onlara sınırsız bir avantaj vermez.

Devretme (Delegation): Token sahipleri oylama ağırlıklarını başka bir adrese devredebilir. Devredilen oylar quorum’a ve 30 günlük kilit gereksinimine sayılır. Devretme, herhangi bir zamanda değiştirilebilir, bir sonraki oylama için geçerli olur.

Quorum

Toplam stake edilen SLDS’nin %30’u (doğrudan veya devretme yoluyla) katılmadıkça bir oylama geçersizdir. Quorum’u karşılamayan bir oylama otomatik olarak 7 gün uzatılır. Quorum hâlâ karşılanmazsa, SIP Tartışma durumuna döner.

Bu quorum gereksinimi, düşük katılımlı yönetişim saldırılarını önler (küçük, motivasyonlu bir grubun, daha geniş topluluğun reddedeceği değişiklikleri geçirmesi).

Onay Eşikleri

Hiçbir tek varlık, toplam oylama ağırlığının %10’undan fazlasını kullanamaz. Tek bir adres (veya bir tanımlanmış denetleyiciden devredilen bir küme) bu eşiği aşarsa, etkin ağırlıkları %10’da sınırlandırılır. Bu yoğunlaşma sınırı, devretme çözüldükten sonra uygulanır.

Oylama Süreci

1. Teklif zincir üzerinde yayınlanır. Tartışma dönemi kesin bir ret olmadan sona erdiğinde, SIP Oylama durumuna geçer ve yönetişim akıllı sözleşmesinde yayınlanır.

2. Anlık görüntü (snapshot) alınır. Oylama başlangıç bloğunda, stake edilen SLDS bakiyelerinin ve devretme atamalarının bir anlık görüntüsü alınır. Stake veya devretmedeki sonraki değişiklikler bu oylamayı etkilemez.

3. Oylama penceresi. Uygun stake edenlerin oy kullanabileceği 14 gün: EVET, HAYIR veya ÇEKİMSER. Çekimser oylar quorum’a sayılır ancak onaya sayılmaz.

4. Sonuç belirleme. Oylama sonunda: quorum karşılandıysa ve onay eşiği karşılandıysa → Onaylandı; quorum karşılandıysa ve eşik karşılanmadıysa → Reddedildi; quorum karşılanmadıysa → Uzatıldı veya Tartışmaya döndürüldü.

5. Veto penceresi. Onaydan sonra, Güvenlik Konseyinin (aşağıya bakın) varoluşsal bir güvenlik riski oluşturması durumunda bir SIP’i veto edebileceği 7 günlük bir veto penceresi vardır. Güvenlik Konseyi, yönle ilgili anlaşmazlığa dayanarak veto veremez — yalnızca açık güvenlik sorunları için.

Hazine

Hazine Fonlarının Kaynakları

Hazine Yönetişimi

Hazine fonları yalnızca onaylanmış bir Hazine SIP’i aracılığıyla harcanabilir. Hazine akıllı sözleşmesi bunu zorunlu kılar: zincir üzerinde onaylanmış bir SIP referansı olmadan hiçbir para çekme işlemi yapılamaz.

Standart bütçe (otomatik, SIP gerekmez):

• Güvenlik Konseyi operasyonları: yılda 50.000 SLDS (donanım, operasyonlar, ödenekleri kapsar)
• Çekirdek geliştirici hibeleri: geliştirici başına yılda 200.000 SLDS’ye kadar (yıllık SIP tarafından belirlenir)
• Hata ödülü havuzu: yılda 100.000 SLDS (otomatik tamamlama)

Takdiri harcama (Hazine SIP’i gerekir):

• Protokol denetimleri
• Araştırma hibeleri
• Ortaklık geliştirme
• Elçi ve hackathon programları
• Yeterince hizmet almayan bölgelerdeki doğrulayıcılar için altyapı hibeleri

Hazine Şeffaflığı

Tüm hazine işlemleri zincir üzerindedir ve Explorer aracılığıyla herkese açık olarak görüntülenebilir (özel bir /treasury görünümü henüz canlı değildir — explorer.solidus.network’ün kendisi bugün canlıdır). Hazine Komitesi tarafından aylık hazine raporları yayınlanır ve şunları gösterir:

• Açılış bakiyesi
• Alınan gelir (kaynağa göre)
• Harcamalar (SIP referansına göre)
• Kapanış bakiyesi
• Ay sonunda SLDS/USD değerlemesi

Yönetişim Komiteleri

Beş daimi komite, resmi SIP oylamaları arasında topluluk etkinliğini koordine eder. Komiteler tavsiye verir, teklif eder ve koordine eder — protokol değişiklikleri üzerinde tek taraflı yetkileri yoktur.

Komite Seçimi: Her 6 ayda bir 2 haftalık bir aday gösterme penceresinde öz-aday gösterme + topluluk oyu. Stake ağırlığına göre en çok oy alanlar mevcut yerleri doldurur. Kurucu ekip üyeleri, Aşama 3’ten sonra komite pozisyonlarında bulunamaz (aşamalı merkeziyetsizleşme).

Komite Yetkisi:

• Komiteler, oylama olmadan Bilgilendirici SIP’ler gönderebilir
• Komiteler Standart SIP’lere sponsor olabilir (14 günlük tartışma uzatması riskini kaldırır)
• Komiteler, onaylanmış bir Hazine SIP’i olmadan hazine fonlarını harcayamaz
• Teknik Komite, Güvenlik Konseyi ile birlikte Acil Durum SIP sürecini başlatabilir

Güvenlik Konseyi

Güvenlik Konseyi, yalnızca acil müdahaleler üzerinde yetkiye sahip 7 üyeli bir multisig’dir. Hazine fonlarını harcayamaz veya protokol parametrelerini değiştiremez — yalnızca Acil Durum SIP sürecini başlatabilir ve 7 günlük oylama sonrası vetoyu kullanabilir.

Bileşim (mainnet lansmanında):

• 3 kurucu ekip üyesi
• 2 dış güvenlik araştırmacısı (topluluk oyuyla seçilir)
• 1 hukuk/uyum temsilcisi
• 1 rotasyonlu topluluk temsilcisi (her 3 ayda bir seçilir)

Multisig gereksinimi: Acil SIP’i başlatmak için 7’de 5, veto için 7’de 4.

Fesih: Güvenlik Konseyi, DAO yönetişim sistemi yeterince olgunlaştığında, Aşama 4’ten sonra topluluk oyuyla feshedilir. Fesihten sonra, acil yamalar %51 Çekirdek Doğrulayıcı onayı gerektirir (aynı 48 saatlik hızlı işlem süreci, ancak merkezi bir multisig olmadan).

Aşamaya Göre Yönetişim

Değişmez Özellikler

Aşağıdaki özellikler genesis’te sabittir ve herhangi bir yönetişim süreci aracılığıyla değiştirilemez. Bunları değiştirmek, olağanüstü bir sosyal konsensüse sahip bir hard fork gerektirir — etkin bir şekilde yeni bir protokol oluşturur.

• Toplam SLDS arzı: 1.000.000.000 (1 milyar). Yeni ihraç mümkün değildir.
• Kriptografik ilkeller: Ed25519, BLAKE3, BBS+ (seçici ifşa, testnet’te canlı, denetim bekliyor). Groth16 ZK-SNARK’lar yol haritasındadır. Gerekirse post-kuantum geçişi bir hard fork’tur, bir SIP değil.
• BFT güvenlik özellikleri: %67 süper çoğunluk kesinliği gereksinimi ve hata toleransı için minimum 3f+1 doğrulayıcı.
• Kimlik bağlama: Doğrulayıcılar doğrulanmış insanlar olmalıdır. Bu gereksinim yönetişim yoluyla kaldırılamaz.
• Yoğunlaşma sınırı: Hiçbir tek varlık oylama ağırlığının %10’undan fazlasını kontrol edemez. Bu sınır ekonomiye değil, yönetişime uygulanır.

Yönetişim Parametreleri (Standart SIP ile Değiştirilebilir)

İtirazlar

Bir yönetişim kararının kötü niyetle alındığına inanan herhangi bir katılımcı (oy manipülasyonu, quorum sahtekârlığı, onaylanmış bir SIP’in yanlış uygulanması), karardan itibaren 30 gün içinde bir itiraz dosyalayabilir.

İtiraz süreci:

1. Kanıtla birlikte yönetişim forumuna itirazı gönderin
2. Teknik Komite 14 gün içinde inceler
3. Teknik Komite haklı bulursa: konu, 60 günlük bir tartışma dönemiyle yeni bir zincir üstü oylamaya gider
4. Teknik Komite reddederse: itiraz eden, Güvenlik Konseyi incelemesi talep edebilir (DID başına 12 ayda bir tırmandırmaya izin verilir)

İtirazlar, yürütülmüş zincir üstü işlemleri (ör. slashing olayları) geri alamaz ancak itiraz başarılı olursa telafi edici hazine ödemeleriyle sonuçlanabilir.

Yönetişim Kaynakları

Aşağıdaki kaynakların hiçbiri henüz canlı değildir — bunlar mainnet lansmanı için planlanan yönetişim yüzeylerini tanımlar, bugün gezilebilir adresler değildir.

• Forum: forum.solidus.network (zincir dışı tartışma) — henüz canlı değil
• Zincir üzerinde teklifler: gov.solidus.network (SIP oylaması ve hazine) — henüz canlı değil
• SIP deposu: SIP metni için herkese açık bir depo — henüz yayınlanmadı
• Yönetişim kontrol paneli: gov.solidus.network/dashboard (oy durumu, devretme, geçmiş) — henüz canlı değil
• Komite programları: gov.solidus.network/committees — henüz canlı değil