Rug pull і тихий вихід команди: 5 протоколів від піку TVL до нуля

Коротко (TL;DR)

Rug pull — це ситуація, коли люди, які контролюють проєкт, забирають вкладені гроші або позбавляють токен можливості бути проданим: знімають ліквідність із пулу, користуються прихованими правами контракту або просто зникають разом зі скарбницею. Більшість матеріалів на цю тему вчать перевіряти проєкт до депозиту. Цей розбір — про інше: гроші вже всередині, і треба зрозуміти, чи виходить команда просто зараз.

• Точок перевірки чотири, і всі читаються без довіри до блогу проєкту: слот адміністратора проксі-контракту, склад і поріг мультипідпису, рух скарбничих адрес, дати останніх комітів у репозиторіях.
• Термін життя повторюється від вибірки до вибірки. За п’ятьма протоколами, які DeFiLlama позначив rugged у 2025–2026 роках, від лістингу до піку TVL минало в середньому 57,4 дня (медіана — 67). У CertiK за 40 історичними інцидентами 2020–2023 середня — 92 дні, медіана — 57.
• Падіння TVL як сигнал запізнюється. У трьох протоколів із п’яти TVL обнулився наступного дня після піку або того самого дня. Стежити треба за правами й активністю, а не за графіком, де подія вже сталася.
• Просідання саме собою нічого не доводить. ZeroLend втратив 98,15% TVL — із $358 718 599 (8 листопада 2024 року) до $6 631 730 (17 лютого 2026 року), — і позначки rugged у DeFiLlama не отримав: причини оголошені публічно, а коміти у фронтенд ішли ще 27 серпня 2026 року.
• Слова про безпеку не дорівнюють факту. CEO SafeMoon публічно називав пули ліквідності «заблокованими», зберігаючи доступ до них; 10 лютого 2026 року він отримав 100 місяців в’язниці та форфейт близько $7,5 млн.
• Готового інструмента під це завдання немає. Honeypot-чекери та сканери контрактів самі пишуть, що дивляться на код у поточний момент, а не на поведінку команди в часі.

Rug pull, pump and dump і тихий вихід: три різні сценарії

Почнемо з термінів, бо в одну купу зазвичай зводять три несумісні речі.

Цей розбір — урок блоку «Ризики і захист» курсу «DeFi: від першої транзакції до профі-стратегій».

Rug pull (дослівно «висмикнути килим»; про постраждалий проєкт англомовною кажуть rug pulled, а сама rug pull definition звучить як «вилучення вартості інсайдерами») — це дії власників проєкту вже після того, як гроші залучені. Механіка буває різною: видалення ліквідності з пулу на децентралізованій біржі, через що продати токен фізично нікому; приховані функції контракту; блокування виведення; просто занедбаність.

BINANCE COPY TRADINGКопітрейдинг на BinanceВідкрита статистика трейдерів, старт з $10, вимкнення одним кліком.Обрати трейдера

Pump and dump — інша історія: скуповування дешевих токенів, штучний ажіотаж, продаж на піку. Тут маніпулюють сприйняттям попиту, а сам токен зазвичай продовжує існувати, і обміняти його можна — за ціною, що обвалилася. Різниця практична: після pump and dump у вас на руках подешевшалий актив, після rug pull — актив, який не вдається обміняти взагалі.

Депег стейблкоїна: дев’ять перевірок — від резервів емітента до глибини пулу

Ризики DeFi за шарами: два зломи дали 44% втрат, і жоден не баг коду

EIP-7702: один підпис віддає адресу контракту, а 97% делегувань вели на sweeper

OpenAI зупинила навчання найпотужніших моделей: агент вийшов із пісочниці через DNS

Crypto bridge між блокчейнами: три схеми і ціна від $0,063 до $0,19

Тихий вихід — предмет цього розбору. Формально команда нічого не краде в момент X: вона поступово скорочує мультипідпис, переводить права контракту на одну адресу, перестає комітити, перестає відповідати. Юридично це не завжди кваліфікується як скам, а за наслідками вкладник залишається з грошима в контракті, за яким більше ніхто не стежить.

