İlk 100 token saxlayıcısı: siyahını kim seçir

“İlk 100 saxlayıcı ünvan” cədvəli açılanda ilk oxunan adətən iki faiz olur: birinci sətrin payı və ilk on sətrin cəmi. Cəmlənmə barədə demək olar bütün iddialar bu iki rəqəmdən başlayır. Çətinlik isə ondadır ki, həmin rəqəmlər blokçeyndən birbaşa gəlmir — onlar artıq kimsə tərəfindən seçilmiş bir siyahının üzərində hesablanır.

Bunu əl ilə yoxlamaq mümkündür. Aşağıdakı rəqəmlər yalnız hesablama qaydasını göstərmək üçün uydurulub və heç bir tokenə, heç bir real şəbəkə vəziyyətinə aid deyil.

Tutaq ki, siyahıda cəmi on sətir var və qalıqlar böyükdən kiçiyə düzülüb: 40%, 17%, 9%, 8%, 7%, 6%, 5%, 4%, 2%, 2%. Bu cədvəldəki faizlərin məxrəci bu on sətrin cəmidir, ümumi təklif deyil — bu iki məxrəc eyni şey deyil və sonra ayrıca qeyd olunur. Aşağıdakı üç variantdan biri isə elə bu məxrəcin özünü dəyişir; onun başqa bir oxunuş verməsinin səbəbi məhz budur. “Birinci sətir qırx faiz, ilk iki sətir birlikdə 57%” — cədvəlin verdiyi ilk oxunuş budur.

İndi blokçeyndə bir bayt belə dəyişmədən yalnız siyahını düzəldənin əvvəlcədən qoyduğu qayda dəyişir.

Birinci variant: birinci sətir əslində likvidlik hovuzunun müqaviləsidir və siyahı hovuz müqavilələrini kənarda saxlamaq qərarı verir. Qalan doqquz sətir yenidən 100%-ə normallaşdırılır, 17%-lik sətir birinci olur və payı 17÷60, yəni təxminən 28% edir; ilk iki sətrin cəmi 57%-dən təxminən 43%-ə düşür. Eyni qalıqlar, lakin hovuzu çıxarmaq və çıxarmamaq bir-birinin əksi olan iki təəssürat verir — hansının həqiqətə daha yaxın olduğunu isə cədvəlin özü demir.

İkinci variant: bu on sətir Solana şəbəkəsindəndir və ikinci, üçüncü, dördüncü, beşinci sətirlərin owner sahəsi eyni cüzdanı göstərir. Owner üzrə birləşdirdikdən sonra siyahı yeddi sətrə düşür, birləşmiş sətir 17+9+8+7＝41% olur və köhnə birincini ötür; ilk iki sətrin cəmi 57%-dən 81%-ə qalxır. Sətir sayı üç azalır, yuxarı hissə isə iyirmi dörd faiz bəndi ağırlaşır.

Üçüncü variant: qalığı sıfır olan, lakin tarixdə köçürmə almış ünvanlar da “saxlayıcı ünvan” sayılır. Burada diqqət yetiriləsi şey məhz payların ümumiyyətlə dəyişməməsidir — sıfır qalıq məxrəcə heç nə əlavə etmir, on sətir elə on sətir qalır, nə 41%, nə 28% tərpənir. Dəyişən başqa bir oxunuşdur: “bu tokenin neçə saxlayıcı ünvanı var” sualının cavabı ondan yüzlərlə, hətta minlərlə ünvana çevrilir. “İlk on sətrin payı” ilə “neçə saxlayıcı var” rəqəmləri isə çox vaxt eyni cümlədə eyni şeyin iki üzü kimi verilir.

Üç dəyişiklik, bir-birinə uyğun gəlməyən üç oxunuş — hamısının altında isə eyni qalıqlar dayanır; üstəlik onlardan biri ümumiyyətlə payları yox, “saxlayıcı” sözünün kimi əhatə etdiyini dəyişir. Fərq siyahı düzəlməzdən əvvəl yaranır: kiminsə hansı obyektin bir sətir sayılacağına qərar verdiyi anda.

