Parçalanmış DEX hovuzları: görünən likvidlikdən marşrut riskinə

Bakı bazarında eyni məhsul üç ayrı piştaxtada ola bilər. Bazarın ümumi ehtiyatı böyük görünsə də, alıcının dayandığı piştaxtada tələb etdiyi miqdar olmaya bilər. Başqa piştaxtaya keçmək, fərqli qiymətlə razılaşmaq və ya malı hissələrə bölmək lazım gəlir. “Bazarda cəmi nə qədər var?” ilə “bu alış üçün nə qədər əlçatandır?” eyni sual deyil.

DEX məlumatında da bir token üçün göstərilən ümumi likvidlik vahid anbar deyil. Kapital başqa şəbəkədə, başqa müqavilədə, başqa quote tokenlə, başqa komissiya pilləsində və ya marşrutun istifadə etmədiyi hovuzda qala bilər. Ona görə bu mövzuya yeni bir sürüşmə hesablayıcısı deyil, hovuzların harada və hansı şərtlə istifadə oluna bildiyini göstərən sübut xəritəsi lazımdır.

Ümumi rəqəmdən əvvəl hovuz xəritəsi qur

Hər hovuz ayrıca bazar obyektidir. Minimum qeyd chain və ya şəbəkə, pair address, base tokenin tam ünvanı, quote tokenin tam ünvanı, istiqamət, DEX və hovuz tipi, komissiya pilləsi məlumdursa həmin dəyər, likvidlik sahəsinin mənbəyi və müşahidə vaxtından ibarətdir.

DEX Screener sənədi pair nəticəsini `chainId`, `pairAddress`, `baseToken`, `quoteToken`, qiymət, dövri həcm və likvidlik kimi sahələrlə verir. Bu model faydalı başlanğıcdır, çünki “PEPE hovuzu” kimi boş etiket əvəzinə konkret obyekt yaradır. Lakin provider-in indekslədiyi pair siyahısı bütün zəncirin tam reyestri deyil və `liquidity.usd` istənilən istiqamətdə istifadə edilə bilən məbləğ vədi vermir.

Xəritədə hovuzlar əvvəl ayrı sətirlərdə qalır. Cəmləmə yalnız eyni aktiv kimliyi, uyğun quote məntiqi, eyni müşahidə vaxtı və tədqiqat sualına uyğun əhatə sübut edildikdən sonra əlavə təsviri göstərici ola bilər. Cəm rəqəmi heç vaxt orijinal sətirləri silməməlidir.

Simvol yox, tam aktiv kimliyi giriş qapısıdır

Eyni simvol fərqli müqavilələrdə istifadə oluna bilər. Eyni layihənin müxtəlif zəncirlərdə ayrıca müqaviləsi də ola bilər. Bir Ethereum hovuzu ilə eyni adlı başqa EVM zəncirindəki hovuzu toplamaq, körpü və iqtisadi münasibət ayrıca təsdiqlənməyibsə, likvidlik deyil ad oxşarlığını toplayır.

Kimlik paketi şəbəkənin tam adı, chain ID, tokenin tam müqavilə və ya mint ünvanı, ünvan növü və bu əlaqəni verən mənbədən ibarətdir. Solana-da mint ilə token account ayrılır; EVM-də proxy, wrapper və bridged versiya ayrıca işarələnir. Token ünvanını yoxlamaq bu qapının necə qurulduğunu izah edir.

Base və quote istiqaməti də kimliyin bir hissəsidir. TOKEN/USDC hovuzu ilə TOKEN/SOL hovuzu eyni token tərəfini saxlayır, amma qiymət yolu və risk daşıyan qarşı aktiv fərqlidir. Ekranda ikisinin də son nəticəsi USD kimi göstərilsə belə, çevirmə zənciri eyni olmaya bilər.

Qiymət təsiri ilə sürüşmə tolerantlığını ayır

Uniswap-ın açıq izahında price impact əməliyyatın hovuzdakı nisbətə təsiridir və əməliyyat ölçüsü ilə mövcud likvidliyə bağlıdır. Kiçik hovuzda nisbətən böyük sorğu qiyməti daha çox hərəkət etdirə bilər. Bu, əməliyyatın həmin vəziyyət daxilində yaratdığı mexaniki təsirdir.

