DEX mübadiləsi: sürüşmə, qiymət təsiri və token icazələri

Bir swap əslində hansı mərhələlərdən ibarətdir?

DEX — mərkəzləşdirilməmiş mübadilə protokoludur. İstifadəçi aktivini bir şirkət hesabına yatırmaq əvəzinə pul kisəsi ilə smart müqaviləyə müraciət edir. İnterfeys mümkün marşrutu və təxmini nəticəni göstərir, pul kisəsi isə zəncirdə icra olunacaq məlumatı imzalayır. Buna görə ekran, protokol və token müqaviləsi eyni şey deyil. Saxta sayt düzgün protokolun adını göstərə, amma imzaya başqa xərcləyici ünvanı qoya bilər.

ERC-20 tokeni ilk dəfə həmin router ilə dəyişirsinizsə, adətən iki zəncir əməliyyatı görünür. Birincisi approval: token müqaviləsinə müəyyən ünvanın sizin adınızdan token xərcləyə biləcəyini bildirir. İkincisi swap: təsdiqlənmiş limit daxilində token hovuz və ya router vasitəsilə dəyişdirilir. Native şəbəkə aktivi üçün ayrıca ERC-20 approval tələb olunmaya bilər, lakin swap yenə şəbəkə haqqı və müqavilə riski daşıyır.

EIP-20 standartında approve və allowance məhz bu xərcləmə səlahiyyətini müəyyən edir. Bəzi tokenlər və tətbiqlər EIP-2612 permit tipli imzadan istifadə edə bilər. “Qazsız imza” ifadəsi təhlükəsiz və nəticəsiz imza demək deyil: imza sonradan allowance yaratmaq üçün təqdim oluna bilər. Pul kisəsi ekranında əməliyyat və mesaj imzasını fərqləndirin, amma hər ikisinin domenini, xərcləyicisini, tokenini, məbləğini və son tarixini oxuyun.

Price impact ilə slippage niyə eyni deyil?

Qiymət təsiri (price impact) sizin sifarişinizin mövcud likvidlik üzrə qiyməti nə qədər dəyişdirdiyini göstərir. Hovuz dayazdırsa və ya sifariş böyükdürsə, daha pis orta qiymət alırsınız. Uniswap-ın rəsmi izahına görə təsir sifariş ölçüsü və hovuz likvidliyi ilə əlaqəlidir. Bu, bazarın siz imza atdıqdan sonra dəyişməsi deyil; kotirovkanın özündə olan icra xərcidir.

Sürüşmə dözümlülüyü (slippage tolerance) isə kotirovka ilə zəncir icrası arasındakı qəbul etdiyiniz maksimum fərqdir. İnterfeys bunun əsasında minimum alınacaq məbləği hesablayır. Faktiki çıxış həmin minimumdan aşağı düşərsə, müqavilə əməliyyatı geri qaytara bilər. Geri qayıdan swap token dəyişimini ləğv etsə də, validatorun gördüyü işə görə şəbəkə haqqı çox vaxt geri qaytarılmır.

Həddi çox dar seçmək dəyişkən bazarda təkrar uğursuz əməliyyat və əlavə qaz xərcinə səbəb ola bilər. Həddi həddən artıq geniş seçmək isə daha zəif icranı qəbul edir və bəzi marşrutlarda MEV/sandwich təsirinə açılan sahəni böyüdə bilər. Deməli, “ən təhlükəsiz faiz” hər token və hər an üçün eyni deyil. Likvid aktiv, dayaz token, transfer vergili token və böyük sifariş ayrı qiymətləndirilməlidir; tətbiqin cari standartını daimi qayda kimi yadda saxlamayın.

Kotirovkanı manat düşüncəsi ilə necə yoxlamaq olar?

DEX kotirovkası adətən token cütü ilə verilir, bank çıxarışı isə sizin üçün AZN dəyəri tələb edə bilər. Əvvəl “verəcəyim token”, “alacağım token” və şəbəkə haqqını ayrı qeyd edin. Sonra eyni zaman nöqtəsinə aid etibarlı bazar qiyməti ilə yalnız müqayisə aparın. AZN çevirməsi protokolun verdiyi zəmanət deyil; qiymət mənbəyi və vaxtı sübut faylında saxlanmalıdır.

Nümunə: interfeys 1 000 vahid A tokeninə 496 B tokeni göstərir, minimum output 491 B-dir. Şəbəkə haqqı ayrıca ödənilir. İmza ilə 496-nı deyil, müqavilə şərtlərinə uyğun ən az 491 sərhədini qəbul edirsiniz. 493 B gəlsə əməliyyat sərhəd daxilindədir, amma ilkin ekrandan 3 B azdır. Alınan məbləği yalnız “swap uğurlu” bildirişi ilə deyil, transaction receipt və pul kisəsi balans dəyişikliyi ilə təsdiqləyin.