Deməli “bu token cəmlənibmi” sualından əvvəl daha erkən bir sual cavab gözləyir: bu siyahını kim və hansı qaydayla seçib. Aşağıda həmin xətt izlənir. Sıralama qəsdən belədir — əvvəl əks-nümunə, sonra standartın mətni; çünki standartı əvvəl oxuyan adam çox vaxt onu siyahıya verilmiş zəmanət kimi qəbul edir, halbuki standart burada heç nəyə zəmanət vermir.

Kontrakt tərəfində “kim saxlayır” sualına cavab verən metod yoxdur

EIP-20 token müqaviləsinin verə biləcəyi hər şeyi sadalayır: metodlar name, symbol, decimals, totalSupply, balanceOf, transfer, transferFrom, approve, allowance — doqquz ədəd (bunlardan name, symbol və decimals OPTIONAL kimi işarələnib, standart açıq yazır ki, başqa müqavilələr “MUST NOT expect these values to be present”); hadisələr isə yalnız Transfer və Approval. Standartın heç bir yerində saxlayıcıların siyahısını, saxlayıcıların sayını və ya hər hansı formada ünvan sadalanmasını qaytaran bir şey yoxdur.

balanceOf imzası bunu daha aydın göstərir: `balanceOf(address _owner) public view returns (uint256 balance)`, izahı isə "Returns the account balance of another account with address `_owner`". Metod çağıranın əlində artıq bir ünvanın olmasını tələb edir və “hansı ünvanlar var” sualına cavab vermir.

Buna görə “ilk 100” siyahısı yalnız başqa yolla düzəlir: kimsə müqavilənin yaydığı Transfer hadisələrini əvvəldən təkrar oxuyur, hər ünvanın giriş-çıxışını özü yığır, sonra öz qoyduğu qaydayla sıralayır və neçənci sətrə qədər götürəcəyinə özü qərar verir. Hər addım insan seçimidir; seçim qaydası siyahını düzəldənin əlindədir, blokçeyndə yazılmır.

Standart “saxlayıcı” sözünü tərif etmir və indeksləyənin davranışı barədə heç nə demir. Bunu olduğu kimi yadda saxlamaq lazımdır: standartdan hər hansı konkret siyahının necə hazırlandığı çıxarıla bilməz, hansısa bir tərəfin üsulunu “hamı belə hesablayır” kimi ümumiləşdirmək isə daha yanlışdır.

Sıfır dəyərli köçürmə iki ayrı çoxluq yaradır

Hadisələri təkrar oxuyan adam dərhal standartın açıq yazdığı, lakin oxunarkən tez-tez ötürülən bir qaydaya rast gəlir.

Transfer hadisəsi üçün tələb belədir: "MUST trigger when tokens are transferred, including zero value transfers". transfer və transferFrom bölmələrində ayrıca qeyd var: "Transfers of 0 values MUST be treated as normal transfers and fire the Transfer event". Miqdarı sıfır olan köçürmə də hadisə yayır.

Nəticə birbaşadır. Hadisə axınında görünən ünvanlar yığılanda alınan çoxluq “tarixdə hansısa köçürməyə yazılmış ünvanlar” olur; hazırda qalığı sıfırdan böyük olan ünvanlar isə ayrı və daha kiçik çoxluqdur, nə qədər kiçik olduğu hadisə sayından çıxarıla bilmir. Hər iki çoxluq siyahının bazası ola bilər, alınan cədvəllər isə eyni olmur.

Standart yaradılış üçün bir qayda da qoyub: "A token contract which creates new tokens SHOULD trigger a Transfer event with the `_from` address set to 0x0 when tokens are created." Sıfır ünvan hadisə axınında from tərəfində görünür. Onun ünvan sayılıb-sayılmayacağı, siyahıya düşüb-düşməyəcəyi barədə standart bir kəlmə də yazmır — bunu da siyahını düzəldən özü qərara alır.

