DeFi-протоколу потрібне відкладене виконання адміністративних дій. Без таймлок-контракту аудитори забракують проект — це базова гарантія безпеки. Після серії зломів DeFi-платформ на початку десятиліття таймлок став обов'язковою вимогою для лістингу на централізованих біржах. Ми розробляємо такі контракти під ключ: від простої інтеграції OpenZeppelin до кастомних рішень з гнучкою затримкою та контрольними ролями. За 5 років роботи ми реалізували 10+ DeFi-протоколів з різною архітектурою управління. Команда має 7+ років досвіду в розробці смарт-контрактів та провела аудит для 15 проектів.
Compound Finance ввів таймлок-контракт у мейнстрім. Їх Timelock.sol — дводенна затримка перед виконанням будь-яких змін протоколу — став стандартом після того, як кілька DeFi-протоколів втратили кошти через миттєві admin-операції. Зараз таймлок — це базова вимога будь-якого аудитора та перше питання на лістингу.
Як налаштувати таймлок-контракт за 5 кроків
- Визначте операції, що потребують затримки (зміна комісій, зміна owner, оновлення контрактів).
- Виберіть затримку для кожної операції (мін. 48 годин для production).
- Виберіть платформу: OpenZeppelin TimelockController або кастомний контракт.
- Інтегруйте з Governor або мультисигом.
- Напишіть тести та проведіть аудит.
OpenZeppelin TimelockController дозволяє налаштувати таймлок у 2 рази швидше, ніж написання кастомного рішення, і перевірений тисячами проектів.
Як ми реалізуємо таймлок-контракти?
Ми використовуємо два підходи — вибір залежить від архітектури протоколу та потреб в управлінні.
| Характеристика | OpenZeppelin TimelockController | Кастомний таймлок |
|---|---|---|
| Готовність | Миттєво, обширні тести | Пишеться під задачу, 2–3 дні |
| Гнучкість затримок | Одна затримка на всі операції | Різні затримки для різних ролей/функцій |
| Інтеграція з Governor | Вбудована (GovernorTimelockControl) | Ручне налаштування |
| Екстрений bypass | Немає вбудованого | Реалізується через Pausable + окрема роль |
| Аудит | Багаторазово перевірений | Потребує окремого аудиту |
Для нового протоколу ми рекомендуємо починати з TimelockController — він покриває 80% випадків. Кастомний таймлок виправданий, коли потрібні різні затримки для зміни fee (48 годин) і зміни admin (7 днів), або інтеграція з мультисигом без Governor.
Деталі реалізації bypass-механізму
В екстрених випадках, наприклад при виявленні вразливості, використовується Pausable контракт з окремою роллю. Паузатор тільки зупиняє протокол, не змінюючи логіку. Важливо, щоб bypass був обмежений: він не повинен дозволяти виконувати звичайні admin-операції поза чергою.Чому важлива мінімальна затримка?
48 годин — мінімум для production-протоколу. Менше — користувачі не встигають вивести ліквідність або відкликати схвалення. Стандарт DeFi-протоколів: 24–72 години для параметрів, 7 днів для зміни owner. Ми завжди перевіряємо, щоб затримка була достатньою: клієнти часто просять 1 годину з міркувань зручності — це груба помилка.
uint256 public constant MIN_DELAY = 2 days; uint256 public constant MAX_DELAY = 30 days; Критичні деталі реалізації
Запобігання replay-атакам
Кожна операція ідентифікується хешем параметрів плюс salt. Без salt одна й та ж операція (наприклад, setFee(100)) може бути поставлена в чергу тільки один раз. З salt — будь-яку кількість разів. Переконуємось, що клієнт розуміє цю поведінку.
Екстрені функції
Майже завжди потрібен bypass для критичних ситуацій — якщо знайдена вразливість, не можна чекати 48 годин. Паузатор (Pausable) з окремою роллю — стандартне рішення. Але паузатор, у свою чергу, повинен бути обмежений: він тільки зупиняє, не змінює логіку.
Базові налаштування таймлоку
| Параметр | Рекомендоване значення |
|---|---|
| Мінімальна затримка | 48 годин |
| Максимальна затримка | 30 днів |
| Роль Proposer | Адреса губернатора |
| Роль Executor | Будь-хто (відкритий) |
| Роль Canceller | Мультисиг |
Що входить в роботу?
- Аналіз архітектури протоколу та вимог до затримок
- Вибір та налаштування OpenZeppelin TimelockController або написання кастомного контракту
- Інтеграція з існуючим Governor або мультисигом
- Написання unit-тестів (coverage >95%) та fuzzing-тестів
- Публікація з верифікацією на Etherscan
- Документація для команди (опис ролей, процедур скасування)
- Підтримка протягом 30 днів після деплою
Інтеграція з Governor
Для повноцінного on-chain управління ланцюжок виглядає так: Governor → TimelockController → Protocol. Голосування проходить в Governor, переможна пропозиція ставиться в чергу TimelockController, після затримки виконується. Головна помилка — дати TimelockController прямий admin-доступ до протоколу, минаючи Governor. Це робить голосування декоративним.
Строки
Деплой TimelockController з конфігурацією ролей — 1 день. Кастомний таймлок з кількома рівнями затримки — 2–3 дні. Інтеграція з існуючим Governor — 1–2 дні залежно від архітектури протоколу. Тести та документація включені в оцінку.
Зв'яжіться з нами для оцінки вашого проекту — ми підберемо оптимальну архітектуру таймлок-контракту та гарантуємо проходження аудиту. Замовте розробку таймлок-контракту для вашого протоколу вже сьогодні.