Böyük məbləği hissələrə bölmək qiymət təsirini azalda bilər, amma hər hissə üçün ayrıca qaz, bazar hərəkəti və əməliyyat riski yaradır. Aqreqator daha yaxşı marşrut göstərə bilər, lakin əlavə müqavilə və token ötürmə addımları risk səthini artırır. Təkcə çıxış rəqəmini deyil, marşrutu, hovuzları, bridge olub-olmadığını və alınan tokenin dəqiq müqavilə ünvanını yoxlayın.

Approval icazəsində əsas təhlükə nədir?

Approval tokeni dərhal göndərmir; xərcləyiciyə gələcəkdə limit daxilində transferFrom çağırışı etmək səlahiyyəti verir. Məhdud approval yalnız planlaşdırılan məbləği əhatə edir. Limitsiz approval rahatdır, amma xərcləyici müqavilə sındırıldıqda, yenilənmə açarı sui-istifadə edildikdə və ya saxta ünvan təsdiqləndikdə pul kisəsindəki gələcək token balansı da riskə düşə bilər.

“Revoke” ayrıca zəncir əməliyyatıdır: allowance sıfırlanır və qaz tələb olunur. Ethereum.org naməlum saytla əlaqəni kəsməyi və lazımsız token approval-larını ləğv etməyi tövsiyə edir. Lakin revoke artıq oğurlanmış aktivi geri gətirmir, zərərli off-chain imzanı avtomatik ləğv etmir və başqa şəbəkədəki icazəni silmir. Hər şəbəkə, token və xərcləyici ayrıca yoxlanmalıdır.

Token ünvanını simvola görə seçməyin. Eyni ad və ikonla saxta müqavilə yaradıla bilər. Layihənin rəsmi sənədindən müqavilə ünvanını götürün, blok tədqiqatçısında xərcləyicinin ünvanını və əməliyyat metodunu müqayisə edin. Pul kisəsi “set approval for all” və ya anlaşılmaz blind-signing göstərirsə, təsdiqi dayandırın; ERC-721/1155 kolleksiya icazəsi ERC-20 allowance-dan daha geniş aktiv qrupunu əhatə edə bilər.

Əməliyyat niyə uğursuz ola bilər?

Rəsmi Uniswap dəstək materialında əsas səbəblər arasında kifayət etməyən şəbəkə aktivi, dəyişən bazar, slippage sərhədi və problemli token davranışı var. “Failed” statusu yalnız texniki nəticədir. Əvvəl transaction hash-i rəsmi blok tədqiqatçısında açın, statusu, çağırılan müqaviləni, sərf olunan qazı və token transfer hadisələrini yoxlayın. İnterfeysin təkrar düyməsinə kor-koranə basmayın.

Pending əməliyyatı eyni nonce ilə dəyişdirmək və ya ləğv etmək pul kisəsi və şəbəkədən asılıdır. “Support” adı ilə seed phrase istəyən şəxslə danışmayın. Seed phrase, private key və ekran paylaşımı heç vaxt əməliyyat diaqnostikası üçün lazım deyil. Rəsmi dəstək kanalına belə toxum sözünü vermək olmaz.

Token satıla bilmirsə, bunu avtomatik olaraq daha yüksək slippage ilə həll etməyə çalışmayın. Honeypot, transfer məhdudiyyəti, blacklist, yüksək token vergisi və saxta likvidlik ola bilər. Müqavilə kodu auditi zəmanət deyil; admin səlahiyyəti, proxy yenilənməsi, likvidlik kilidi və holder paylanması ayrıca araşdırılır.

Dini qiymətləndirmə hansı sualları ayrıca saxlayır?

Texniki cəhətdən uğurlu DEX swap dini uyğunluq barədə yekun hökm vermir. Aktivlərin mahiyyəti, real sahiblik və qabz, mübadilənin dərhallığı, qiymət və miqdarın məlumluğu, borc/leverage, faiz mexanizmi, tokenin əsas fəaliyyəti və müqavilədə həddən artıq qeyri-müəyyənlik ayrıca qiymətləndirilməlidir. AAOIFI-nin qabz materialı və Beynəlxalq İslam Fiqh Akademiyasının rəqəmsal aktiv qətnaməsi ümumi çərçivə verir, konkret token və protokol üçün avtomatik təsdiq deyil.