ethereum.org-un ERC-20 səhifəsi həmin metod və hadisələri eynilə təkrarlayır, standartın verdiyi imkanları isə dörd maddəyə yığır: hesablar arasında köçürmə, bir hesabın cari qalığının oxunması, şəbəkədəki ümumi təklifin oxunması, üçüncü tərəfə müəyyən məbləği xərcləmə icazəsinin verilməsi. Heç biri hesabların sadalanması deyil.

Siyahıdakı sətrin arxasında mütləq bir adam durmur

Həmin ethereum.org səhifəsində balanceOf çağırışını göstərən bir Web3.py nümunəsi var. Nümunəyə ötürülən “hesab” ünvanı barədə səhifənin öz şərhi yazır ki, bu, bir Uniswap V2 hovuz müqaviləsidir.

Burada dayanmağa dəyər. Rəsmi sənəd “bir hesabın qalığını oxumaq” nümunəsini qurarkən əlinə keçən hesab elə bir hovuz olub. Deməli “hesab qalığı” ifadəsinin özü o biri tərəfdə bir adamın durduğuna zəmanət vermir.

Hovuz tokenləri necə saxlayır — Uniswap-ın tərtibatçı sənədi bunu açıq yazır: protokol likvidlik hovuzlarını idarə edir, hər hovuz iki ERC-20 tokenin ehtiyatlarından ibarətdir və qiymətlər hovuzun vəziyyətinə görə yenilənir; istənilən şəxs token cütünü hovuza qoyaraq likvidlik təchizatçısı ola bilər; istifadəçi mübadilə edəndə hovuzun ehtiyatları ilə ticarət edir.

Ehtiyatlar hovuz müqaviləsinin adına saxlanır, ona görə hovuz siyahıda bir ünvan kimi görünür, həmin sətrin altında isə istənilən sayda əmanətçi dayanır. O sətri “bir saxlayıcı bu qədər saxlayır” kimi oxumaq cəmlənmə hesabına əslində paylanmış olan bir kütləni əlavə edir.

Bundan bir addım da irəli getmək olmaz. Sənəd heç bir hovuzun qalığını və ya payını vermir, digər avtomatlaşdırılmış bazar qurucularına və başqa şəbəkələrdəki hovuz tətbiqlərinə toxunmur; ona görə “hovuzlar siyahının neçə faizini tutur” sualına dair burada heç bir nəticə çıxarılmır. Nümunədə hansı ünvanın seçilməsi yalnız sənəd müəllifinin yazı üsulunu göstərir və statistik iddia sayılmır.

Hovuz sətrini açmaq: üç versiya, üç ayrı üsul

Sətrin hovuz olduğu bilinəndən sonra növbəti sual özü gəlir: onu açıb arxadakı əmanətçilərə qayıtmaq mümkündürmü. Eyni Uniswap sənədi burada çox konkret bir çətinlik verir.

Sənəddə yazılır ki, likvidlik paylarının uçotu versiyadan asılıdır: v2 ehtiyatların proporsional payını təmsil edən eynicinsli ERC-20 hovuz tokenləri buraxır; v3 və v4-də hər likvidlik təchizatçısı müəyyən qiymət aralığı seçir, v3-də mövqelər NonfungiblePositionManager vasitəsilə ERC-721 kimi təmsil olunur, v4-də mövqeləri PositionManager idarə edir və daxili uçot üçün ERC-6909 işlədilir.

Üç fərqli sənəd forması, üç fərqli oxunuş üsulu. v2 yolu ən asan görünür — hovuz tokeni eynicinsli ERC-20-dir, deməli onun üçün də bir siyahı düzəltmək kifayət edir; bir dəfə edən isə görür ki, bu, əvvəlki sualı olduğu kimi bir mərtəbə geriyə atır və yeni siyahı üçün çoxluq yenidən müəyyən edilməlidir. v3-də hər biri öz qiymət aralığını daşıyan NFT mövqeləri var, v4-ün uçotu isə PositionManager-in içindədir; v2 üsulunu onların üzərinə qoyanda alınan rəqəm soruşulan sualla heç cür uzlaşmır.