Price slippage isə gözlənilən nəticə ilə icra zamanı alınan nəticənin fərqidir. Sifariş hazırlanandan zəncirə daxil edilənədək bazar dəyişə, başqa əməliyyatlar hovuzun vəziyyətini yeniləyə və marşrut başqa nəticə verə bilər. Slippage tolerance istifadəçinin qəbul etdiyi sərhəddir; müşahidə olunan nəticənin özü deyil.

Bu üç ifadəni “slippage” adı altında birləşdirmək araşdırmanı korlayır. Price impact üçün hovuz vəziyyəti və ölçü münasibəti, faktiki slippage üçün ilkin quote ilə icra nəticəsi və onların vaxtı, tolerance üçün isə əməliyyat parametrinin dəyəri lazımdır. Uniswap sənədi çox aşağı tolerance-ın revert ehtimalını, çox yüksək tolerance-ın daha az token alınması riskini izah edir. Bu fakt hər token üçün sabit və tövsiyə edilən faiz yaratmır.

Marşrut hovuz cəmindən daha dar ola bilər

Bir aqreqator sorğunu iki və ya daha çox hovuz arasında bölə bilər. Bu, ekranda görünən bütün hovuzların avtomatik istifadə edildiyi demək deyil. Marşrut token uyğunluğuna, zəncirə, icazə verilən protokollara, komissiyaya, qaz xərcinə, qarşı tokenə və həmin andakı vəziyyətə görə məhdudlaşa bilər.

Məsələn, üç hovuzun hər biri eyni base tokeni göstərir, amma biri yanlış müqaviləyə, biri zəif quote aktivinə, biri isə düzgün cütə aiddirsə, başlıqdakı ümumi likvidlik real yolun dərinliyini şişirdir. Başqa halda iki düzgün hovuz ola bilər, lakin aralarındakı əlavə keçid və zəncir xərci kiçik məbləğ üçün istifadəni mənasız edir. Bu məqalə həmin xərci hesablamır; yalnız onun hovuz cəmindən çıxarıla bilmədiyini göstərir.

Marşrut sübutu varsa, route ID və ya istifadə edilən pair-lər, quote vaxtı, blok, giriş və gözlənilən çıxış kimi sahələr saxlanır. Yoxdursa “bütün hovuzlar istifadə oluna bilər” yazılmır. Naməlum marşrut ayrıca statusdur.

Parçalanma həm şəbəkə, həm cüt, həm də vaxt üzrədir

Likvidlik yalnız məkan üzrə bölünmür. Hovuz vəziyyəti zamanla dəyişir: əlavə və çıxarışlar, əməliyyatlar, quote aktivinin qiyməti və provider yeniləməsi rəqəmi dəyişdirə bilər. Səhər bir hovuzdan, günorta digərindən götürülmüş məlumatı eyni snapshot kimi toplamaq səhv zaman paketi yaradır.

Hər sətirdə upstream müşahidə vaxtı varsa ayrıca, saytın fetch vaxtı ayrıca saxlanır. Provider yalnız fetch vaxtını verirsə bu məhdudiyyət qeyd edilir. Pair-in yaradılma tarixi canlı likvidliyin vaxtı deyil; iyirmi dörd saatlıq həcm də cari ehtiyat snapshot-ı deyil.

Başqa zəncirdəki hovuz üçün körpü vaxtı və əməliyyat riski də yaranır. Kapital iqtisadi baxımdan bağlı görünsə belə, bir şəbəkədəki swap digər şəbəkənin ehtiyatına atomik çıxış vermir. “Multichain cəmi” marketinq ölçüsü ola bilər, tək marşrutun icra dərinliyi deyil.

Həcm hovuzları birləşdirən körpü deyil

Yüksək iyirmi dörd saatlıq həcm kapitalın gün ərzində neçə dəfə dövr etdiyini göstərə bilər. O, həmin anda quote tərəfdə nə qədər ehtiyat qaldığını, neçə hovuzun eyni kapitalı saydığını və müəyyən istiqamətdə nə qədər qiymət təsiri yaranacağını bildirmir. Həcmlə dərinliyin fərqi dövr göstəricisi ilə snapshot arasındakı sərhədi geniş izah edir.

Eyni əməliyyat ekosistemdə bir neçə məlumat məhsulunda görünə bilər. Bir indeksləşdirici pair həcmini, başqa provayder token üzrə aqreqatı, analitika səhifəsi isə DEX cəmini təqdim edə bilər. Bu rəqəmləri toplamaq yeni iqtisadi fəaliyyət yaratmır; eyni hadisəni iki dəfə saya bilər.

