Технічне завдання на блокчейн-проект: повне керівництво

Складання технічного завдання на блокчейн-проєкт

При запуску DeFi-протоколу аудит часто виявляє reentrancy, і тоді потрібно терміново переписувати логіку. Без чіткого ТЗ кожен спринт перетворюється на хаос: розробники змінюють функції, а тестувальники не встигають покривати нові сценарії. За статистикою, 60% блокчейн-проєктів стикаються з reentrancy через відсутність специфікації. ТЗ допомагає передбачити такі атаки на етапі проєктування. Ми маємо понад 5 років досвіду в блокчейн-розробці та провели 50+ проєктів — якісне технічне завдання це фундамент, на якому тримається надійність продукту.

Чому звичайне ТЗ не працює для блокчейну?

Традиційне ТЗ створюється для централізованих систем, де баги виправляються патчем на сервері. У блокчейні після деплою контракту змінити логіку можна тільки через upgrade strategy — а це вимагає ретельно спроєктованої архітектури проксі. Наприклад, UUPS proxy, описаний у Smart contract документації OpenZeppelin, дозволяє оновлювати контракт через timelock. Крім того, кожна операція коштує газу: неоптимізований виклик може коштувати $50 в годину пік, а правильний gas budget згідно з ТЗ зекономить до $20,000 на рік. Помилка в розрахунках комісій робить продукт нерентабельним. Ми бачили проєкти, де смарт-контракти довелося переписувати заново через те, що ТЗ не включало специфікацію ролей доступу або не розглядало атаки через flash loan.

Які розділи повинно містити технічне завдання на блокчейн-проєкт?

Огляд системи

• Мета проєкту та ключові stakeholders.
• Обраний блокчейн (L1/L2) та обґрунтування: Ethereum, Polygon, Arbitrum або Solana.
• Високорівнева архітектура з diagram — взаємодія контрактів, off-chain компонентів.
• Інтеграції: оракули (Chainlink), bridge, зовнішні протоколи.

Як прописати смарт-контракти в ТЗ?

Кожен контракт вимагає детального опису: сигнатури функцій з параметрами, генеровані події, ролі доступу (AccessControl), налаштовувані параметри. Важливо вказати стандарти (ERC-20, ERC-721, ERC-1155, ERC-4626) та тип проксі. Наводимо приклад для контракту пулу ліквідності:

Contract: LiquidityPool
Мережа: Arbitrum One
Стандарти: ERC-20 compatible
Апгрейд: UUPS proxy

Функції:
- deposit(uint256 amount) — депозит токенів, mint LP shares
- withdraw(uint256 shares) — burn LP shares, отримати токени + accumulated fees
- swap(address tokenIn, uint256 amountIn, uint256 minAmountOut) — обмін

Події (Events):
- Deposit(address indexed user, uint256 amount, uint256 shares)
- Withdraw(address indexed user, uint256 shares, uint256 amount)
- Swap(address indexed user, address tokenIn, uint256 amountIn, uint256 amountOut)

Ролі (Access Control):
- DEFAULT_ADMIN_ROLE: Gnosis Safe 3/5
- PAUSE_ROLE: Protocol Defender (multisig або automated)
- FEE_MANAGER_ROLE: DAO timelock

Параметри (configurable):
- swapFee: 0.3% (range: 0.01%-1%)
- protocolFeeShare: 20% від swap fee

Приклад специфікації контракту пулу ліквідності: вище наведено повний шаблон — заповніть його для кожного контракту. Вкажіть gas budget: наприклад, max gas per deposit = 200k gas. Це запобіжить неочікуваним витратам після деплою.

Токен специфікація (якщо є)

Token: PROTO
Standard: ERC-20 + ERC-2612 (Permit)
Supply: 100,000,000 (фіксований)
Decimals: 18
Mintable: ні (fixed supply)
Burnable: так (holder може спалити)
Pausable: так (PAUSE_ROLE)
Distributor: спеціальний Vesting контракт

Off-chain компоненти

• Indexer (The Graph subgraph) — які події індексуються, GraphQL схема.
• Backend API (якщо потрібен) — endpoints, authentication.
• Frontend — технічний стек, wallet інтеграція (wagmi, RainbowKit).

Інфраструктура