Slippage həddinin mövcudluğu təkbaşına qumar hökmü yaratmır və “smart contract” etik uyğunluğu təmin etmir. Alimə token ünvanı, hovuz cütü, qiymət formulu, fee, minimum output, əməliyyat vaxtı, alınan aktiv üzərində faktiki çıxarış/nəzarət və borc komponenti barədə sübut təqdim edin. Marketinq adını deyil, real müqaviləni qiymətləndirin.

Swap kotirovkasını necə sübut faylına çevirmək olar?

Kotirovka qısa müddət yaşayır, buna görə yalnız son transaction hash-i saxlamaq qərarın hansı məlumatla verildiyini göstərmir. İmzadan əvvəl tarix və saatı, pul kisəsi şəbəkəsini, giriş və çıxış tokeninin müqavilə ünvanını, giriş miqdarını, təxmini və minimum çıxışı, price impact, slippage, marşrutu və göstərilən bütün fee-ləri qeyd edin. Ekran görüntüsü faydalıdır, amma mətn kopyası və ya rəsmi interfeysin transaction detallarını da saxlayın. Sonradan interfeys dizaynı dəyişsə, həmin qeydlər imzanın məzmununu izah etməyə kömək edir.

Zəncir nəticəsində transaction status, block nömrəsi, çağırılan router, real token transfer hadisələri və sərf olunan qazı arxivləşdirin. Approval ayrıca transaction-dırsa, onun hash-i, spender və limitini də yazın. Swap başqa şəbəkədən bridge istifadə edirsə, bridge mesajını eyni swap kimi göstərməyin; hər mərhələnin öz riski və sübutu var. Uçot üçün ilkin kotirovka ilə faktiki alınan məbləğin fərqini ayrıca göstərin. Bu fərq price impact, bazar hərəkəti, token vergisi və ya marşrut haqqının qarışığı ola bilər; səbəbi yalnız yekun balansdan müəyyən etmək olmaz.

Multi-hop marşrut daha yaxşı qiymət deməkdirmi?

Birbaşa A/B hovuzu dayaz olduqda router A tokenini əvvəl WETH və ya stabilkoinə, sonra B tokeninə dəyişə bilər. Hər əlavə hop başqa hovuz haqqı, müqavilə çağırışı və qiymət təsiri yaradır, amma ümumi likvidlik daha dərin olduğu üçün yekun çıxış yenə yaxşı ola bilər. Buna görə hop sayına təkbaşına “yaxşı” və ya “pis” hökmü verməyin; minimum output və bütün marşrut üzrə faktiki çıxışı müqayisə edin.

Aqreqator birdən çox DEX və hovuz arasında sifarişi bölə bilər. Bu, qiyməti yaxşılaşdıra bilər, lakin router, adapter və approval səthini genişləndirir. İnterfeysdə tanınmış token simvolu görünməsi hər adapterin yoxlanmış olduğunu göstərmir. Route details bölməsində istifadə olunan protokolları, hədəf müqavilələri və bridge olub-olmadığını açın. Hədəf tokenin bir neçə şəbəkə versiyası varsa, likvidliyi çox görünən hovuz sizin istədiyiniz kanonik tokeni deyil, üçüncü tərəf wrapped tokenini verə bilər.

Birbaşa marşrutla aqreqator təklifini eyni blok vaxtına yaxın müqayisə edin. Bir neçə dəqiqə aralı kotirovka fərqi marşrut keyfiyyətindən çox bazar hərəkəti ola bilər. Məbləği hissələrə bölərkən hər hissənin qazını, dəyişən qiymətini və əlavə imza riskini hesablayın; sadəcə ilk kiçik hissənin yaxşı nəticəsini qalan məbləğə ekstrapolyasiya etməyin.

MEV və sandwich riski istifadəçiyə necə görünür?

İmzalanmış swap ictimai mempool-a düşəndə başqa iştirakçılar əməliyyatın ölçüsünü və slippage sərhədini görə bilər. Sandwich modelində hücumçu sizin əməliyyatdan əvvəl eyni istiqamətdə alıb hovuz qiymətini dəyişir, sizin swap daha pis sərhəddə icra olunur, sonra öz mövqeyini bağlayır. Minimum output müqaviləni sərhəddən aşağı nəticədən qoruyur, lakin sərhəd çox genişdirsə, zərərli qiymət hərəkəti həmin aralığa sığa bilər.

Bu riski azaltmaq üçün əvvəl dayaz hovuz və böyük order əlamətlərini yoxlayın, əsassız geniş slippage seçməyin və interfeysin təqdim etdiyi qorunan göndəriş/private routing funksiyasının dəqiq şərtini oxuyun. “MEV protected” marketinq adı tam zəmanət deyil: əməliyyatın hansı relayerə getdiyi, uğursuz olduqda açıq mempool-a yayılıb-yayılmadığı və əlavə etibar tərəfinin kim olduğu aydın olmalıdır.