Академічна праця SoK про причини rug pull (arXiv 2403.16082) розкладає явище на 34 першопричини, 19 підкатегорій і 6 категорій верхнього рівня: Simple rug pull (LP Drain), Sell rug pull (Token Distribution), Smart Contract Trap Doors, LP Manipulation, Counterfeit Token і комбінації. Для нашого завдання важлива одна межа всередині цієї таксономії.

Перший рядок закривають інструменти (про них — нижче). Четвертий рядок — те, чого не покриває жоден розібраний конкурент українською, російською та англійською: усі пишуть про перевірку до заходу й мовчать про спостереження за вже працюючим протоколом.

Наскільки це масово, показує єдина знайдена кількісна база щодо термінів — звіт CertiK про 40 «жорстких» інцидентів 2020–2023 років. Із 31 проєкту, за яким вдалося встановити склад команди, 24 (77,4%) були повністю анонімні, 7 (22,6%) — частково; жодного випадку повністю ідентифікованої команди у вибірці немає. Там-таки — деталь, що свідчить про підготовку: 37,5% проєктів (15 із 40) реєстрували домен через Namecheap із приватною реєстрацією, а разом із невпізнаваними доменами це 45% вибірки. Власну арифметику щодо термінів життя ми порахували незалежно, за публічним API DeFiLlama — вона в окремому розділі нижче.

Анонімність при цьому погана як одиночна ознака: анонімних команд у DeFi багато, і переважна більшість із них нікуди не тікає. Вона працює як множник до решти сигналів, а не як вирок.

Права контракту: proxy-admin, відмова від прав і передача власності

Більша частина DeFi працює на оновлюваних контрактах. Схема така: смартконтракт, у якому лежать гроші, — це проксі. Він зберігає стан і адресу другого контракту, де живе виконуваний код («реалізація»). Апгрейд протоколу — це заміна адреси реалізації. Хто може її замінити, записано в окремій комірці сховища.

BINANCE COPY TRADINGКопітрейдинг на BinanceВідкрита статистика трейдерів, старт з $10, вимкнення одним кліком.Обрати трейдера

Стандарт EIP-1967 фіксує, де саме ці комірки лежать, щоб будь-який експлорер і будь-який гаманець читали їх однаково:

• слот реалізації — 0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc, тобто bytes32(uint256(keccak256('eip1967.proxy.implementation')) - 1);
• слот адміністратора проксі — 0xb53127684a568b3173ae13b9f8a6016e243e63b6e8ee1178d6a717850b5d6103, тобто bytes32(uint256(keccak256('eip1967.proxy.admin')) - 1).

Зміщення «−1» у формулі стоїть навмисно: так прообраз хешу невідомий, і компілятор не може випадково покласти в той самий слот звичайну змінну.

Читаються ці комірки одним викликом eth_getStorageAt, без газу й без під’єднання гаманця. Порядок дій:

1. Узяти адресу контракту, куди ви кладете кошти (не адресу токена — саме адресу сховища або пулу).
2. Відкрити її в експлорері мережі й переконатися, що це проксі: у розділі Contract буде позначка про проксі-патерн і посилання на реалізацію.
3. Прочитати слот адміністратора: eth_getStorageAt(<адреса проксі>, 0xb531…5d6103). Останні 20 байтів результату — це адреса, яка може підмінити код.
4. Відкрити цю адресу. Далі три варіанти: це мультипідпис (добре), це контракт-таймлок (добре), це звичайний гаманець з одним приватним ключем (погано).
5. Повторити перевірку за місяць. Зміна — це факт, який ви виявите лише порівнянням із минулим значенням.

Окремо варто розуміти різницю двох функцій зі стандартної бібліотеки OpenZeppelin, які в текстах проєктів часто подають як одне й те саме. renounceOwnership() описана в документації так: «Leaves the contract without owner. It will not be possible to call onlyOwner functions anymore» — контракт залишається без власника, і адмінських функцій більше не викликати ніколи. transferOwnership(newOwner) — «Transfers ownership of the contract to a new account (newOwner). Can only be called by the current owner» — права просто переходять на іншу адресу.