Araşdırma hər həcm sahəsi üçün pəncərə, timezone, pair əhatəsi, base/quote istiqaməti və mənbə metodunu saxlamalıdır. Həcm likvidlik xəritəsinə kontekst verir, lakin hovuzların bir-birinə keçidini sübut etmir.

Uyğunsuzluq xəta yox, araşdırma siqnalıdır

Provider A üç hovuz, provider B beş hovuz göstərirsə əvvəl “hansı yalan deyir?” sualı verilmir. İndeksləmə əhatəsi, chain seçimi, deaktiv pair qaydası, quote token filtri və yenilənmə vaxtı yoxlanır. Bir provider wrapped aktivi əsas tokenə birləşdirə, digəri ayrıca saxlaya bilər.

Null likvidlik sıfır likvidlik deyil. Stale nəticə cari nəticə deyil. Pair tapılmaması zəncirdə pair yoxdur hökmü deyil. Bu statusların hamısı mənbə, sorğu və vaxtla saxlanır. Son məlum rəqəm göstərilirsə “cari” etiketi almır və hansı vaxtdan qaldığı görünür.

Anomaliya qeydi müşahidə ilə şərhi ayırır: “provider-də 14:05-də pair yoxdur” müşahidədir; “hovuz bağlanıb” isə əlavə zəncir sübutu tələb edən izahdır. Bu ayrım sosial media iddiasını məlumat nəticəsinə çevirməyin qarşısını alır.

Fee tier hovuz kimliyinin bir hissəsidir

Eyni DEX, şəbəkə və token cütü bir neçə haqq pilləsində ayrı hovuz yarada bilər. Hovuz ünvanı və fee tier yazılmadan iki müşahidə eyni obyekt kimi birləşdirilə bilər. Aşağı haqq həmişə daha yaxşı icra demək deyil; cari aktiv likvidlik diapazonu və marşrut da nəticəyə təsir edir.

Konsentrasiyalı likvidlikdə LP mövqeləri müxtəlif qiymət aralıqlarında olur. Ümumi kilidli dəyərin hamısı cari tick ətrafında işləməyə bilər. Buna görə hovuz kartındakı ümumi dollar rəqəmi konkret istiqamətdə əlçatan dərinliyin yerini tutmur.

Hovuz versiyası da saxlanır. Protokolun yeni versiyasında hook, fərqli fee mexanizmi və ya router qaydası ola bilər. Eyni brend altında olmaq müqavilə davranışını eyniləşdirmir.

Router quote-u hovuz state-indən ayrı müşahidədir

Router bir və ya bir neçə hovuzdan keçən yol seçə bilər. Quote alınanda giriş tokeni, çıxış tokeni, dəqiq məbləğ, istiqamət, marşrut, fee-lər, blok və vaxt saxlanır. Sonradan eyni sorğu fərqli yol qaytara bilər; quote icra zəmanəti deyil.

Aggregator bir neçə DEX-i birləşdirəndə onun cavabı tək hovuz qiyməti kimi yazılmır. Hər ayaq mümkündürsə tam müqavilə kimliyi ilə açılır. Yolun bir hissəsi naməlumdursa yekun “bütün bazar dərinliyi” sayılmır.

Quote API-si simulyasiya, indekslənmiş state və ya canlı RPC oxusundan istifadə edə bilər. Mənbə sənədi bunu izah etmirsə metod naməlum qalır. Ekran vaxtı fetch vaxtının yerinə keçmir.

Token decimals və istiqamət xətasını erkən tut

Pool reserve xam tam ədəd ola bilər. Hər tokenin decimals dəyəri öz müqaviləsindən oxunur; eyni simvollu başqa tokenin dəyəri köçürülmür. Token0/token1 sırası dəyişəndə qiymət nisbəti tərs çevrilməlidir. Bu iki xəta zahirən inandırıcı, amma miqyasca yanlış rəqəm yarada bilər.

USD dəyəri ayrı qiymət ayağı tələb edir. Qarşılıq aktivinin dollar qiyməti köhnədirsə hovuz reserve-ləri fresh olsa belə dollar görünüşü qarışıq yaşdadır. Hər ayağın vaxtı ayrı saxlanır.

Token vergi, rebase və transfer məhdudiyyəti kimi qeyri-standart davranışa malikdirsə sadə reserve modeli faktiki alınan məbləği təsvir etməyə bilər. Bu mexanizmlər sübut olunmadan standart token kimi vəd verilmir.