Deadline də vacibdir. Çox uzun deadline köhnə kotirovkanın sonradan icra şansını artırır; çox qısa deadline sıx şəbəkədə uğursuzluq yarada bilər. Pul kisəsində qaz qiymətini və pending nonce-ları yoxlayın. Eyni nonce ilə sürətləndirmə yalnız həmin zəncir əməliyyatına aiddir; approval artıq təsdiqlənibsə, swap-ın ləğvi allowance-u avtomatik sıfırlamır.

Transfer vergili, rebase və honeypot tokenləri necə ayırmaq olar?

Bəzi token müqavilələri hər transferdən faiz kəsir, alışı və satışı fərqli dərəcə ilə vergiyə cəlb edir, müəyyən ünvanları bloklayır və ya maksimum transaction limiti qoyur. İnterfeys adi ERC-20 davranışı fərz edirsə, alınan məbləğ kotirovkadan kəskin fərqlənə və swap revert edə bilər. Slippage-i artırmaq kontraktın admin riskini və yüksək verginin iqtisadi itkisini həll etmir.

Rebase tokenində pul kisəsindəki vahid sayı protokol qaydasına görə dəyişə bilər. Wrapped və vault tokenində isə bir vahidin əsas aktivə çevrilmə nisbəti dəyişir. Simvol və nominal balans eyni olsa da, faktiki tələb hüququ eyni deyil. Müqavilənin rəsmi sənədində transfer mexanizmi, mint/burn, blacklist, pause və upgrade səlahiyyətini axtarın. Blok tədqiqatçısında müqavilənin verified olması kodun təhlükəsiz və ya etik olduğunu sübut etmir; yalnız yayımlanan bytecode ilə mənbənin əlaqəsini yoxlamağa kömək edir.

Honeypot tokeni almağa icazə verib satışı məhdudlaşdıra bilər. Naməlum token üçün yalnız “başqası sata bildi” sosial media videosuna güvənməyin; göstərilən müqavilə ünvanı, blok və satıcının xüsusi whitelist statusu fərqli ola bilər. Kiçik sınaq belə adminin sonradan qaydanı dəyişməyəcəyinə zəmanət vermir. İzah edə bilmədiyiniz tokeni almaqdan imtina etmək də etibarlı risk qərarıdır.

Approval həyat dövrünü necə idarə etmək olar?

İlk addım mövcud allowance-u şəbəkədə oxumaqdır. İnterfeys yeni approval istəmirsə, daha əvvəl verilmiş limit hələ aktiv ola bilər. Token, owner və spender üçlüyü birlikdə yoxlanır; eyni router adı başqa zəncirdə başqa ünvana malikdir. Məbləğə bərabər approval risk səthini məhdudlaşdırır, amma bəzi tokenlər limiti dəyişməzdən əvvəl sıfırlama tələb edə bilər və nəticədə əlavə transaction yaranır.

Limitsiz approval istifadə rahatlığı üçün verilirsə, bu qərarı ayrıca qeyd edin və istifadə bitəndən sonra ehtiyacı yenidən qiymətləndirin. Revoke vasitəsini açarkən də saxta domen riski var; rəsmi pul kisəsi və ya tanınmış blok tədqiqatçısının contract write funksiyasından istifadə etdikdə ünvanı yenə yoxlayın. Revoke transaction-ının uğurlu statusunu və yeni allowance-un sıfır olduğunu on-chain oxuyun. Sadəcə wallet disconnect etmək token müqaviləsindəki allowance-u silmir.

Router kontraktı proxy ilə yenilənirsə, köhnə spender allowance-u qala, yeni versiya isə ayrıca approval istəyə bilər. Hansı versiyanın işlədiyini tarixlə saxlayın. Kompromet şübhəsində əvvəl zərərli sayta yeni imza verməyi dayandırın, qalan tokenləri təhlükəsiz ünvana daşımağın riskini qiymətləndirin və hər allowance-u şəbəkə üzrə ləğv edin. Toxum sözünü “yoxlama” üçün heç kimə göndərməyin.

Failed, pending və dropped statuslarında hansı ardıcıllıq işləyir?