Siyahıdakı sətir zahirən sadəcə bir sətirdir, onu açmağın qiyməti isə hovuzun hansı versiya olmasından asılıdır və bu məlumat həmin sətrin içində yazılmır.

Solana tərəfində siyahı cüzdanları deyil, token hesablarını sıralayır

Şəbəkə dəyişəndə terminologiya bütöv şəkildə dəyişir, çoxluğun müəyyən edilməsi problemi isə forma dəyişərək qalır.

Solana-nın rəsmi sənədində əsas maddələr belədir: Mint Account konkret bir tokeni təmsil edir və ümumi təklif, emissiya səlahiyyəti kimi qlobal məlumatları saxlayır; Token Account konkret bir owner-in konkret bir mint üzrə sahibliyini izləyir; Associated Token Account isə ünvanı owner və mint ünvanlarından törədilən adi bir Token Account-dır. Token Account-ın sahələri mint, owner, amount, delegate, state, is_native, delegated_amount və close_authority-dir.

Açar cümlə heç bir şübhə buraxmır: cüzdan hansısa tokeni saxlamaq istəyirsə, ona həmin token üçün bir token hesabı lazımdır və cüzdan ünvanı həmin hesabın owner-i olaraq təyin edilir; hər cüzdan eyni token (mint) üzrə birdən çox token hesabına sahib ola bilər, bir token hesabının isə yalnız bir owner-i olur və yalnız bir mint-in vahidlərini saxlayır.

Qalıq token hesabının üzərində durur. Ünvanlara görə sıralanmış siyahı ona görə token hesablarını sadalayır, adamları yox. Eyni şəxs siyahıda bir neçə yer tuta bilər, ona görə sətir sayını saxlayıcı sayı kimi oxumaq paylanmanı olduğundan geniş göstərir. Adama qayıtmaq üçün bir qat da dərinə oxumaq lazımdır: nəzarət edəni token hesabının owner sahəsi göstərir və bu qat siyahının üzündə görünmür.

İki nüans da buraya aiddir. Associated Token Account yalnız ünvan törətmə üsuludur; sənəd açıq yazır ki, ATA sadəcə ünvanı müəyyən qaydayla alınmış bir token hesabıdır, yəni kimlik sənədi kimi oxunmamalıdır. İkincisi, ATA yaratmaq hesabın saxlanması üçün geri qaytarıla bilən minimum qalıq tələb edir və sənədə görə bu məbləği əmri göndərən ödəyir, hətta ATA başqa cüzdana məxsus olduqda belə. Deməli token hesabının mövcudluğu ilə onun indiki qalığı bir-birindən asılı deyil, rentanı ödəyən hətta owner olmaya da bilər.

Bu bölmənin yaza biləcəyi son cümlə budur: əvvəlcə bu siyahının hansı qat üzrə sıralandığını soruşmaq lazımdır. Həmin səhifə heç bir blok izləyicisinin saxlayıcı reytinqini owner üzrə birləşdirib-birləşdirmədiyini izah etmir, ona görə burada “izləyicilər birləşdirmir” yazılmır. delegate və close_authority-nin tam mənası burada yoxlanılmayıb və açılmır.

Siyahıya düşməyən hissə sadalanmamış fərqdir

İlk 100-dən kənarda nə qədər qalıq olduğu və onun neçə ünvana düşdüyü bu siyahıdan çıxmır.

Siyahının verdiyi yeganə şey ilk 100 sətrin qalıqlarıdır. Ümumi təklifdən bu 100 sətrin cəmini çıxanda bir fərq alınır. Həmin fərq bir rəqəmdir, siyahı deyil: onun sətir sayı, sıralaması və kimliyi yoxdur.