Практичний маркер — події в логах контракту, але шукати треба правильну назву, інакше перевірка дасть хибне «усе гаразд». Сам стандарт EIP-1967 оголошує три події: AdminChanged(address previousAdmin, address newAdmin) — змінилася адреса в адмін-слоті, Upgraded(address indexed implementation) — замінено адресу реалізації, BeaconUpgraded(address indexed beacon) — для beacon-схеми. Події OwnershipTransferred у цьому стандарті не визначено взагалі: вона належить модулю Ownable і її емітує або контракт-адміністратор (у схемі OpenZeppelin це ProxyAdmin, він сам Ownable), або звичайний протокольний контракт на Ownable.

Різниця не термінологічна. Якщо шукати OwnershipTransferred у логах проксі, під час реальної зміни адміністратора ви не знайдете нічого — і зробите висновок, що права не змінювалися. Правильний порядок такий:

В усіх чотирьох рядків є поля «було» і «стало». Якщо нова адреса створена за кілька днів до переказу й без іншої історії, це саме той клас змін, заради яких варто перечитати розділ про мультипідпис нижче.

Мультипідпис протоколу: як прочитати підписантів і поріг підписів

«Управління децентралізоване» в блозі — твердження сторони. Перевірюваний еквівалент — мультипідпис: контракт, який виконує транзакцію лише за наявності кількох підписів. Найпоширеніший стандарт тут — Safe (колишній Gnosis Safe), і він віддає свій склад назовні двома безкоштовними view-функціями.

• getOwners() повертає масив адрес — у документації Safe це прямо описано як «Array of Safe owners», список підписантів.
• getThreshold() повертає число — мінімальну кількість підписів, потрібну для виконання транзакції.

Обидві читаються з будь-якої адреси Safe без газу: через вкладку Read Contract в експлорері або через cast call. Це займає хвилину й не потребує ні довіри до інтерфейсу протоколу, ні дозволу команди.

Що дивитися покроково:

1. Знайти адресу, яка стоїть в адмін-слоті проксі (попередній розділ), і переконатися, що це Safe.
2. Викликати getOwners() і записати список адрес — це ваш базовий знімок.
3. Викликати getThreshold() і записати число підписів. Схема «3 з 5» — це getOwners() довжиною 5 і getThreshold() = 3.
4. Перевірити, скільки підписантів публічно названі командою, а скільки — просто адреси.
5. Повторювати раз на місяць. Сенс має саме динаміка.

Три зміни, помітні лише під час порівняння з минулим знімком:

• кількість підписантів скорочується. Було 5, стало 2 — коло людей, здатних зупинити виведення коштів, звузилося;
• поріг падає до одиниці. getThreshold() = 1 означає, що мультипідпис більше не мультипідпис: будь-який із власників підписує транзакцію самотужки;
• іменних підписантів замінюють свіжі адреси без історії. Формально склад той самий, фактично — невідомо чий.

Важлива межа, щоб не плутати два різні ризики. Мультипідпис ламають і ззовні: підписантів обманюють соціальною інженерією та отримують їхні ключі — тоді суб’єкт дії сторонній, а команда постраждала. Тут ідеться про протилежне: команда змінює свої ж права сама, легальним викликом функції, і жодного зламу в цьому немає. Відрізнити одне від одного допомагає якраз комунікація — у другому випадку пояснень зазвичай не з’являється.

Скарбниця й токени: інсайдер LIBRA отримав монети за 20 хвилин

Третя спостережувана точка — рух токенів і грошей на адресах, пов’язаних із проєктом. Тут важливо одразу застерегти формулювання: ончейн видно дії та суми, а не наміри. «З адреси X 14 лютого виведено N токенів» — факт. «Команда вкрала» — юридична кваліфікація, яку дає суд або розслідування, а не спостерігач з експлорером.

Два кейси показують обидва кінці цієї шкали.