Likvidliyin silinməsi zaman hadisəsidir

LP mövqeyi bağlananda və ya reserve çıxarılanda hovuzun cari icra qabiliyyəti dəyişə bilər. Köhnə snapshot həmin kapitalı hələ mövcud göstərə bilər. Ona görə likvidlik rəqəmi vaxt və blok olmadan uzunmüddətli hovuz keyfiyyəti kimi saxlanmır.

LP tokeninin burn edilməsi, NFT mövqeyinin bağlanması və əsas token burn-u ayrı hadisələrdir. “Likvidlik yandırıldı” layihə ifadəsi konkret müqavilə və redemption imkanları ilə yoxlanır. Əlçatmaz LP mövqeyi hovuzdakı əsas tokenləri protokol təklifi xaricinə çıxarmır.

Timelock və locker xidməti istifadə edilirsə müqavilə, beneficiary, unlock vaxtı və admin səlahiyyəti yoxlanır. Uzaq sayt etiketi on-chain vəziyyətin yerini tutmur.

Fragmentasiya qeydinin qəbul meyarı

Hər hovuz sətri şəbəkə, DEX versiyası, pair address, token0/token1 tam müqavilələri, fee tier, blok və fetch vaxtı olmadan natamam sayılır. Likvidlik sahəsi ilkin vahidi və USD çevirmə yolunu saxlayır. Provider bu sahələrdən birini vermirsə boşluq sıfırla doldurulmur.

Marşrut iddiası üçün router cavabında bütün ayaqlar və dəqiq giriş məbləği görünməlidir. Ayrı hovuzların mövcudluğu onların bir transaction-da birlikdə istifadə ediləcəyini sübut etmir. Cross-chain kapital isə bridge, vaxt və qarşı təmsil sübutu olmadan eyni marşruta daxil edilmir.

Yekun cədvəl ümumi hovuz sayına keyfiyyət balı vermir. O, istifadə edilə bilən əlaqəni, yalnız eyni aktivə aid olduğu təsdiqlənən hovuzu və naməlum mapping-i ayrı saxlayır. Beləliklə fragmentasiya müşahidəsi proqnoz və ya order məsləhətinə çevrilmir.

Stable pair və volatile pair eyni əyri deyil

Bəzi AMM-lər bir-birinə yaxın qiymətli aktivlər üçün stable əyri, digər cütlər üçün volatile əyri istifadə edir. UI-da eyni “liquidity” sahəsi görünsə də reserve-lərin order-a reaksiyası fərqlidir. Hovuz fabriki, pool type və müqavilə versiyası xəritədə saxlanır.

Stabil adı tokenin həmişə sabit qalacağına zəmanət deyil. Qarşılıq aktivinin bazar qiyməti dəyişəndə USD görünüşü və hovuz balansı ayrı təsir alır. Curve növü iqtisadi təhlükəsizliyi deyil, swap funksiyasını təsvir edir.

Token vergi və fee-on-transfer yolu dəyişdirir

Transfer zamanı token müqaviləsi haqq tuta bilər. Router nominal girişi göndərsə hovuz daha az məbləğ ala bilər. Standart quote kodu bunu dəstəkləmirsə simulyasiya ilə icra arasında fərq yaranar. Vergi dərəcəsi cari müqavilə state-i və istiqamətə görə yoxlanır.

Blacklist, max transaction və trading switch kimi qaydalar da hovuza baxmaqla görünməyə bilər. Pool reserve-nin mövcudluğu hər ünvanın swap edə biləcəyinə zəmanət deyil. Contract permission araşdırması likvidlik xəritəsindən ayrı qatdır.

Oracle qiyməti pool spot-u deyil

Protokol TWAP və ya xarici oracle istifadə edə bilər. Oracle müəyyən zaman pəncərəsini, medianı və ya ayrı mənbələri birləşdirir; pool-un cari spot nisbəti ilə eyni deyil. Liquidation və collateral sistemi oracle-a baxa, router isə pool state-indən quote yarada bilər.

Oracle update vaxtı, round ID, heartbeat və stale qaydası məlum olmadan onun qiyməti canlı hovuz qiyməti kimi yazılmır. Eyni token üçün iki rəqəmin fərqli olması bu obyekt ayrılığından yarana bilər. Sayt avtomatik comparator hökmü yaratmır.

Mempool və state dəyişikliyi quote-un ömrünü qısaldır