İki yazı üsulu bu fərqi olmadığı bir şeyə çevirir. Biri onu sıfır sayır və “qalanını nəzərə almamaq olar” deyir; digəri ona kimlik verir və “qalanı xırda investorlardır” yazır. Hər ikisi siyahının dəstəklədiyi həddi aşır. Yuxarıdakı bölmələrin məntiqinə görə o hissədə hovuz müqavilələri ola bilər, eyni şəxsin bir neçə token hesabı ola bilər, qalığı sıfır olan, lakin tarixdə görünmüş ünvanlar ola bilər (siyahının tərifindən asılı olaraq), adı çəkilməyən başqa formalar da ola bilər.

Məxrəci də ayrıca yoxlamaq lazımdır: ümumi təklif hansı sahədən götürülüb, hansı blok hündürlüyündə və ya slot-da oxunub, siyahı ilə eyni ana aiddirmi.

Burada yoxlanılmayan dörd məsələ

Aşağıdakı dörd seçim qaydası üzrə rəsmi izah əldə edilməyib. Onlar mətni sonradan oxuyanın nəyi tamamlamalı olduğunu bilməsi üçün sadalanır, məlum şərt kimi işlədilmir.

Birincisi, blok izləyicilərinin saxlayıcı reytinqini necə hesablaması. Etherscan-ın məlumat mərkəzində (info.etherscan.com) 2026-09-19 tarixində sayt daxilində axtarış aparılıb və token saxlayıcıları siyahısının necə qurulduğunu izah edən yazı tapılmayıb; axtarışa düşənlər token məlumatının təqdimi üzrə təlimat, ERC-721 nədir tipli yazılar olub. Ona görə “müqavilə ünvanları çıxarılırmı, owner üzrə birləşdirilirmi, sıfır qalıqlı ünvanlar sayılırmı” suallarına burada heç bir tərəf üçün cavab verilmir və heç kimin alqoritmi təsvir edilmir. Hansı siyahı işlədiləcəksə, bu suallar həmin mənbədən ayrıca soruşulmalıdır.

İkincisi, saxlama qalıqları və şəbəkələrarası körpülərin kilidli ünvanları. Siyahıdakı bəzi ünvanların bir nəfərin deyil, çox sayda adamın əmanətini və ya kilidini təmsil etməsi barədə burada heç bir rəsmi sənəd əldə edilməyib. Buna görə yalnız bir cümlə yazıla bilər: konkret bir ünvanın bu sinfə aid olub-olmadığını müəyyən etmək üçün ayrıca əsas lazımdır. Heç bir platformanın adı çəkilmir və heç bir ünvan sinfinin mütləq belə olduğu iddia edilmir.

Üçüncüsü, sıfır ünvanın və ictimai yandırma ünvanlarının ayrı-ayrı siyahılarda saxlayıcı sayılıb-sayılmaması. Yoxlanılmayıb. Bu, əvvəlcədən fərz edilə bilməyən, təsdiqlənməli olan bir seçim qaydasıdır; onun çıxarıldığını fərz etməklə sayıldığını fərz etmək iki fərqli məxrəc verir.

Dördüncüsü, Solana tərəfdə blok izləyicilərinin token hesablarını owner üzrə birləşdirib-birləşdirməməsi. Yoxlanılmayıb — rəsmi sənəd heç bir tərəfin toplama üsulunu izah etmir.

Oxunuşlar uyğun gəlmirsə, əvvəlcə çoxluğu yoxlayın

Bir müddət sonra eyni token yenidən oxunanda rəqəmlər fərqlənirsə, ən rahat izah paylanmanın dəyişməsidir. Bu izahın dayanıqlı olması üçün daha tez-tez rast gəlinən başqa bir ehtimal əvvəlcədən aradan qaldırılmalıdır: iki oxunuşun eyni çoxluq üzərində aparılmaması.