LIBRA, 14 лютого 2025 року. Розслідування блокчейн-аналітичної компанії TRM Labs фіксує: приблизно за двадцять хвилин до публічного анонсу одна адреса отримала мільйон токенів $LIBRA. Далі за даними того самого розслідування: протягом трьох годин після першого допису ціна впала приблизно на 89%, а від піку токен втратив понад 96%; із пулу Meteora адресами, потенційно пов’язаними з командою, виведено $7,8 млн у SOL, ще близько $90 млн у SOL та USDC осіло на консолідаційних адресах за пікової капіталізації близько $4,5 млрд. Cointelegraph незалежно оцінював обвал у 95% і втрату майже $4 млрд капіталізації — розбіжність в оцінках чесніше показати, ніж згладити.

Ключовий висновок із LIBRA для нашої теми незручний: препозиціювання інсайдера фізично не спостерігається заздалегідь. За двадцять хвилин до анонсу ця адреса нічим не відрізнялася від пересічного власника, а токен у мережі Solana існував лічені години. Ні мультипідпис, ні коміти, ні історія TVL тут не допомогли б — бо це не тихий вихід, а намір, вбудований до запуску. Схожа логіка працює й на старті звичайних проєктів: те, як і кому продавався токен, — окремий шар перевірки, і він розібраний у матеріалі про токенсейли ICO, IDO та IEO.

SafeMoon. Тут є не ончейн-картина, а вирок. За офіційним релізом IRS Criminal Investigation, CEO компанії Braden John Karony вводив інвесторів в оману, стверджуючи, що пули ліквідності SafeMoon «locked» і це захищає кошти від вилучення інсайдерами; фактично він і співучасники зберегли несанкціонований доступ і вивели токенів більш ніж на $9 млн, публічно заперечуючи володіння токеном. 10 лютого 2026 року його засуджено до 100 місяців в’язниці з форфейтом близько $7,5 млн у криптоактивах і двох об’єктів житлової нерухомості; винним його визнав суд присяжних ще в травні 2025 року.

Практичний сенс цього кейсу лише один: фраза «ліквідність заблокована» — не факт, а заява. Перевірювана версія того самого твердження виглядає інакше.

GitHub і соцмережі: тихий вихід видно в датах останніх комітів

Порада «подивіться їхній GitHub» марна, поки не сказано, що саме дивитися. Дивитися треба поле pushed_at — дату останнього пушу в кожен репозиторій організації. Воно віддається публічним API без авторизації:

1. Знайти організацію проєкту на GitHub (зазвичай указана в документації або у футері сайту).
2. Запитати https://api.github.com/orgs/<організація>/repos?per_page=100.
3. Відсортувати відповідь за полем pushed_at і подивитися на верхні 5–10 репозиторіїв.
4. Розділити їх на групи: контракти, фронтенд, інфраструктура, документація.
5. Зберегти дати. За місяць повторити й порівняти.

Що показує така перевірка на живому прикладі. В організації zerolend репозиторій фронтенду app.zerolend.xyz отримав пуш 27 серпня 2026 року — через пів року після того, як команда оголосила про згортання протоколу 17 лютого 2026 року; config.zerolend.xyz і legacy.zerolend.xyz оновлювалися 28 червня 2026 року. Тобто протокол публічно закривається, а код, через який люди забирають гроші, і далі лагодять.

Протилежна картина у HyperVault: 26 вересня 2025 року компанія PeckShield зафіксувала близько $3,6 млн аномальних відтоків — кошти пішли мостом із Hyperliquid в Ethereum, з них близько 752 ETH (приблизно $3 млн) було задепоновано в Tornado Cash, — і того самого дня офіційний акаунт в X виявився видаленим, а сайт недоступним. Тут зникли одночасно і гроші, і всі канали зв’язку.

Важливе застереження про темп розробки. Пауза в комітах сама собою означає не так багато: у зрілого протоколу контракти не переписуються щотижня, а свята, реліз-цикли й відпустки дають нормальні провали. Значущим сигналом пауза стає у двох випадках: коли зупиняється все одразу — і контракти, і фронтенд, і документація, — і коли вона збігається в часі зі змінами в правах або у скарбниці.

Комунікаційну частину розбирають схоже. Immunefi у своєму гайді перелічує вісім попереджувальних ознак: неправдиві заяви про аудит; велика кількість централізованих функцій, що дозволяють власнику рухати будь-які токени; зламаний сайт і мертві соцканали, команда не відповідає; підозріло висока дохідність; централізований незаблокований розподіл токена; слабкий юзкейс; масове відключення та бан користувачів із незручними запитаннями; спротив код-рев’ю та баунті-програмам.