Quote alınandan transaction bloka daxil olana qədər başqa swap-lar state-i dəyişə bilər. İctimai mempool-da transaction sırası və MEV davranışı da faktiki icraya təsir edə bilər. Köhnə quote bu gələcək state üçün müqavilə deyil.

Deadline və minimum output istifadəçi qoruma parametrləridir. Onların olması transaction-un mütləq keçəcəyini göstərmir; şərt ödənməsə revert edə bilər. İş vərəqi quote vaxtı ilə receipt vaxtını ayırır.

Cross-chain hovuz eyni anda əlçatan kapital deyil

Eyni token brendi Ethereum, BNB Smart Chain və Solana-da hovuzlara malik ola bilər. Bir zəncirdəki transaction digər zəncir reserve-nə birbaşa toxunmur. Kapitalın daşınması bridge, vaxt, fee və representation riskini tələb edir.

Qlobal səhifədə hovuzlar yanaşı göstərilə bilər, amma icra xəritəsində chain sərhədi qalır. Bridge işləmirsə başqa zəncirdəki böyük hovuz cari route-a qoşula bilməz. Buna görə chain-lər üzrə TVL cəmi konkret order dərinliyi deyil.

Wrapped quote aktivini ayrıca yoxla

Native aktivin wrapped versiyası ERC-20 və ya SPL müqaviləsi kimi istifadə oluna bilər. WETH/ETH və SOL/WSOL texniki çevirmələri layihənin xüsusi token bridge-i ilə eyni deyil. Routerin hansı variantdan istifadə etdiyi pair contract və route addımlarında görünür.

Başqa custodian wrapped tokeni isə redemption və ehtiyat mexanizmi tələb edir. Simvola “W” əlavə edilməsi əlaqəni sübut etmir. Qarşılıq aktivinin kimliyi səhvdirsə USD conversion və hovuz təsnifatı da səhv olur.

Pool yaradılma tarixi keyfiyyət balı deyil

Yeni hovuz az tarixçəyə, köhnə hovuz isə köhnəlmiş müqavilə və boş reserve-ə malik ola bilər. Yaradılma transaction-ı yalnız pool-un nə vaxt və hansı factory-dən çıxdığını göstərir. Cari likvidlik, owner imkanları və route istifadəsi ayrıca müşahidə olunur.

Factory rəsmi protokol sənədində yoxlanır. Saxta DEX görünüşü eyni token cütü ilə başqa factory-də hovuz yarada bilər. Pair address rəsmi factory event-i və contract code ilə uzlaşdırılır.

Reserve balansı ilə daxili accounting fərqlənə bilər

Token müqaviləsinin `balanceOf(pool)` cavabı AMM-in saxladığı daxili reserve sahəsi ilə eyni olmaya bilər. Birbaşa token transferi pool balansını dəyişdirə, `sync` və ya oxşar funksiya daxili state-i sonradan uyğunlaşdıra bilər. Protokol versiyasına görə bu fərqin davranışı dəyişir.

Araşdırma hər iki sahəni adı ilə saxlayır. Xarici token balansını daxili reserve kimi təqdim etmir və fərqdən avtomatik exploit nəticəsi çıxarmır. Transaction və contract məntiqi səbəbi göstərməlidir.

Hovuz fee-si LP gəliri vədi deyil

Swap fee pool qaydasının hissəsidir, lakin LP-nin gəliri həcm, mövqe aralığı, token qiyməti, impermanent loss, protocol fee və zamanla bağlıdır. Fee tier-i təkbaşına “yüksək gəlir” kimi təqdim etmək olmaz.

Toplanmamış fee mövqeyə aid state ola bilər. Onun göstərilməsi real claim, vergi və qiymət nəticəsini izah etmir. Sayt likvidlik təmin etmə kalkulyatoru və gəlir proqnozu vermir.

Token miqrasiyası hovuz tarixçəsini bölür

Layihə yeni müqaviləyə keçəndə köhnə hovuz avtomatik yeni token bazarı olmur. Köhnə pair hələ ticarət oluna və eyni simvolu göstərə bilər. Rəsmi miqrasiya, çevirmə nisbəti və yeni pair address ayrıca təsdiqlənir.

Tarixçə iki müqavilə arasında səssiz birləşdirilmir. Köhnə pool likvidliyi yeni contract üçün cəm edilmir. Provider köhnə və yeni bazarı qarışdırırsa mapping problemi kimi qeyd olunur.