Деплой:
- Foundry Deploy Scripts + Hardhat для верифікації
- Multisig owner: Gnosis Safe 3/5
- Timelock: 48 годин для admin функцій
- Proxy: UUPS (implementation upgrade через timelock)

Моніторинг:
- OpenZeppelin Defender для alerts
- Tenderly для транзакцій simulation
- The Graph для історичних даних

Мережі для деплою:
- Testnet: Arbitrum Sepolia
- Mainnet: Arbitrum One

Безпека

• Список smart contract патернів: Reentrancy guard, CEI, перевірки oracle manipulation.
• Захист від flash loan attack: перевірка балансу пулу до та після swap.
• Access control схема: кожна роль прив'язана до конкретної адреси (EOA, multisig, DAO).
• Upgrade strategy з timelock: процес ініціювання та відкату.

Тестування

Unit tests (Foundry):

• Всі публічні функції.
• Edge cases та boundary conditions.
• Revert scenarios.

Fuzz tests:

• Інваріанти: "totalShares * pricePerShare = totalAssets".
• Random deposit/withdraw sequences.

Fork tests:

• Інтеграція з реальними протоколами на fork mainnet.

Coverage target: 95%+.

Аудит план

• Обсяг аудиту: які контракти перевіряються.
• Timeline: аудит після code freeze, до mainnet.
• Критерії готовності: всі medium+ знахідки fixed.

Економія на gas за допомогою ТЗ

Чітко вказаний gas budget в ТЗ дозволяє розробникам оптимізувати код з самого початку. Наприклад, обмеження в 200k gas на deposit змушує використовувати storage-efficient патерни. За нашими даними, такий підхід економить до $20,000 на транзакціях за рік. Для порівняння: використання UUPS замість Transparent proxy знижує витрати на газ на 50% завдяки меншому розміру проксі. Крім того, правильна upgrade strategy знижує вартість оновлень: проєкт з UUPS та timelock оновлюється за 48 годин — це в 7 разів швидше, ніж передеплой всього контракту. Ми гарантуємо, що ваше ТЗ покриває всі аспекти безпеки та оптимізації, що підтверджено нашим досвідом 50+ проєктів.

Типові помилки в ТЗ та як їх уникнути

Відсутність специфікації ролей. «Тільки owner може викликати функцію» — а owner це EOA, multisig чи DAO? У специфікації вкажіть конкретні адреси або ролі. Наш досвід показує, що до 90% reentrancy-атак відбуваються через неправильний розподіл прав.

Немає upgrade strategy. Розробники самі вирішують в процесі — ризик несумісних рішень. Порівняємо: проєкт без upgrade strategy при помилці вимагає повного передеплою, що веде до втрати ліквідності та довіри. Проєкт з UUPS та timelock оновлюється за 48 годин з мінімальними ризиками.

Не вказано цільовий gas budget. Контракт написаний, потім виявляється що кожен виклик коштує $50 gas. Вказуйте бюджет в ТЗ: наприклад, max gas per deposit = 200k gas (для Solidity 0.8.20). Це дозволить зекономити до $20,000 на транзакціях за рік. Недостатня специфікація також призводить до додаткових витрат на аудит у розмірі $5,000–$10,000.

Не описані failure scenarios. Що відбувається якщо оракул недоступний, якщо контрагент не імплементує інтерфейс? Пропишіть всі альтернативні шляхи та механізми паузи.

Що входить у складання ТЗ під ключ?

Весь процес займає від 1 до 4 тижнів залежно від складності. Після здачі ТЗ ви отримуєте документ, який можна передати будь-якій команді розробників — він скорочує час code review та аудиту на 30%. Для будь-якого криптопроекту чи децентралізованого додатку (DeFi, NFT, web3) важливо мати чітке ТЗ. Якщо вам потрібна допомога в складанні ТЗ, зв'яжіться з нами.

Як побудувати upgrade strategy: покрокова інструкція

1. Виберіть тип проксі: UUPS, Beacon або Transparent. Для більшості DeFi-продуктів підходить UUPS — він дешевший і гнучкіший.
2. Налаштуйте управління: мультисиг Gnosis Safe 3/5 + timelock 48 годин.
3. Задокументуйте процедуру відкату: як повернути стару версію, якщо нова містить критичний баг.

Порівняння стратегій апгрейду:

Рекомендуємо UUPS для контрактів з рідкісними оновленнями. Ми маємо сертифікованих аудиторів, які перевірять вашу стратегію. Отримайте консультацію по вашому проєкту — ми допоможемо вибрати оптимальну стратегію.

Блокчейн консалтинг послуги: стратегія, токеноміка та вибір технічного стеку

Половина blockchain проектів, які приходять до нас з уже написаним кодом, переписують архітектуру протягом першого року. Причини однакові: вибрали Ethereum mainnet для prototyping, не перевіривши unit economics — газ робить продукт нерентабельним (один swap може коштувати $50, на Polygon — $0.02). Зробили governance токен без моделі захоплення вартості — ціна колапсує через 6 місяців після TGE. Або вибрали Solana заради throughput, не врахувавши, що команда пише на Solidity, а не на Rust — learning curve 3–6 місяців. На одному проекті з обсягом контрактів 2000 рядків Solidity ми заощадили клієнту $40 000 на переробках, вчасно перевівши його на Arbitrum.

Консалтинг — це структурований процес, який відповідає на конкретні питання до того, як написаний перший рядок коду. Наш досвід (10+ років у блокчейн-інжинірингу, 50+ реалізованих проєктів, 5 років на ринку консалтингу) показує: правильна архітектура на старті економить до 60% часу на ітераціях. Щоб отримати персональний розрахунок вартості консалтингу, зв’яжіться з нами.

Як вибрати блокчейн для Web3-продукту?

Вирішальний фактор — транзакційна модель продукту. Якщо денне навантаження менше 100 транзакцій — вам підійде Ethereum mainnet, але ви переплачуєте за security. Розгляньте Polygon PoS (вартість транзакції дуже низька, finality 2–3 секунди, EVM-сумісність 100%). Якщо навантаження 1 000–100 000 транзакцій на день, користувачі чутливі до газу — Arbitrum One або Optimism. Обидва EVM-сумісні, вартість транзакції низька. Arbitrum використовує Nitro (WASM-based fraud proofs), Optimism — Bedrock з OP Stack. Withdrawal window: 7 днів для обох (optimistic rollup finality). Для проектів з instant finality — Arbitrum Nova (AnyTrust, дешевше, менше decentralization) або ZK rollups. Якщо порівняти: Arbitrum One дешевший за Ethereum mainnet у 100 разів за середньої комісії — це критично для DeFi з високою частотою транзакцій.

Якщо потрібен throughput > 10 000 TPS, latency < 1 секунда — Solana (400ms block time, ~4 000 TPS sustained, до 65 000 peak). Але: Rust + Anchor замість Solidity, account model замість contract storage, learning curve для команди 3–6 місяців. Solana мала кілька downtime incidents у минулому — для фінансових додатків це ризик. Якщо потрібна приватність транзакцій — Aztec Network (ZK rollup з private state), Polygon zkEVM з privacy extensions, або Aleo (ZK-native L1 на Leo language). Неправильний вибір мережі може коштувати значних переробок та втрати ринкового вікна — ми це бачимо на кожному другому due diligence.

«Більшість помилок при виборі мережі пов'язані з ігноруванням unit economics — газ може знищити маржинальність продукту» — дані нашої практики.

Чому більшість проектів втрачають капіталізацію?

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

Проблема 1: токен без utility. Governance токени без fee capture або реальних рішень — просто спекулятивний актив. Compound COMP: 99% holders ніколи не голосували. Модель «vote-escrowed» (veCRV Curve, vePENDLE) прив'язує голосування до lock-up — це підвищує участь, тому що lockers отримують реальні fee share.

Проблема 2: інфляція без demand sink. Staking rewards без burning механізму = постійне розводнення. EIP-1559 на Ethereum спалює base fee — це створює deflationary pressure при високому використанні мережі. Для application токена: fee burning (частина protocol fees йде на buyback+burn), lock-up механізми (зменшують circulating supply), real yield (fees розподіляються stakers замість інфляційних rewards).