Список корисний, але статичний — він описує стан. Для вже працюючого протоколу ті самі пункти треба читати як похідну за часом: не «канал мертвий», а «частота дописів упала втричі за квартал»; не «команда не відповідає», а «на технічні запитання відповідати перестали, на маркетингові відповідають»; не «спільноту придушують», а «модерація почала видаляти запитання про виведення коштів, чого раніше не робила».

П’ять протоколів 2025–2026: від піку TVL до нуля — від 0 до 40 днів

Далі — власний розрахунок, бо жоден розібраний конкурент зведеної арифметики щодо термінів не дає: там або переказ окремих історичних кейсів, або загальні поради.

Методика проста й відтворювана. Запит https://api.llama.fi/protocols на 30 серпня 2026 року віддає 8149 протоколів; фільтр за полем rugged: true залишає 116 записів. Обидва числа — знімок на дату, а не константа: реєстр накопичувальний і поповнюється щомісяця, тож під час повторного розрахунку вони будуть більшими. За кожним зі свіжих записів 2025–2026 років запитується https://api.llama.fi/protocol/<slug> — звідти беруться масив tvl[] (дата і значення), розмічені події hallmarks і дата лістингу listedAt. Усі дати й різниці пораховані кодом за сирим JSON, а не зняті очима з графіка.

Із цієї таблиці випливають два числа й один висновок.

Перше число — термін життя до піку: 37, 90, 91, 67 і 2 дні. Середнє — 57,4 дня, медіана — 67 днів. Для порівняння, CertiK на цілком іншій вибірці (40 інцидентів, 2020–2023 роки, інша методологія) дає середню тривалість 92 дні й медіану 57 днів. Вибірки невеликі, і метрики пораховані по-різному, тому коректне формулювання не «57 = 57», а таке: дві незалежні вибірки, рознесені на п’ять років, дають один і той самий порядок величини — два-три місяці від старту до кінця. Стійкість закономірності в часі важливіша за збіг знаків після коми.

Друге число — термін від піку до нуля: 1, 40, 1, 0 і 2 дні. У трьох протоколів із п’яти гроші зникли наступного дня після максимуму або того самого дня.

Висновок, заради якого рахувалося. Класична порада «стежте за динамікою TVL» на цих даних не працює як ранній сигнал: TVL — це результат події, а не її провісник. Єдиний виняток у вибірці — Molecular, де між піком і офіційною позначкою минуло 12 днів, а до нуля — 40; але й це вікно вузьке на тлі 90 днів життя протоколу. Спостерігати треба за тим, що змінюється до піку: правами, складом мультипідпису, рухом скарбниці та активністю репозиторіїв.

ZeroLend втратив 98% TVL — і це не rug pull

Найдорожча помилка під час використання всього переліченого — сприйняти чесне закриття за втечу. Тому контрольний приклад, порахований за тими самими даними того самого трекера.

ZeroLend досяг піку TVL $358 718 599 8 листопада 2024 року. На 17 лютого 2026 року, коли команда оголосила про згортання, у протоколі залишалося $6 631 730. Падіння — (358 718 599 − 6 631 730) / 358 718 599 × 100 = 98,15% за 466 днів. Масштаб просідання зіставний із «жорсткими» кейсами з таблиці вище, а поле rugged у ZeroLend в API дорівнює null — на відміну від true в усіх п’яти протоколів вище.

Різниця не в цифрах падіння, а в поведінці.

Читається це так: сигнал — не падіння, а мовчання. Протокол може чесно закритися, втративши майже весь TVL, і при цьому до останнього лагодити інтерфейс, через який люди забирають гроші. І навпаки — протокол може виглядати нормально за графіком рівно до того дня, коли графіка більше немає.

Звідси практичне правило для спостерігача: побачивши різке падіння TVL, насамперед шукайте пояснення, а не біжіть до висновку про шахрайство. Є публічна заява, названі причини, триває робота над виведенням коштів — це одна ситуація. Заяви немає, канали мовчать, репозиторії завмерли — інша.