Sübut screenshot-u xam ünvanın yerini tutmur

DEX səhifəsinin screenshot-u pair adı, reserve və reklamı eyni anda göstərə bilər, lakin dinamik state tez köhnəlir. Cookie örtüyü və ya böyük reklam əsas sahəni bağlayırsa sübut qəbul edilmir. Şəkil yalnız görünən faktın tarixli əlavəsidir.

Əsas sübut pair address, chain, block/slot, API və ya contract state-dir. Screenshot yenidən yoxlama URL-i və baxış vaxtı ilə saxlanır. Saxta interface və hesab təcrübəsi yaradılmır.

Fragmentasiya xəritəsinin yenilənməsi

Yeniləmə əvvəl aktiv reyestrini, sonra hər chain üzrə factory və pair siyahısını yoxlayır. Silinmiş və ya boşalmış hovuz tarixçədən yox olmur; son müşahidə və statusla qalır. Yeni hovuz yalnız tam kimlik və rəsmi/protokol əlaqəsi ilə əlavə olunur.

Hər source time və fetch time ayrıdır. Provider `null` qaytarırsa sıfır likvidlik yazılmır. Parser və ya network xətası əvvəlki rəqəmi fresh saxlamır.

Pool state üçün məlumat keyfiyyəti statusu

Pool müşahidəsi fresh olduqda yalnız onun blok/slot və fetch yaşı qəbul həddi daxilindədir. Bu status reserve-in gələcək transaction-a qədər dəyişməyəcəyini və ya contract-ın təhlükəsiz olduğunu göstərmir. Stale müşahidə son uğurlu state-i vaxtı ilə saxlayır; yeni quote kimi təqdim edilmir.

RPC cavabı uğursuz, pair schema-sı natamam və ya token mapping-i həll olunmamışdırsa `unavailable` istifadə olunur. Əvvəlki reserve rəqəmi etiketsiz göstərilmir. `0` yalnız həqiqi xam state sıfır olduqda saxlanır; `null`, missing və parser xətası sıfıra çevrilmir.

Provider pool-u siyahıdan çıxardıqda bu, onun on-chain mövcudluğunun silindiyi demək deyil. Son pair address ilə zəncir state-i ayrıca yoxlanır. Provider əhatəsi və chain mövcudluğu iki ayrı statusdur.

Parçalanma araşdırmasının redaksiya sərhədi

Məqalə hovuz sayını tokenin populyarlıq balına çevirmir. Çox hovuz kapitalın və qiymət discovery-sinin bölünməsini göstərə bilər, amma təkbaşına daha yaxşı və ya pis bazar hökmü yaratmır. Az hovuz da avtomatik mərkəzləşmiş və ya təhlükəli nəticəsi deyil.

Cari rəqəmlər istifadə edilirsə hər biri tarixli və mənbəlidir. Dəyişkən TVL və reserve screenshotdan köçürülüb daimi fakt kimi saxlanmır. Təcrübəni bəzəmək üçün uydurma token, uydurma pool və ya hesab hekayəsi əlavə edilmir.

Nəticə istifadəçiyə order ölçüsü, gəlir və ya qiymət istiqaməti məsləhəti vermir. O, yalnız hansı kapitalın eyni chain və route daxilində olduğunu, hansı məbləğin başqa cüt və şəbəkədə qaldığını, hansı əlaqənin hələ sübut edilmədiyini göstərir.

Yekun çıxış bir rəqəm deyil, istifadə xəritəsidir

Yaxşı hesabat hovuzları şəbəkə və aktiv kimliyi üzrə qruplaşdırır, amma hər pair-i ayrıca saxlayır. Hər sətirdə istiqamət, quote aktiv, provider, görünən likvidlik, vaxt, məlumat vəziyyəti və marşrut uyğunluğu olur. Sonra üç nəticə yazılır: hansı kapitalın eyni araşdırma obyektinə aid olduğu təsdiqlənib; hansı hovuzların bir marşrutda istifadə edilə biləcəyi sübut edilib; hansı əlaqələr hələ naməlumdır.

Bu xəritə “nə qədər almalı” cavabı vermir və icra nəticəsini proqnozlaşdırmır. Onun faydası daha əsasdır: böyük görünən cəmin arxasında ayrı zəncirləri, ayrı cütləri və ayrı vaxtları görünən edir. Sürüşmə haqqında fikir yalnız həmin sərhədlərdən sonra mənalı ola bilər.