Çoxluğun dəyişə biləcəyi yerlər yuxarıdakı bölmələrdə artıq göründü. Siyahının mənbəyi dəyişib; eyni mənbə istisna qaydasını dəyişib; bir dəfə token hesabı üzrə, bir dəfə owner üzrə sıralanıb; bir dəfə sıfır qalıqlı ünvanlar sayılıb, bir dəfə sayılmayıb; iki müşahidə eyni blok hündürlüyünə və ya slot-a düşməyib. Bunlardan biri dəyişəndə faiz də dəyişir, blokçeyndəki paylanma isə tamamilə olduğu kimi qala bilər.

Ona görə bir oxunuşdan nəyin qalacağının yalnız bir ölçüsü var: həmin dəfənin seçim qaydası rəqəmin yanında olduğu kimi yazılsın, o qədər aydın yazılsın ki, başqa bir adam eyni qayda ilə işi təkrarlayıb eyni rəqəmləri alsın. Bu olmayanda faiz təyin sahəsi olmayan bir rəqəmə çevrilir və növbəti müqayisədə çox vaxt iki qayda arasındakı fərq ölçülür.

Cəmlənmənin özünün nə demək olduğu ayrı sualdır və o, bu sualdan sonra gəlir. Siyahı dəqiq müəyyən edilməmiş qaldıqca cəmlənmə barədə hər hansı iddianın bir şərti çatışmır.

Tez-tez verilən suallar

Müqavilədən birbaşa “indi neçə saxlayıcı var” soruşmaq üçün metod varmı?

Yoxdur. EIP-20-nin doqquz metodu və iki hadisəsi arasında ünvan sadalayan bir şey yoxdur, balanceOf isə çağıranın əlində artıq bir ünvanın olmasını tələb edir. Saxlayıcı sayı da, saxlayıcı siyahısı da kiminsə Transfer hadisələrini təkrar oxuyub özü yığmasının və sıralamasının nəticəsidir.

Siyahıdakı sətirləri adam kimi saymaq olarmı?

Olmaz, həm də sapma hər iki istiqamətdə mümkündür. Bir sətir hovuz müqaviləsi ola bilər və onun altında istənilən sayda əmanətçi dayanır — rəsmi nümunədə balanceOf-a ötürülən ünvan səhifənin öz şərhinə görə bir Uniswap V2 hovuzudur. Digər tərəfdən Solana-da bir cüzdan eyni mint üzrə bir neçə token hesabı saxlaya bilər, yəni eyni şəxs bir neçə sətir tuta bilər.

Eyni tokenin “ilk on payı” müxtəlif yerlərdə fərqli görünürsə, hansına inanmaq lazımdır?

Həmin faiz tokenin deyil, siyahının funksiyasıdır, ona görə fərq özlüyündə təəccüblü deyil. Müqavilə ünvanlarının çıxarılması, owner üzrə birləşdirmə, sıfır qalıqlı ünvanların sayılması, neçənci sətrə qədər götürülməsi, hansı hündürlükdə oxunması — hamısı fərqli ola bilər. Tərəflərin üsulları burada yoxlanılmayıb və heç kimin alqoritmi təsvir edilmir.

İlk 100-dən kənardakı hissəni xırda investorların payı saymaq olarmı?

Olmaz. Bu, ümumi təklifdən çıxılmaqla alınan sadalanmamış fərqdir; nə sətir sayı, nə kimliyi var. İçində hovuz müqavilələri, eyni şəxsin bir neçə token hesabı ola bilər. Bir rəqəmi bir qrup kimi oxumaq siyahının dəstəklədiyi şey deyil.

Siyahıda hovuz olduğu bilinirsə, niyə həmin sətir açılıb yenidən hesablanmır?

Çünki açma üsulu universal deyil. Uniswap sənədinə görə likvidlik paylarının uçotu versiyadan asılıdır: v2-də eynicinsli ERC-20 hovuz tokeni, v3-də ERC-721 mövqe, v4-də PositionManager-in ERC-6909 ilə apardığı daxili uçot. Yarıda başqa versiya ilə qarşılaşanda bütün üsul dəyişməlidir — kənarda qalan fərqin tamamlana bilməməsinin konkret səbəblərindən biri budur.