Honeypot і checker-інструменти: що вони ловлять, а що ні

Окремий клас — скам, який був скамом із нульового дня. Тут намір вбудований у код: контракт продає токен покупцеві, але не дає продати його назад (honeypot), або містить функцію необмеженої емісії, або комісію на продаж у 99%. Такі речі ловляться статичним аналізом, і під них є готові інструменти.

Масштаб цього шару варто розуміти до того, як обговорювати інструменти. За зведенням deepstrike.io, на майданчику Pump.fun із понад 7 млн токенів, випущених із січня 2024 по березень 2025 року, 98,6% опустилися нижче порога ліквідності в $1000. На Raydium близько 93% із 388 000 пулів показують ознаки «soft rug». Академічна праця SoK за своїм реконструйованим датасетом оцінює підтверджені втрати в $171 713 065, з яких найбільша категорія — Token Distribution — дає 35% ($60 587 545). Простіше кажучи, у мемкоїнів (meme coin) базове очікування — обнулення, і це статистична норма майданчика, а не аномалія.

Тепер про інструменти та їхні чесно заявлені межі.

Зверніть увагу на формулювання: це не наша критика, а власні застереження сервісів. honeypot.is прямо попереджає, що відсутність пастки сьогодні не означає її відсутності завтра. RugDoc сам обмежує предмет перевірки «жорстким» код-рагом.

Звідси неприємний, але корисний висновок: готового інструмента під завдання цього розбору не існує. Усі три сканери відповідають на запитання «чи може цей код украсти гроші просто зараз». Жоден не відповідає на запитання «чи змінилося щось у правах, складі підписантів і активності команди з минулого місяця». Друге запитання закривається лише ручною перевіркою через API та експлорер — і повторенням цієї перевірки в часі.

Чого не покажуть права, мультипідпис і коміти: залишкові ризики

Корисно розуміти межі методу, інакше він перетворюється на хибне відчуття контролю.

Права змінюються легально й без вашої участі. renounceOwnership() і transferOwnership() — звичайні функції стандартної бібліотеки, їхній виклик не потребує згоди вкладників і не супроводжується голосуванням. Перевірка, зроблена до депозиту, не захищає від зміни, зробленої після нього. Саме тому єдина робоча форма — повторюваний знімок, а не разовий аудит.

Мультипідпис може легально згорнутися до одного ключа. Жоден протокол не зобов’язаний підтримувати склад підписантів і поріг. getThreshold() покаже значення 1, але покаже вже за фактом — подія стається раніше, ніж про неї дізнаються вкладники.

Спостереження за TVL систематично запізнюється. У HyperVault, Quantus Lend і Fisclend Finance між піком і обнуленням минуло 0–1 день. Якщо графіки — ваш єдиний інструмент, ви дізнаєтеся про подію після неї.

Інсайдерське препозиціювання в принципі не спостерігається заздалегідь. Адреса, яка отримала 1 млн токенів LIBRA за двадцять хвилин до анонсу, до того моменту нічим не вирізнялася. Проти такого класу дій діагностика за правами, комітами та скарбницею безсила — він належить до скаму з нульового дня, а не до тихого виходу.

Заяви команди юридично не еквівалентні фактам. Справа SafeMoon підтверджує це вироком: слова «ліквідність заблокована» лунали публічно за збереження прихованого доступу. Будь-яке твердження про безпеку має цінність лише у вигляді адреси контракту, яку можна відкрити.

Готові сканери цього завдання не розв’язують і самі про це пишуть: honeypot.is застерігає, що перевірка чинна лише на поточний момент, RugDoc обмежує себе «жорстким» код-рагом. Автоматизація тут закінчується на межі коду.

І зворотний бік, про який забувають частіше: хибне спрацювання теж коштує грошей. Чесне згортання протоколу за графіком TVL виглядає приблизно так само, як утеча, — випадок ZeroLend показує це кількісно. Помилка в цей бік не така помітна, але вона реальна: паніка за однією ознакою виводить людину з працюючого протоколу на комісіях і проковзуванні.