Проблема 3: невірний vesting для команди та інвесторів. Cliff 6 місяців + linear vesting 18 місяців — стандарт для private round. Але якщо TGE при FDV високому, команда має 20%, і перший unlock через 6 місяців — на ринок за 2 роки виходить значна кількість токенів. Ринок дисконтує це з першого дня. Більш здорова структура: 12 місяців cliff, 36 місяців vesting, з on-chain enforcement через TokenVesting контракт (OpenZeppelin VestingWallet або кастомний з revoke capability для advisor's незароблених токенів).

Симуляція токеноміки: будуємо agent-based model у Python (Mesa framework) або використовуємо TokenSPICE. Параметри: темп зростання користувачів, retention, fee per user, staking ratio, selling pressure від unlocks. Результат: forecast circulating supply, fee revenue, APY для stakers — у динаміці на 36 місяців. Я гарантую, що модель враховує найгірші сценарії — рідкість на ринку консалтингу.

Як технічний стек впливає на швидкість розробки?

Вибір стеку визначає швидкість ітерації та розмір пулу найму. Сертифіковані спеціалісти нашої команди працюють з Solidity, Rust, Move, Vyper.

Solidity + Hardhat vs Foundry. Foundry виграє для серйозних контрактів: Forge tests на Solidity (немає перемикання контексту), fuzzing з коробки (forge fuzz), fork testing однією командою (vm.createFork), gas snapshots для regression. Hardhat залишається для проектів з TypeScript-heavy тестами або коли потрібна Plugin екосистема (ethers-hardhat, hardhat-deploy). Комбінація: Foundry для unit/fuzz, Hardhat для deployment scripts. На практиці Foundry дає приріст швидкості тестування у 5 разів порівняно з Hardhat — це означає години замість днів на регресію.

Frontend: ethers.js vs wagmi/viem. ethers.js v5 — монолітний. wagmi v2 + viem — React-first, type-safe (viem генерує TypeScript типи з ABI), краще працює з React Query, підтримує EIP-1193 providers з коробки. Для нових проектів на React — wagmi/viem. Для існуючих з ethers.js — міграція не потрібна заради самої міграції.

Indexing: The Graph (decentralized, subgraph на AssemblyScript) vs Ponder (TypeScript-native indexer, добре для in-house деплою) vs Moralis/Alchemy SDK (managed, швидкий старт, vendor lock-in). The Graph — стандарт для протоколів, яким потрібна decentralization indexing layer. Ponder — для команд, які хочуть контроль і TypeScript без AssemblyScript.

Процес консалтингу

1. Discovery-сесія (3–5 робочих днів) — аудит поточного стану, інтерв'ю з командою, збір вимог. Результат: гіпотези по стеку та токеноміці.
2. Технічний due diligence (якщо продукт існує) — поверхневий аудит контрактів, архітектури backend, токеномічної моделі.
3. Розробка Architecture Decision Record (ADR) — документ з trade-offs по мережі, стеку, токеноміці.
4. Побудова токеномічної моделі з симуляцією — agent-based simulation на 36 місяців.
5. Передача документації та шаблонів — ADR, скрипти, boilerplate-репозиторій, навчання команди (2–4 години).

Engagement model: фіксований retainer (щомісячно, 20–40 годин) або проектний (deliverable-based). Для стартапів на стадії pre-seed/seed — проектний формат, щоб не розмивати бюджет на постійний retainer.

Типові помилки при виборі стеку: кейс з практики

Один клієнт вибрав Polygon PoS для NFT-маркетплейсу з високою частотою транзакцій. Після запуску з'ясувалося, що checkpoint finality (~30 хвилин) не влаштовує користувачів — вони чекали підтвердження. Мігрували на Arbitrum Nova (AnyTrust) з finality в 1 секунду. Переробка обійшлася у $25 000 та два тижні затримки. Якби discovery врахувала вимоги до finality, цих витрат вдалося б уникнути.

Що входить в роботу

Орієнтири по термінах та вартості

• Discovery + ADR — від 1 до 2 тижнів. Вартість: розраховується індивідуально.
• Повна токеноміка (модель + симуляція + документація) — від 3 до 6 тижнів.
• Tech stack audit існуючого проекту — від 1 до 3 тижнів.
• Ongoing advisory retainer — від 3 місяців (мінімальний horizon для значного impact).

Помилковий вибір мережі або токеноміки на ранній стадії може коштувати проекту значних витрат на переробку — це підтверджує кожна друга наша discovery-сесія. Отримайте експертну оцінку свого проекту — залиште заявку на безкоштовний 60-хвилинний брифінг. Замовте консультацію — і ми покажемо, як уникнути типових помилок. Для індивідуального розрахунку вартості та термінів зв’яжіться з нами.