Як оцінити ризики проекту Web3: практичний контрольний список для користувача

In Web3, users often hold their own keys and sign transactions directly. A useful review therefore starts not with “How much can I earn?” but with: What am I signing, which code will gain access to my assets, and who can change the rules?

Жоден контрольний список не може довести безпечність проєкту. Його мета — виявити невідомі фактори, зіставити твердження з доказами, які можна перевірити, і обмежити потенційну шкоду.

Ця стаття має виключно освітню мету й не є фінансовою, інвестиційною або юридичною консультацією. Транзакції Web3 можуть призвести до повної втрати переказаних активів.

1. Перевірте джерело

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

Stop signal: a site asks you to “synchronize,” “validate,” or “restore” a wallet by entering secret words.

2. Підтвердьте мережу й актив

Перед будь-яким переказом зафіксуйте:

• мережа;
• адреса контракту токена;
• адреса отримувача або викликаного контракту;
• сума;
• актив для сплати комісії;
• очікувана дія.

A name such as USDT does not uniquely identify a token. Verify the full token contract address. The same 0x… address format can be used on different EVM networks, but assets and state remain network-specific.

Stop signal: the project gives a ticker but does not publish the network and token address.

3. Перевірте розгорнутий код

У блокчейн-оглядачі:

• знайти контракт за офіційною адресою;
• перевірити верифікацію вихідного коду;
• визначити, чи є він proxy;
• відкрити поточну implementation;
• зіставити всі адреси з документацією проєкту.

On BscScan, Exact Match means published source and constructor parameters were matched to deployed bytecode. This improves transparency but is not a security assessment.

Stop signal: no address is published, source is unverified, and the project still claims “full transparency” without explanation.

4. Зрозумійте адміністративні повноваження

Шукайте такі ролі та функції:

• owner, admin, operator і upgrader;
• призупинення й поновлення;
• зміни комісій або лімітів;
• зміни пов’язаних адрес;
• карбування токенів;
• виведення активів;
• оновлення implementation;
• блокування адреси.

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

Stop signal: one address holds critical powers while the project claims that nobody can change anything.

5. Правильно читайте аудит

Перевірте, чи:

• звіт опубліковано аудитором;
• репозиторій і хеш commit зазначено;
• чинний контракт входить до обсягу перевірки;
• звіт охоплює поточну implementation;
• залишилися невиправлені зауваження;
• виправлення повторно протестовано;
• важливі компоненти було виключено.

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

Stop signal: there is an “Audited” badge but no report or reviewed code version.

6. Порівняйте заяви з ончейн-поведінкою

Перевірте кілька транзакцій на предмет:

• статус;
• Від і To / Interacted With;
• Переміщення BEP-20;
• внутрішні виклики;
• журнали;
• комісії;
• зміни балансів і стану контракту.

Compare the actual path of funds with the published architecture. Do not draw a system-wide conclusion from one demonstration transaction. Успіх means the code executed without reverting; it does not mean the operation was safe or beneficial.

Stop signal: observable fund flows differ from the stated process and no clear explanation is provided.

7. Відокремлюйте активи від зобов’язань

Видимий баланс адреси — лише один факт. Запитайте:

• чи розкрито всі відповідні адреси;
• хто контролює активи;
• чи можна їх вивести;
• які зобов’язання існують перед іншими користувачами;
• як визначається зовнішня ціна;
• чи залежить доступ від мосту, DEX, оракула або контрагента.

Великий баланс токенів не доводить наявності ліквідності. Велика кількість одиниць може мати низьку вартість, яку реально можна отримати.

Stop signal: one address balance is presented as proof of solvency without disclosing obligations or control rights.

8. Поясніть економічну модель простою мовою

Знайдіть чіткі відповіді на запитання:

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

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

Stop signal: a fixed outcome is promised without a verifiable source of funds or loss scenario.

9. Контролюйте підписи та дозволи на використання токенів

Перед підтвердженням перевірте, що показує гаманець:

• мережа;
• викликана адреса;
• функція або зрозумілий опис дії;
• вартість нативного токена;
• кількість токенів і розмір allowance;
• очікувані зміни активів.

An approve call does not immediately transfer a token. It may authorize a spender contract to call transferFrom up to an allowance. An unlimited allowance increases potential loss if the spender is compromised or flawed.

Відхиліть підпис, якщо дані незрозумілі або адреса відрізняється від перевіреної. Після використання перегляньте й відкличте непотрібні дозволи за допомогою надійного інструмента.

Stop signal: you are pressured to sign unreadable data or told that a signature “does nothing.”

10. Урахуйте ризики поза блокчейном

Навіть ретельно перевірений код не може запобігти кожному:

• компрометація вебсайту або DNS;
• шкідливе розширення браузера;
• викрадення ключа;
• скомпрометований обліковий запис проєкту;
• збій backend;
• атака із застосуванням соціальної інженерії;
• юридичне обмеження;
• збій підтримки або операційний збій.

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

11. Обмежте можливі збитки

Навіть після завершення перевірки:

• починайте з найменшої практичної тестової суми;
• використовувати окремий гаманець для незнайомих dApps;
• не зберігати всі активи в підключеному гаманці;
• ніколи не підписувати під тиском часу;
• зберігати хеші транзакцій та адреси;
• регулярно перевіряти allowances токенів;
• установити максимальну суму під ризиком, повна втрата якої залишатиметься прийнятною.

Офіційні рекомендації Solidity з безпеки радять обмежувати обсяг активів у контракті: якщо в коді, компіляторі або платформі є помилка, обмеження експозиції може зменшити втрати.

Контрольний список перед транзакцією

Answer yes, no, or unknown:

• Я перевірив домен.
• Я знаю точну мережу.
• Я перевірив адресу контракту токена.
• Я перевірив адресу викликаного контракту.
• Я знаю статус верифікації вихідного коду.
• Я перевірив proxy та implementation.
• Я розумію повноваження адміністраторів.
• Аудит відповідає чинній версії.
• Я перевірив реальні транзакції.
• Я розумію джерело виплат і сценарії втрат.
• Я розумію запит на підпис.
• Allowance має розумне обмеження.
• Я врахував ризики frontend, ключів і юридичні ризики.
• Тестова сума не може завдати критичної шкоди.

For a critical question, unknown is not a neutral answer—it is an unassessed risk. Pausing for verification is usually cheaper than an irreversible transaction.

Запитання, які має поставити обачний користувач

Is a project safe if its code is open and audited?
No. Those are useful signals, but unknown bugs and administrative, operational, economic, and external risks remain.

If assets are visible on-chain, can they definitely be returned?
No. Return depends on code, current state, control rights, and external dependencies.

Does a small successful test prove a larger transaction will work?
No. It tests one path at one moment. Limits, liquidity, state, and implementation may later differ.

What if I do not understand the signature?
Reject it. Identify the function, called address, asset changes, and permissions before trying again.

Джерела та додаткові матеріали

1. Solidity Documentation — Питання безпеки
2. Ethereum.org — Безпека смартконтрактів
3. Ethereum.org — Тестування смартконтрактів
4. BscScan Information Center — Перегляд транзакцій
5. BscScan Information Center — Типи верифікації контрактів
6. BscScan Information Center — Що таке адреса?
7. OpenZeppelin Docs — Шаблон оновлення Proxy