Failed transaction bloka daxil olub, amma müqavilə icrası revert edib. Token swap baş verməyə bilər, qaz isə xərclənir. Receipt-də çağırılan ünvanı və hadisələri yoxlayın; saxta interfeys “failed” yazsa da, approval ayrıca uğurlu ola bilər. Pending transaction hələ yekunlaşmayıb. Eyni hesabdan sonrakı nonce-lar onun arxasında qala bilər. Pul kisəsinin sürətləndir və ləğv funksiyası eyni nonce ilə yeni transaction göndərir, lakin validatorun hansını qəbul edəcəyinə tam zəmanət vermir.

Dropped və ya “not found” yerli node və mempool vəziyyətini göstərə bilər. Başqa rəsmi tədqiqatçı ilə transaction hash-i yoxlayın və hesab nonce-nu müqayisə edin. Eyni swap-ı təkrar göndərməzdən əvvəl əvvəlki transaction-ın həqiqətən icra edilmədiyini təsdiqləyin; iki ayrı nonce təsdiqlənsə, iki swap baş verə bilər.

Dəstəyə müraciətdə public wallet ünvanı və transaction hash adətən diaqnostika üçün kifayətdir. Private key, seed phrase, 2FA kodu, uzaqdan idarəetmə proqramı və “wallet validation” imzası lazım deyil. Rəsmi saytın support keçidini özünüz açın, axtarış reklamından və şəxsi mesajdan gələn agentə güvənməyin. Problemin tarixçəsini saxlayın: səhv mətni, şəbəkə, token, nonce, qaz parametri və etdiyiniz hər addım.

Ümumi xərci və real nəticəni necə hesablamaq olar?

Swap nəticəsini yalnız “alınan token sayı” ilə ölçmək yanlış ola bilər. Başlanğıc aktivin eyni vaxtdakı istinad dəyərini, alınan aktivin faktiki dəyərini, pool/protocol fee, qaz, approval qazı, bridge və ya aqreqator haqqı, token transfer vergisi və sonradan geri çıxış xərcini ayrıca yazın. Real nəticə bu xərclər çıxıldıqdan sonra görünür. Manatla uçot aparırsınızsa, AZN qiymət mənbəyinin adını və vaxtını saxlayın; protokolun dollar rəqəmi avtomatik yerli uçot qiyməti deyil.

Bir swap gələcək gəlir vəd edən vault və ya liquidity position tokeni verirsə, çıxış tokenini əsas aktivlə eyni saymayın. Exchange rate, lockup, withdrawal queue, impermanent loss və müqavilə riskini ayrıca sənədləşdirin. Göstərilən APR və ya APY swap qiymət təsirini, qazı və əsas token qiymət dəyişikliyini kompensasiya etməyə bilər.

Dini və hüquqi məsləhət üçün də bu xərclər faydalıdır. Fee-nin xidmət haqqı, borca əlavə, gəlir payı və ya naməlum token kəsintisi olması fərqli müqavilə təsviri yaradır. Fakt faylı hökm vermir, amma mütəxəssisin real əməliyyatı marketinq adından deyil, məbləğ, hüquq, öhdəlik və zaman ardıcıllığı ilə qiymətləndirməsinə imkan verir.

İki kotirovkanı ədalətli necə müqayisə etmək olar?

DEX A daha çox çıxış tokeni, DEX B isə daha aşağı şəbəkə haqqı göstərə bilər. Müqayisə eyni giriş məbləği, eyni token müqavilələri, eyni şəbəkə və mümkün qədər yaxın vaxtla aparılmalıdır. Bir interfeys fee-ni çıxışdan kəsir, digəri ayrıca sətirdə göstərirsə, böyük görünən rəqəm real üstünlük olmaya bilər. Minimum output, price impact, pool fee, protocol fee, approval qazı və swap qazını eyni cədvəldə toplayın.

Kotirovkanın etibarlılıq müddətini də yoxlayın. Biri beş saniyə əvvəl, digəri otuz saniyə əvvəl alınmışsa, dəyişkən bazarda fərq marşrutdan deyil vaxtdan yarana bilər. Eyni token simvolunun müxtəlif müqavilələrini müqayisə etməyin. Xüsusilə stabilkoin və wrapped aktivdə issuer, bridge və redeem hüququ fərqli ola bilər. Daha çox vahid almaq daha yaxşı aktiv almaq demək deyil.

Son qərarı faktiki receipt ilə bağlayın. İcra olunan marşrut ilkin təklifdən dəyişibsə, real token transfer hadisələrini və hər hop-un ünvanını saxlayın. Aqreqator uğursuz marşrutu başqa protokola yönəldə bilər; interfeysin yekun bildirişi bunu qısalda bilər. Məqsəd ən çox rəqəm göstərən düyməni seçmək deyil, əvvəlcədən qəbul etdiyiniz sərhədlə faktiki hüquq və xərci müqayisə etməkdir.