> For the complete documentation index, see [llms.txt](https://novacont.gitbook.io/nova-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://novacont.gitbook.io/nova-docs/novacont-docs/turkish/audit-and-security/novacont-lite-security-review.md).

# NovaCont Lite Security Review

### Kapsam 

* NovaCont\_Lite.tact

### Metodoloji

* Manuel kod incelemesi: iki tur halinde yürütülmüştür. İlk turda mimari ve durum-geçiş mantığı incelenmiş, bulgular geliştirici tarafından giderilmiş; ikinci turda düzeltmeler kaynak kod seviyesinde doğrulanmıştır. 
* Statik Analiz: Misti 

| Seviye        | Sayı | Kategori                                                                                                                                                                                                         |
| ------------- | ---- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Kritik/Yüksek | 0    | Yok                                                                                                                                                                                                              |
| Orta seviye   | 9    | SuboptimalSend, send() yerine gas-verimli message() önerisi, fonksiyonel risk yok                                                                                                                                |
| Düşük seviye  | 29   | PreferredStdlibApi (require -> throwUnless), PreferSenderFunction (context().sender -> sender()), EtaLikeSimpliifications, UnusedMethodArgument, tamamı gas optimizasyonu veya stil, davranış farkı bulunmamakta |

Misti ile yapılan statik analizler doğrultusunda kod tabanında hiçbir fonksiyonel güvenlik açığı bulunmamıştır. İşaretlenen her şey gas optimizasyonu veya API tercihi düzeyindedir. 

### Manuel İnceleme 

İlk incelemede tespit edilen, geliştirici tarafından giderilen ve kaynak kod üzerinden doğrulanan bulgular; 

#### CancelEscrow state-mutation sıralama hatası \[Giderildi]

İlk versiyonda, escrow\.state yerel değişkeni STATE\_CANCELLED olarak güncellendikten sonra escrow\.state == STATE\_CREATED kontrolü yapılıyorudu; bu kontrol her zaman "false" dönüyordu çünkü değişken zaten mutasyona uğramıştı. Yalnızca "acceptTime == 0" koşulu fiilen çalışıyordu ve bu koşul, STATE\_CREATED durumunun her zaman doğru bir vekili olduğu için pratikte zararsız kalıyordu. Dead condition, gelecekteki bir refactor'da sessizce gerçek bir hataya dönüşebilecek bir risk taşıyordu. Bu durum artık mutasyondan önce "wasNotYetAccepted: Bool" değişkeninde yakalanıyor, state değişikliği sonrasında bu önceden yakalnmış değer kullanılıyor. 

#### SendIgnoreErrors modu ile sessiz fon kaybı riski \[Giderildi] 

Tüm "send()" çağrıları, başarısız bir transferi sessizce yutan "sendIgnoreErrors" yerine "SendBounceIfActionFail" moduna geçirilmiştir. Bir transfer artık başarısız olduğunda işlem bounce ediliyor, state güncellemesi transferin başarısıyla tutarlı kalıyor. Kod tabanındaki her "send()" çağrısı doğrulandı. 

#### Fon dağıtım mantığının merkezileştirilmesi \[Giderildi]

İlk versiyonda "CancelEscrow"un ceza uygulanan iptal dalı, "distributeFunds"tan bağımsız kendi fon bölüştürme mantığını taşıyordu. Bu ikili yapı, bir düzeltmenin diğer kod yoluna yansımaması riskini taşıyordu (nitekim ilk zafiyetteki bug yalnızca bu dalda kalmıştı). 

Artık "cancelEscrow", "distributeFunds(escrowId, escrow, 5000 veya 10000)" çağrısı üerinden tek bir merkezi fonksiyona yönlendiriliyor. Bu, hem kod tekrarını ortadan kaldırıyor hem de STORAGE\_RESERVE hesaplamasının tüm fon dağıtım senaryolarında tutarlı olmasını garanti ediyor. 

#### Dipsute çözümünde tek-nokta-arıza \[Giderildi] 

İlk versiyonda anlaşmazlıklar, kişisel bir hesaba bağlı olarak çözülüyordu. Artık "AddSupport/RemoveSupport" ile yönetilen bir destek havuzu ve "nextSupportAssign" ile round-robin dağıtım mekanizması mevcut bir anlaşmazlık açıldığında (RaiseDispute), sırayla bir destek üyesine atanıyor.  "RemoveSupport"taki swap-with-last-element pattern'i, index/count/nextAssign senkronizasyonunu doğru koruyor. 

> Not: Bu bir bug düzeltmesi değil, mimari dayanıklılık iyileştirmesidir. Merkezileşme riskini azaltır ancak ortadan kaldırmaz. 

#### EscrowId çakışma riski \[Giderildi]

İlk versiyonda müşteri kendi escrow ID'sini seçebiliyordu, bu da iki farklı müşterinin aynı ID'yi seçmesi durumunda çakışma riski taşıyordu. Artık "escrowId","self.escrowCount" ile otomatik ve sıralı olarak atanıyor.

<table><thead><tr><th>Bulgu</th><th>Durum</th><th data-hidden></th></tr></thead><tbody><tr><td>Tam sayı bölme yuvarlama kaybı</td><td>dust-level, ölçülebilir etkisi yok</td><td></td></tr><tr><td>description/evidenceUrl alanlarında maksimum uzunluk kontrolü yok</td><td>düşük öncelikli, gas öngörülebilirliği için önemli</td><td></td></tr><tr><td>Event isimlendirme tutarlılığı (EscrowCreated vs )</td><td>Kozmetik, fonksiyonel risk yok</td><td></td></tr><tr><td>Minimum agreedTon alt sınırı tanımlı değil</td><td>ancak "distributeFunds" taki > STORAGE_RESERVE koşullu kontrolleri sayesinde negatif/geçersiz gönderim riski zaten örtük olarak önlenmiş durumda</td><td></td></tr></tbody></table>

### Sonuç

İlk incelemede tespit edilen bir Yüksek ve bir Orta seviyeli bulgu dahil olmak üzere altı bulgunun tamamı, v1.1.0'da doğrulanmış şekilde gösterilmiştir. Mistik statik analizi, kod tabanında herhangi bir fonksiyonel güvenlik açığı tespit etmemiştir. NovaCont Lite, bu doğrulama turunun sonunda ana NovaCont kontratlarıyla karşılaştırılabilir bir olgunluk seviyesine ulaşmıştır. Bağımsız bir üçüncü taraf denetimi hala önerilir, ancak dahili inceleme sürecinin titizliği ve düzeltme hızı olumlu bir sinyaldir.&#x20;