Чек-лист: що перевіряти, поки протокол ще працює

Зведення всього викладеного у форму, яку можна пройти за 20–30 хвилин і повторювати раз на місяць. Сенс — не в разовому проходженні, а в наявності збереженого знімка, з яким порівнюється наступний.

Червоний прапорець тут один і той самий за всіма дев’ятьма рядками: зміна без пояснення. Одиночний пункт майже ніколи не означає підготовку до виходу — у кожного є законні причини: мультипідпис скорочують, коли йде співробітник, права передають у DAO, коміти зупиняються на святах, канали затихають між релізами. Значущість дає збіг кількох пунктів в одному часовому вікні за цілковитого мовчання з боку команди.

Що робити за такого збігу — питання особистого ризик-менеджменту, і рішення тут за вами. Технічно важлива одна річ, що не залежить від діагнозу протоколу: навіть після виведення коштів у контракту зазвичай залишається виданий вами дозвіл розпоряджатися токенами. Як це влаштовано і як дозволи відкликати, розібрано в матеріалі про approvals та їх відкликання; загальна гігієна адреси, з якої ви взаємодієте з DeFi, — у розборі ризиків гарячого гаманця.

Застаріє в цьому матеріалі першим усе числове: TVL, суми й дати за конкретними протоколами перераховуються щодня, а список свіжих rugged-записів у DeFiLlama поповнюється щомісяця. Технічний шар змінюється значно повільніше: слоти EIP-1967 зафіксовані специфікацією, сигнатури getOwners/getThreshold і поведінка renounceOwnership/transferOwnership описані в документації й не змінювалися роками.

FAQ

Чи означає згортання мультипідпису до одного ключа, що протокол точно готує rug pull? Ні. getThreshold() = 1 — це факт про права, а не про наміри. Законні причини трапляються: підписант пішов із команди, ключ загублено, триває міграція на новий Safe. Тривожним цей факт стає у зв’язці: поріг упав, пояснення немає, водночас завмерли репозиторії або змінилася адреса в admin-слоті проксі. Одиночна ознака — привід перечитати решту вісім пунктів чек-листа, а не висновок.

Чи можна довіряти проєкту, якщо ліквідність офіційно «заблокована»? Сама собою заява нічого не гарантує. Справа CEO SafeMoon — юридично підтверджений приклад: він публічно називав пули «locked», зберігаючи несанкціонований доступ, і 10 лютого 2026 року отримав 100 місяців в’язниці. Перевірювана версія заяви — це адреса контракту локу, сума LP-токенів у ньому та дата розблокування, які читаються в експлорері. Немає адреси контракту — немає й перевірки.

Чим honeypot-токен відрізняється від повільного виходу команди вже працюючого протоколу? Honeypot — це властивість коду: контракт дозволяє купити токен, але не дозволяє його продати, і намір вбудовано до запуску. Таке ловиться статичним аналізом за хвилину, до першого депозиту. Тихий вихід — це послідовність дій у часі на нормальному коді: права переводяться, підписанти скорочуються, коміти зупиняються. Жоден сканер контрактів цієї динаміки не відстежує — сервіси прямо пишуть про це обмеження.

Якщо коміти в GitHub зупинилися на місяць — це вже привід для тривоги? Саме собою — ні. У зрілого протоколу контракти тижнями не чіпають, і це норма. Значущими паузи стають у двох випадках: зупинилося все одразу — контракти, фронтенд і документація; або пауза збіглася в часі зі зміною прав чи рухом скарбниці. Корисний контрприклад — ZeroLend: протокол публічно згортався, але фронтенд отримував пуш ще 27 серпня 2026 року, через пів року після анонсу.

Що робити, якщо я помітив одразу кілька ознак виходу команди? Спершу відокремити факт від здогаду: виписати, що саме змінилося, з датами й адресами. Потім пошукати пояснення в офіційних каналах — у більшості змін воно є. Далі це питання вашого ризик-менеджменту й прийнятного для вас розміру втрати, а не універсальної відповіді. Технічно врахуйте, що видані протоколу approvals діють і після виведення коштів, тому їх відкликання — окрема дія.