Управління проєктом розробки децентралізованої біржової платформи

Сухомудренко, Сергій Сергійович
Please use this identifier to cite or link to this item: https://er.chdtu.edu.ua/handle/ChSTU/7034
Full metadata record
DC Field	Value	Language
dc.contributor.advisor	Прокопенко , Тетяна Олександрівна	-
dc.contributor.author	Сухомудренко, Сергій Сергійович	-
dc.date.accessioned	2026-02-16T22:13:27Z	-
dc.date.available	2026-02-16T22:13:27Z	-
dc.date.issued	2025-12-17	-
dc.identifier.uri	https://er.chdtu.edu.ua/handle/ChSTU/7034	-
dc.description.abstract	Кваліфікаційна робота присвячена дослідженню створення децентралізованої біржової платформи (DEX) із застосуванням проєктного підходу та сучасних методологій управління ІТ-проєктами. DEX-платформа розглядається як комплексний Web3-проєкт, що поєднує технічні, організаційні та фінансовоуправлінські аспекти, включаючи розробку смартконтрактів, інтеграцію з блокчейн-мережами та оцінку економічної ефективності. Актуальність дослідження зумовлена зростанням складності управління проєктами у сфері децентралізованих фінансів, високими технічними та фінансовими ризиками, а також необхідністю ефективного використання ресурсів і мінімізації помилок під час розробки DEX-платформ. Метою роботи є узагальнення та обґрунтування методології проєктного менеджменту у процесі створення децентралізованої біржової платформи з урахуванням специфіки блокчейн-технологій та DeFi-середовища. Об’єктом дослідження є проєкт створення DEX-платформи, а предметом — методи, моделі та інструменти управління проєктом, зокрема управління ресурсами, ризиками, вартістю та якістю. У роботі використано стандарти PMBOK, гнучку методологію Agile Kanban, методи SWOT- та PEST-аналізу, а також інструменти управління ресурсами, ризиками, часом, вартістю та якістю проєкту. Наукова новизна полягає в адаптації підходів проєктного менеджменту до специфіки розробки децентралізованих біржових платформ з урахуванням особливостей блокчейн-технологій та DeFi-середовища. Практична значущість полягає в можливості застосування результатів роботи під час планування та управління Web3-проєктами і DEX-платформами. У першому розділі розглянуто концепцію створення DEX. У другому розділі обґрунтовано застосування галузей знань проєктного менеджменту. Третій розділ присвячений оцінці економічної ефективності та прогнозуванню фінансових показників проєкту. Четвертий розділ висвітлює практичні аспекти впровадження DEX-платформи	uk_UA
dc.language.iso	uk	uk_UA
dc.subject	проєктний менеджмент	uk_UA
dc.subject	планування ресурсів	uk_UA
dc.subject	Web3	uk_UA
dc.subject	DEX	uk_UA
dc.subject	DeFi	uk_UA
dc.subject	управління проєктами	uk_UA
dc.subject	Agile-методології	uk_UA
dc.subject	економічна ефективність	uk_UA
dc.title	Управління проєктом розробки децентралізованої біржової платформи	uk_UA
dc.type	Master Thesis	uk_UA
Appears in Collections:	126 Інформаційні системи та технології (IT Project Management)
Files in This Item:
File	Description	Size	Format
РЕП_МАГ_Сухомудренко_МІТ-2411.pdf Restricted Access		2.13 MB	Adobe PDF	View/Open Request a copy
Show simple item record
Extracted text
МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ 
ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ 
ФАКУЛЬТЕТ ІНФОРМАЦІЙНИХ ТЕХНОЛОГІЙ І СИСТЕМ 
КАФЕДРА ІНФОРМАЦІЙНИХ ТЕХНОЛОГІЙ ПРОЄКТУВАННЯ 
 
 
 
 
 
 
ПОЯСНЮВАЛЬНА ЗАПИСКА 
до кваліфікаційної роботи магістра 
на тему: Управління проєктом розробки децентралізованої біржової платформи 
 
 
 
 
Виконав  здобувач  другого 
(магістерського) рівня вищої освіти 
__2___курсу, групи  МІТ-2411 
Спеціальності 126 Інформаційні системи та 
технології 
ОП «IT Project Management» 
Сухомудренко  Сергій Сергійович 
Керівник: завідувач кафедри ІТП, д.т.н., 
проф. Прокопенко Тетяна Олександрівна 
Рецензент: посада, науковий ступінь, вчене 
звання, ПІП 
 
 
 
 
 
 
 
 
 
 
Черкаси 2025  
 
ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ 
 
Факультет Інформаційних технологій і систем 
Кафедра Інформаційних технологій проєктування 
Освітньо-кваліфікаційний рівень Магістр 
Спеціальність 126 – інформаційні системи та технології  
Освітня 
програма IT Project Management 
 
 
                                                                                          ЗАТВЕРДЖУЮ 
                                                                                          Завідувач кафедри ІТП  
                                                                                          _______________ Прокопенко Т.О. 
                                                                                         «____» _____________ 2025 р. 
 
 
 
ЗАВДАННЯ 
на кваліфікаційну роботу студенту 
Сухомудренко Сергій Сергійович 
(прізвище, ім‘я, по батькові) 
1. Тема роботи    Управління проєктом розробки децентралізованої біржової платформи 
 
Керівник роботи       Прокопенко Тетяна Олександрівна д.т.н., професор 
(прізвище, ім’я, по батькові, науковий ступінь, вчене звання) 
Затверджені наказом Черкаського державного технологічного університету від «7» жовтня 2025 
року № 307/03-03 
 
2. Строк подання студентом роботи    12 грудня 2025 р 
3. Вихідні дані до проєкту     стандарти управління проєктами; процеси управління проєктом;  
вимоги до керівника проєкту; управління командою проєкту; календарне планування проєкту; 
 управління ризиками проєкту; управління ресурсами проєкту 
  
4. Зміст пояснювальної записки (перелік питань, що їх належить розробити): 
Вступ 
1. Концепція створення децентралізованої платформи обміну криптовалют 
 2. Галузі знань створення децентралізованої біржової платформи на основі проєктного підходу 
3. Оцінка економічної ефективності проєкту 
 4. Практичні аспекти впровадження DEX-платформи 
Висновки 
Список використаних джерел 
 5. Перелік графічного матеріалу (з точним зазначенням обов’язкових креслень, плакатів) 
 
1. Ін1с)т рФукуцнікяц кіонраилсьтнуав аWчаB S структура проєкту 
2)  
Б 
 
       2)   Прогноз грошових потоків проєкту 
3)  Діаграма Ганта 
 6. Консультанти розділів роботи 
Прізвище, ініціали та Підпис, дата 
Розділ посада завдання видав завдання прийняв 
консультанта 
    
    
 
7. Дата видачі завдання 24.09.2025 
  
 
КАЛЕНДАРНИЙ ПЛАН 
№ з/п Назва етапів кваліфікаційної роботи магістра Строк виконання 
етапів роботи Примітка 
1.1 Постановка задачі 24.9.2025 Виконано 
1.2 Підготовка завдання 29.9.2025 Виконано 
1.3 Погодження завдання 01.10.2025 Виконано 
1.4 Затвердження завдання 03.10. 2025 Виконано 
2. Основна стадія   
2.1 Підбір матеріалів Виконано 
17.10.2025 
2.2 Аналіз шляхів вирішення постановленої задачі 21.10.2025 Виконано 
2.3 Розрахунок основних параметрів роботи  01.11.2025 Виконано 
2.4 Вибір кінцевого варіанту проєктного рішення 05.11.2025 Виконано 
2.5 Оформлення первісної редакції роботи 23.11.2025 Виконано 
3. Заключна стадія   
3.1 Узгодження прийнятих проєктних рішень з 25.11.2025 Виконано 
керівником 
3.2 Оформлення пояснювальної записки роботи в 01.12.2025 Виконано 
кінцевій редакції 
3.3 Попередній захист роботи 08.12.2025 Виконано 
3.4 Затвердження роботи 10.12.2025 Виконано 
3.5 Рецензування роботи 12.12.2025 Виконано 
3.6 Захист роботи 17.12.2025 Виконано 
 
 
Здобувач вищої освіти           _____________________________    Сухомудренко С.С. 
(підпис)                                         (прізвище та ініціали)         
 
Керівник роботи                     ____________________________      Прокопенко Т.О. 
                                          (підпис)                                           (прізвище та ініціали)     
 
 
 
 
 
АНОТАЦІЯ 
 
Пояснювальна записка магістерської роботи складається з чотирьох розділів, 
викладена на 99 сторінках, містить 12 рисунків, 25 таблиць, 3 додатки, використано 
50 джерел літератури. 
Кваліфікаційна робота присвячена дослідженню створення 
децентралізованої біржової платформи (DEX) із застосуванням проєктного підходу 
та сучасних методологій управління ІТ-проєктами. DEX-платформа розглядається 
як комплексний Web3-проєкт, що поєднує технічні, організаційні та фінансово-
управлінські аспекти, включаючи розробку смартконтрактів, інтеграцію з 
блокчейн-мережами та оцінку економічної ефективності. 
Актуальність дослідження зумовлена зростанням складності управління 
проєктами у сфері децентралізованих фінансів, високими технічними та 
фінансовими ризиками, а також необхідністю ефективного використання ресурсів 
і мінімізації помилок під час розробки DEX-платформ. 
Метою роботи є узагальнення та обґрунтування методології проєктного 
менеджменту у процесі створення децентралізованої біржової платформи з 
урахуванням специфіки блокчейн-технологій та DeFi-середовища. Об’єктом 
дослідження є проєкт створення DEX-платформи, а предметом — методи, моделі 
та інструменти управління проєктом, зокрема управління ресурсами, ризиками, 
вартістю та якістю. 
У роботі використано стандарти PMBOK, гнучку методологію Agile Kanban, 
методи SWOT- та PEST-аналізу, а також інструменти управління ресурсами, 
ризиками, часом, вартістю та якістю проєкту. 
Наукова новизна полягає в адаптації підходів проєктного менеджменту до 
специфіки розробки децентралізованих біржових платформ з урахуванням 
особливостей блокчейн-технологій та DeFi-середовища. 
Практична значущість полягає в можливості застосування результатів роботи 
під час планування та управління Web3-проєктами і DEX-платформами. 
У першому розділі розглянуто концепцію створення DEX. 
У другому розділі обґрунтовано застосування галузей знань проєктного 
менеджменту. Третій розділ присвячений оцінці економічної ефективності та 
прогнозуванню фінансових показників проєкту. Четвертий розділ висвітлює 
практичні аспекти впровадження DEX-платформи. 
 
 
Ключові слова: проєктний менеджмент, Web3, DEX, DeFi, управління проєктами, 
Agile-методології, економічна ефективність, планування ресурсів. 
 
 
 
 
 
 
 
 
 
SUMMARY 
 
The explanatory note of the master’s thesis consists of four chapters, is presented 
on 99 pages, contains 12 figures, 25 tables, 3 appendices, and references 50 literature 
sources. 
The qualification paper is devoted to the study of developing a decentralized 
exchange (DEX) platform using a project-based approach and modern IT project 
management methodologies. The DEX platform is considered as a comprehensive Web3 
project that combines technical, organizational, and financial-management aspects, 
including smart contract development, integration with blockchain networks, and the 
assessment of economic efficiency. 
The relevance of the research is driven by the increasing complexity of project 
management in the decentralized finance (DeFi) domain, high technical and financial 
risks, and the need for efficient resource utilization and error minimization during the 
development of DEX platforms. 
The goal of the work is to generalize and substantiate project management 
methodologies in the process of developing a decentralized exchange platform, taking 
into account the specifics of blockchain technologies and the DeFi environment. The 
object of the research is the project of developing a DEX platform, while the subject is 
the methods, models, and tools of project management, including resource, risk, cost, and 
quality management. 
The study applies PMBOK standards, the Agile Kanban methodology, SWOT and 
PEST analyses, as well as tools for managing project resources, risks, time, cost, and 
quality. 
The scientific novelty lies in adapting project management approaches to the 
specifics of decentralized exchange platform development, considering the characteristics 
of blockchain technologies and the DeFi environment. 
The practical significance of the research consists in the possibility of applying the 
obtained results in planning and managing real Web3 projects and DEX platforms. 
The first chapter examines the concept of creating a DEX. The second chapter 
substantiates the application of project management knowledge areas. The third chapter 
is devoted to assessing economic efficiency and forecasting the project’s financial 
indicators. The fourth chapter addresses the practical aspects of implementing a DEX 
platform. 
 
 
Keywords: project management, Web3, DEX, DeFi, project management 
methodologies, Agile methodologies, economic efficiency, resource planning. 
 
 
 
 
 
 
 2 
ЗМІСТ 
 
ВСТУП ............................................................................................................................. 4 
РОЗДІЛ I. Концепція проєкту створення децентралізованої платформи обміну 
криптовалют .................................................................................................................... 7 
1.1. Особливості створення децентралізованої біржової платформи .................... 7 
1.2 Аналіз ринку та конкурентів. ............................................................................... 9 
1.3 SWOT та PEST аналізи проєкту створення децентралізованої біржової 
платформи .................................................................................................................. 12 
1.4 Концепція проєкту .............................................................................................. 21 
РОЗДІЛ ІІ Галузі знань створення децентралізованої біржової платформи на 
основі проєктного підходу ........................................................................................... 31 
2.1 Управління змістом та предметною областю проєкту .................................... 31 
2.2 Управління ресурсами проєкту .......................................................................... 33 
2.3 Управління часом проєкту ................................................................................. 35 
2.4 Управління вартістю проєкту ............................................................................ 38 
2.4.1 Грошова винагорода команді. ..................................................................... 39 
2.4.2. Податки та збори .......................................................................................... 40 
2.4.3 Хмарна інфраструктура ................................................................................ 40 
2.4.4 Провайдери, інтеграції, API, аудит. ............................................................ 41 
2.4.5 Інші витрати та резерв .................................................................................. 41 
2.4.6 Фінальний бюджет ........................................................................................ 42 
2.5 Управління якістю проєкту ................................................................................ 42 
2.6 Управління інформаційним зв’язком та комунікаціями ................................. 45 
2.7 Управління ризиками .......................................................................................... 47 
2.8 Взаємодія компонентів системи ........................................................................ 49 
2.9 Управління персоналом ...................................................................................... 51 
РОЗДІЛ ІІІ Оцінка економічної ефективності проєкту ............................................ 55 
3.1 Планування фінансових ресурсів інвестиційної фази IT-проєкту ................. 55 
3.2 Оптимізація плану фінансування інвестиційної фази проєкту ....................... 56 
3.3 Зведений кошторис планових витрат інвестиційної фази DEX-проєкту ...... 60 
3.4 Прогнозування показників операційної діяльності ......................................... 61 
3.5 Планування амортизаційних витрат операційної діяльності .......................... 65 
3.6 Планування кредитних процесів операційної діяльності ................................ 65 
 
 3 
3.7 Прогноз доходів операційної діяльності ........................................................... 67 
3.8 Прогноз витрат операційної діяльності DEX-платформи ............................... 68 
3.9 Прогноз грошових потоків операційної діяльності ......................................... 70 
3.10 Прогноз грошових потоків проєкту ................................................................ 72 
3.11 Оцінка показників ефективності проєкту .......................................................... 74 
3.12 Розробка проєкту кредитного договору ....................................................... 75 
РОЗДІЛ ІV Практичні аспекти впровадження DEX-платформи ............................. 77 
4.1. Дослідницько-аналітична робота в процесі впровадження платформи ....... 77 
4.2 Організація впровадження та взаємодія учасників проєкту ........................... 78 
4.3 Інтеграція DEX-платформи в інформаційне середовище ............................... 79 
4.4 Взаємодія учасників проєкту та управління процесами впровадження ........ 80 
4.5 Управління відхиленнями від плану та зовнішні фактори впливу на строки 
впровадження ............................................................................................................ 81 
4.6 Використання інформаційних систем у менеджменті проєкту ...................... 83 
4.7 Оцінка ефективності впровадження та відповідність прогнозам ................... 84 
ВИСНОВКИ .................................................................................................................. 87 
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ ..................................................................... 90 
Додаток А ...................................................................................................................... 94 
Додаток Б ....................................................................................................................... 95 
Додаток В ...................................................................................................................... 98 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 4 
ВСТУП 
Швидке зростання технологій блокчейн та децентралізованих фінансів (DeFi) 
стимулює формування нових цифрових активів і платформ, що забезпечують їх 
обмін та взаємодію в мережевому середовищі. Однією з найдинамічніших галузей 
DeFi є децентралізовані біржі (DEX), які дозволяють користувачам проводити 
транзакції без посередників і зберігати повний контроль над своїми активами. 
Побудова DEX є складним процесом, оскільки потребує інтеграції 
смартконтрактів, мульти-ланцюгових інфраструктур, механізмів масштабування та 
комплексних систем моніторингу, що підтверджується сучасними дослідженнями 
в галузі управління інформаційними системами та інноваційними технологічними 
продуктами [1]. 
Попри суттєвий прогрес у розвитку Web3, більшість проєктів стикається з 
низкою викликів: інтеграція сторонніх сервісів, підвищені вимоги до безпеки, 
залежність від зовнішніх блокчейн-провайдерів, швидкі зміни нормативного поля. 
Ці фактори формують додаткові ризики та ускладнюють застосування традиційних 
методів управління ІТ-проєктами, що вимагає адаптованих підходів, орієнтованих 
на децентралізовані середовища [2]. 
Особливої уваги потребує управління проєктом створення DEX-платформи, 
оскільки помилки на ранніх етапах – формування вимог, планування, оцінки 
ризиків, визначення архітектури чи тестування – можуть призвести до критичних 
наслідків: фінансових втрат, вразливостей смартконтрактів, операційних збоїв та 
втрати користувацької довіри. Саме тому методологічно обґрунтоване управління 
розробкою децентралізованої біржової платформи є актуальною науковою та 
практичною проблемою. Для цього доцільно застосовувати стандартизовані 
підходи управління проєктами, описані у міжнародних керівництвах і системах 
професійного менеджменту [3] 
Метою дослідження є розроблення та обґрунтування системи управління 
проєктом створення децентралізованої біржової платформи та формування повної 
моделі розрахунку вартості її розробки з нуля. 
Для досягнення мети необхідно виконати наступні задачі: 
 
 5 
• Проаналізувати сучасний стан DeFi-ринку та підходи до створення DEX-
платформ. 
• Визначити специфіку управління блокчейн-проєктами, включно з 
технічними, організаційними та фінансовими ризиками. 
• Розробити структуру управління проєктом розробки DEX з урахуванням 
етапів життєвого циклу Web3-рішень. 
•  Сформувати детальну модель оцінки бюджету розробки з нуля, включно з: 
• наймом працівників, 
• оплатою праці найманих робітників, 
• оплатою сервісів, провайдерів і аудитів, 
• витратами на супровід та підтримку. 
• Удосконалити підхід до управління ризиками в блокчейн-проєктах. 
• Обґрунтувати методи забезпечення якості та безпеки DEX-платформи. 
• Сформувати практичні рекомендації щодо впровадження запропонованої 
моделі управління та фінансового планування. 
Об'єктом дослідження є процес управління ІТ-проектами в технології 
блокчейн, включаючи технічні, організаційні та економічні аспекти. 
Предметом дослідження є методи, моделі та інструменти управління 
проєктом розробки децентралізованої біржової платформи та методика повного 
розрахунку її вартості. 
Методи дослідження. У роботі були застосовані методи системного аналізу, 
методи проєктного менеджменту (PMBOK, Agile, Kanban), порівняльний аналіз 
архітектур DEX, моделювання бізнес-процесів, економічні методи для розрахунку 
вартості проєктів, методи ризик-менеджменту, інструменти фінансового 
планування та оцінки витрат. 
Новизна роботи полягає в тому, що був створений комплексний підхід до 
управління проектом розробки децентралізованої платформи обміну, поєднуючи 
сучасні методи управління проектами з економічними моделями для оцінки 
розвитку Web3. Запропонована робота представляє адаптовану модель управління 
ризиками, яка враховує специфіку децентралізованих систем, смарт-контрактів і 
 
 6 
багатоланцюгових середовищ. Важливим результатом є розробка структурованої 
моделі для формування загального бюджету проекту DEX, що охоплює технічні, 
інфраструктурні та операційні витрати. 
Практичне значення проведеного дослідження полягає в можливості 
застосування запропонованої моделі управління під час реалізації реальних Web3-
проєктів та децентралізованих платформ. Отримана модель оцінки бюджету є 
хорошим інструментом фінансового планування і може бути корисною для 
блокчейн-стартапів, інвесторів та компаній, що розробляють децентралізовані 
продукти. Представлені рекомендації можуть мінімізувати ризики проекту, 
раціоналізувати витрати та покращити ефективність організації розробки. Крім 
того, системний підхід до управління розробкою забезпечує покращення якості, 
стабільності та безпеки в роботі платформ DEX. 
Публікація результатів роботи і публікації.  Результати дипломної роботи 
представлені як окрема стаття «Особливості проєктного менеджменту у розробці 
децентралізованої платформи обміну криптовалют» // Матеріали IV Міжнародної 
науково-практичної  Internet-конференції «ІННОВАЦІЇ ТА ПЕРСПЕКТИВНІ 
ШЛЯХИ РОЗВИТКУ ІНФОРМАЦІЙНИХ ТЕХНОЛОГІЙ (ІПШРІТ-2025)», 25 
листопада 2025. [Електронний ресурс] – Черкаси: ЧДТУ, 2025. 
 
 
 
 
 
 
 
 
 
 
 
 7 
РОЗДІЛ I. Концепція проєкту створення децентралізованої платформи обміну 
криптовалют 
1.1. Особливості створення децентралізованої біржової платформи 
Одним із ключових напрямів удосконалення управління сучасними ІТ-
організаціями, підвищення ефективності їхньої діяльності, якості сервісів, 
продуктивності та конкурентоспроможності в умовах глобальної цифрової 
економіки є перехід до нових форм функціонування та розвитку – зокрема до 
використання децентралізованих фінансових інструментів і платформ. Особливе 
місце серед таких рішень посідають децентралізовані біржові платформи (DEX), 
що забезпечують обмін цифрових активів на основі смартконтрактів без участі 
централізованого посередника [4]. 
У контексті Web3 та DeFi децентралізована біржа розглядається як 
сукупність смартконтрактів, інтерфейсів користувача, інтеграцій із блокчейн-
мережами, провайдерами ліквідності, аналітичними сервісами тощо. На відміну від 
класичних централізованих бірж, DEX-платформи не акумулюють кошти 
користувачів на власних рахунках, а забезпечують операції безпосередньо між 
гаманцями користувачів через протоколи обміну. Це змінює як технічну 
архітектуру, так і управлінську логіку проєкту [5]. 
Становлення та розвиток проєктів децентралізованих бірж стали можливими 
завдяки сукупності факторів: глобалізації криптовалютних ринків; поширенню 
публічних блокчейн-мереж; появі стандартів токенів (ERC-20, ERC-721 тощо); 
розвитку протоколів автоматизованих маркет-мейкерів (AMM); формуванню 
мультичейнової інфраструктури; зростанню запиту на прозорість і 
безкастодіальність управління активами. Водночас такі проєкти функціонують у 
середовищі високої технологічної та регуляторної невизначеності, що посилює 
вимоги до системи їхнього управління [6]. 
Якщо для традиційних підприємств ключовими є матеріальні ресурси, 
виробничі потужності та фізична інфраструктура, то для DEX-платформ основну 
цінність становлять цифрові активи, програмний код, алгоритми управління 
ліквідністю, довіра спільноти та стійкість протоколу. Децентралізована біржа може 
 
 8 
не мати офлайн-офісу чи класичних виробничих потужностей, але водночас 
виступати повноцінним «віртуальним підприємством», що функціонує у 
глобальному цифровому просторі. 
Поняття «децентралізованість» у цьому контексті означає, що управління 
операціями та виконання угод здійснюється не централізованим суб’єктом, а 
заздалегідь визначеним набором правил, закріплених у смартконтрактах. Це 
зменшує роль людського фактору в окремих процесах, але підвищує вимоги до 
якісного проєктування, верифікації та аудиту коду. Будь-яка помилка в архітектурі 
чи логіці контрактів може призвести до незворотних фінансових втрат, оскільки 
транзакції в блокчейні, як правило, не підлягають скасуванню. 
Сучасні децентралізовані біржі, як і інші Web3-рішення, існують у формі 
розподілених систем, де окремі компоненти можуть належати різним учасникам 
екосистеми: розробникам протоколу, командам, що підтримують інтерфейс 
користувача, провайдерам даних (оракулам), провайдерам інфраструктури (RPC, 
ноди, хмарні сервіси), аудиторам безпеки тощо. Таким чином, проєкт створення 
DEX є складною коопераційною формою організації, де успіх залежить від 
узгодженої взаємодії багатьох автономних агентів. 
Важливою особливістю таких проєктів є можливість їхнього функціонування 
у вигляді протоколів з відкритим кодом, до розвитку яких долучається спільнота 
розробників і користувачів. Це з одного боку підвищує прозорість, а з іншого 
вимагає впровадження специфічних підходів до управління: голосування за 
пропозиції (governance), токен-економіка, механізми стимулювання ліквідності, 
програми баунті з пошуку вразливостей тощо. 
Отже, проєкт створення децентралізованої біржової платформи можна 
розглядати як форму віртуального підприємства нового типу, що функціонує на 
основі блокчейн-інфраструктури та смартконтрактів, об’єднує розподілені цифрові 
ресурси й компетенції, інтегрує зовнішні сервіси та орієнтується на глобальну 
аудиторію користувачів криптоактивів. Це зумовлює необхідність застосування 
адаптованих методів проєктного менеджменту, системного аналізу та ризик-
менеджменту. 
 
 9 
1.2 Аналіз ринку та конкурентів. 
Ринок децентралізованих фінансових сервісів (DeFi) стрімко розвивається та 
демонструє високу динаміку інновацій, що формує складне конкурентне 
середовище для сучасних DEX-платформ. Основні напрями змагання між 
учасниками ринку включають якість реалізації обмінних операцій, ефективність 
маршрутизації транзакцій, підтримку мультичейнових сценаріїв, гнучкість 
комісійної політики та загальний користувацький досвід [7] 
Щоб визначити місце досліджуваної DEX-платформи в екосистемі Web3, 
доцільно проаналізувати ключових гравців, які працюють у найближчих або 
суміжних сегментах ринку. Для порівняння обрано три платформи: Jumper, 
Uniswap та SushiSwap. Вони представляють різні підходи до організації обмінів – 
від мультипротокольної маршрутизації до AMM-моделей з власною ліквідністю, 
що дозволяє комплексно оцінити конкурентні переваги й обмеження. 
Jumper є одним із найбільш технологічно близьких аналогів, оскільки 
використовує той самий принцип маршрутизації через протокол LiFi. Платформа 
працює як універсальний інтерфейс для виконання обмінів між різними блокчейн-
мережами, агрегуючи маршрути через десятки зовнішніх мостів і 
децентралізованих бірж. Користувач отримує можливість виконувати як 
внутрішньомережеві, так і міжмережеві обміни без необхідності взаємодіяти з 
різними сервісами окремо. 
Jumper не має власної AMM-моделі та не володіє пулом ліквідності – усі 
операції відбуваються через зовнішні протоколи. Такий підхід робить платформу 
гнучкою, але повністю залежною від стабільності сторонніх API. Водночас вона не 
стягує власних комісій за обміни, отримуючи дохід переважно через партнерські 
механізми, що визначає її бізнес-модель. 
Хоча обидві платформи використовують протокол LiFi як основу для 
маршрутизації обмінів, досліджувана DEX-платформа має ширшу 
функціональність. На відміну від Jumper, вона застосовує власні смартконтракти 
для внутрішньомережевих обмінів і реалізує окрему комісійну модель. Це дає 
 
 10 
змогу формувати більш стабільний та прогнозований дохід, а також пропонувати 
користувачам розширені можливості, яких Jumper не надає. 
Uniswap є найбільшим і найвідомішим DEX-протоколом у сфері DeFi. Його 
архітектура ґрунтується на моделі AMM (Automated Market Maker – автоматичний 
маркетмейкер). Автоматизовані маркетмейкери забезпечують безперервну 
ліквідність без використання традиційних ордербуків, дозволяючи здійснювати 
децентралізований та бездозвільний обмін активами [8], що дозволяє користувачам 
здійснювати обміни без традиційних книг ордерів. Ліквідність у протоколі 
забезпечують самі користувачі шляхом внесення активів у пули, а ціна 
визначається автоматично відповідно до формули балансу пулу. 
Платформа підтримує велику кількість мереж, проте всі обміни виконуються 
в межах однієї мережі. Uniswap не має власної нативної можливості кросчейнових 
обмінів. Він також слугує джерелом ліквідності для багатьох інших сервісів – 
включаючи агрегатори, які виконують маршрутизацію через декілька DEX-х 
одночасно. 
У порівнянні з мультичейновим маршрутизатором, Uniswap пропонує іншу 
парадигму роботи – автономну ліквідність замість агрегування зовнішніх джерел. 
Його сильні сторони базуються на масштабі, стабільності та ліквідності 
екосистеми, але він не покриває сценарій обмінів між мережами. 
Uniswap представляє інший підхід до організації обмінів, використовуючи 
AMM-модель у якій ліквідність формується користувачами через спеціальні пули. 
На відміну від досліджуваної DEX-платформи, яка спирається на зовнішню 
маршрутизацію через LiFi та власні смартконтракти для внутрішньомережевих 
обмінів, Uniswap дозволяє виконувати операції без участі сторонніх протоколів. Це 
робить його одним із найпотужніших гравців у сфері обмінів завдяки високій 
ліквідності та великому охопленню мереж. 
Попри відмінність моделей, Uniswap є релевантним конкурентом, оскільки 
саме він задає галузеві стандарти швидкості обмінів, якості UX та економічної 
ефективності транзакцій. Порівняння з цією платформою дозволяє оцінити, 
 
 11 
наскільки досліджувана система може бути конкурентною без власної ліквідності 
та за повної залежності від маршрутизаторів. 
SushiSwap був створений як модифікована копія Uniswap архітектури та 
AMM-логіки, але згодом перетворився на повноцінну DeFi-екосистему, що 
включає кілька продуктів: AMM-біржу, сервіси кредитування, стейкінг, фармінг  та 
автоматизовані vault-інструменти. 
Платформа працює в багатьох мережах, однак, аналогічно до Uniswap, 
забезпечує лише внутрішньомережеві обміни. Для кросчейнових операцій 
користувачі мають застосовувати сторонні мости або мультичейнові агрегатори. 
SushiSwap пропонує ширший функціонал порівняно з іншими DEX-ами, але 
основна архітектура не вирішує ключове завдання мультичейнових швидких 
обмінів «у один клік», що знижує його конкурентність саме у твоєму сегменті. 
Хоча досліджувана DEX-платформа не використовує модель AMM, 
SushiSwap є важливим об’єктом порівняння, оскільки демонструє, як додаткові 
сервіси впливають на користувацьку поведінку, лояльність та обсяги операцій. Це 
дозволяє визначити, які механізми стимулювання можуть бути потенційно 
корисними в майбутньому розвитку платформи, навіть попри різні архітектурні 
підходи. 
Порівняння всіх чотирьох платформ зображені в таблиці 1.1. 
Таблиця 1.1 
Порівняння платформ за ключовимим критеріями 
Критерій Jumper Uniswap SushiSwap DEX-платформа 
AMM AMM (форк Власні 
Модель Агрегатор на (автоматичний Uniswap) + смартконтракти 
роботи LiFi маркетмейкер) DeFi-модулі + LiFi 
Тип обмінів Внутрішні та Лише внутрішні Лише Внутрішні та 
кросчейнові внутрішні кросчейнові 
 
 12 
Критерій Jumper Uniswap SushiSwap DEX-платформа 
Наявність Ні 
власної Ні Так Так (маршрутизація 
ліквідності через LiFi) 
Комісійна Партнерські Фіксовані комісії Гнучка Комісії власних 
модель комісії пулів комісійна смартконтрактів 
політика + частка від LiFi 
Залежність 
від Висока Низька Низька Помірна (лише 
сторонніх LiFi частково) 
API 
Комерційна 
Кросчейн Внутрішньомереже DeFi- DEX-платформа 
Орієнтація маршрутизаці
я ві обміни екосистема для масового 
використання 
Комерційна 
Зручність Розширена модель з 
Унікальніст «обмінів в Найбільша DeFi- власними fee та 
ь один клік» ліквідність ринку функціональні підтримкою 
сть 
мультичейну 
 
1.3 SWOT та PEST аналізи проєкту створення децентралізованої біржової 
платформи 
SWOT-аналіз є інструментом стратегічного планування, який дозволяє 
встановити зв’язки між сильними сторонами (Strengths) та слабкостями 
(Weaknesses) внутрішнього середовища проєкту, а також можливостями 
(Opportunities) і загрозами (Threats) зовнішнього середовища. У сфері Web3 та DeFi 
такий підхід є особливо важливим, оскільки децентралізовані системи 
функціонують у середовищі підвищених технологічних та регуляторних ризиків, 
що формуються під впливом зовнішніх чинників – стабільності блокчейн-мереж, 
криптографічних протоколів, ринкової волатильності та змін інфраструктурних 
 
 13 
стандартів [9]. Результати SWOT-аналізу можуть бути використані для формування 
стратегій розвитку, вибору пріоритетів, а також для коригування параметрів 
проєкту відповідно до ринкових умов.У контексті проєкту створення 
децентралізованої біржової платформи SWOT-аналіз дає можливість: 
• виявити конкурентні переваги обраної архітектури та моделі продукту; 
• ідентифікувати внутрішні обмеження команди та технологічного стеку; 
• визначити зовнішні можливості, пов’язані з ростом ринку DeFi та появою 
нових сегментів користувачів; 
• оцінити загрози, зумовлені регуляторними змінами, технологічними 
ризиками та конкуренцією з боку інших DEX і CEX (централізованих бірж). 
Результати SWOT-аналізу проєкту створення децентралізованої біржової 
платформи узагальнено в таблиці 1.2 
Таблиця 1.2 
Результати SWOT-аналізу проєкту створення децентралізованої біржової 
платформи 
Strengths (сильні сторони) Opportunities (можливості) 
1. Використання 1. Зростання популярності DeFi; 
децентралізованої архітектури; 2. Вихід на глобальні ринки; 
2. Безкастодіальна модель 3. Залучення інституційної 
роботи; ліквідності; 
3. Мультичейн-підтримка; 4. Інтеграції з Web3 продуктами; 
4. Прозорість операцій; 5. Партнерства з іншими 
5. Інтеграція з DeFi-протоколами; екосистемами; 
6. Автоматизація завдяки 6. Підвищення довіри через 
смартконтрактам. аудити. 
Weaknesses (слабкі сторони) Threats (загрози) 
1. Залежність від якості 1. Регуляторні обмеження; 
смартконтрактів; 2. Конкуренція з DEX/CEX; 
2. Складний інтерфейс для 3. Технологічні ризики; 
новачків; 4. Волатильність криптовалют; 
 
 14 
3. Потреба у Web3-фахівцях; 5. Атаки на смартконтракти та 
4. Витрати на аудити безпеки; інфраструктуру. 
5. Проблеми зі масштабуванням. 
 
Сутність PEST-аналізу полягає у виявленні й оцінці впливу факторів 
макросередовища на результати поточної й майбутньої діяльності проєкту [11], що 
ґрунтується на використанні блокчейн-технологій і функціонуванні у Web3-
екосистемі. Метод дозволяє системно аналізувати зовнішнє середовище за чотирма 
ключовими напрямами: P – Political/Legal, E – Economic, S – Sociocultural, T – 
Technological, та визначати тенденції, події та ризики, які не залежать від 
розробника, але здатні істотно вплинути на проєкт. Урядова політика, нормативно-
правова база та макроекономічні умови відіграють вирішальну роль у розвитку та 
стійкості платформ на основі блокчейну, часто визначаючи межі, у яких можуть 
працювати децентралізовані системи [10]. 
Метою проведення PEST-аналізу є визначення впливу макрочинників на 
поточну та майбутню діяльність DEX-платформи, оцінка стабільності середовища 
та виявлення напрямів, де необхідна адаптація або зміна стратегії. Враховуючи 
специфіку Web3-сфери – її регуляторну невизначеність, швидкий технологічний 
розвиток та високу залежність від глобальних економічних умов – PEST-аналіз є 
критично важливим інструментом стратегічного управління проєктом. Далі 
наводиться розгляд кожного пункту детальніше. 
Політичні та правові фактори (P – Political/Legal) 
Аналіз політичних та правових умов є одним з важливих аспектів, оскільки 
регуляторні вимоги забезпечують можливість легальної роботи криптовалютних 
платформ. Деякі конкретні акти з регулювання цифрових активів та правила 
можуть відрізнятися: наприклад, ЄС та США мають регуляторні акти (наприклад, 
положення MiCA або AML/KYC), які наразі контролюють цифрові активи та 
посилюють контроль за криптовалютними транзакціями. Але для DEX платформ 
такі розробки ведуть як до зростання довіри інституційних інвесторів, так і до 
 
 15 
закликів інтегрувати KYC процедури або обмежити їх, якщо це необхідно в деяких 
регіонах.  
Політична стабільність держав та наявність національної цифрової стратегії 
також значною мірою впливають на розвиток проектів Web3. У місцях, де є 
процвітаюча цифрова економіка та де інноваційні компанії мають конкурентну 
перевагу, децентралізовані платформи можуть бути більш перспективними для 
зростання. Тим часом політичні кризи, санкції або макроекономічні труднощі 
можуть ускладнити роботу постачальників інфраструктури, таких як RPC сервери 
або хмарні сервіси. Міжнародні торгові норми, зокрема обмеження з санкціями або 
контроль за грошовими потоками, також мають значний вплив. Якщо вони 
накладені занадто суворо, доступність ліквідності може постраждати, або доступ 
до банківських API може бути обмежений, або інтеграція фіатних платіжних 
шлюзів може стати неможливою. 
Економічні фактори (E – Economic) 
Економічні умови визначають платоспроможність користувачів, 
інвестиційну активність, здатність проєктів залучати капітал і рівень ринкових 
ризиків. Стан світової економіки має прямий вплив на криптовалютний ринок. Під 
час економічного піднесення інвестиції у DeFi зростають, а в періоди криз 
ліквідність різко зменшується, супроводжуючись підвищеною волатильністю. 
Важливим чинником є інвестиційна активність у сфері Web3. Наявність 
венчурного капіталу, зростання фондових ринків і попит на інновації визначають 
шанси DEX-платформи отримати фінансування для масштабування. Значний 
вплив має податкова політика: у багатьох державах вводяться окремі податки на 
криптооперації, що формує поведінку користувачів, прибутковість для маркет-
мейкерів і можливості операційних команд. 
Окремим фактором виступають валютні коливання. Нестабільність курсу, 
особливо у регіонах зі слабшими регуляціями, впливає на вартість інфраструктури 
в доларовому еквіваленті, доступність ліквідності та загальну інвестиційну 
активність користувачів. 
Соціокультурні фактори (S – Sociocultural) 
 
 16 
Розвиток Web3 значною мірою залежить від рівня цифрової грамотності 
населення, готовності приймати нові технології та загальної довіри до фінансових 
інновацій. Популярність криптовалют постійно зростає: збільшується число 
користувачів блокчейн-гаманців, а тренд на децентралізацію стимулює інтерес до 
DEX-платформ. 
Поведінка споживачів також змінюється: дедалі більше користувачів 
переходять від централізованих бірж до самостійного контролю активів (self-
custody), що створює сприятливе середовище для розвитку децентралізованих 
бірж, де автономність і безпека є ключовими перевагами. У країнах зі слабкою 
фінансовою стабільністю попит на DeFi як спосіб збереження капіталу зростає ще 
сильніше. 
Водночас рівень довіри до нових технологій все ще формується. Хоча інтерес 
до Web3 підвищується, користувачі остерігаються хакерських атак, помилок у 
смартконтрактах і складності інтерфейсів. Це підсилює роль якісного UX/UI-
дизайну, аудитів та освітніх матеріалів, адже вони безпосередньо впливають на 
темпи адаптації користувачів. Аналітичні звіти Chainalysis також підтверджують, 
що рівень прийняття криптотехнологій зростає у регіонах із високою економічною 
нестабільністю, де населення шукає фінансову автономію та альтернативу 
традиційним банківським інструментам [12] 
Технологічні фактори (T – Technological) 
Технологічний прогрес є головним драйвером успіху децентралізованих 
бірж. Розвиток блокчейн-технологій відкриває нові можливості Це узгоджується з 
аналітичними висновками Messari, згідно з якими швидка еволюція L2-мереж, zk-
технологій та модульних блокчейн-архітектур суттєво підвищує технологічні 
вимоги до учасників ринку та прискорює розвиток децентралізованих застосунків 
[13]. Це формує широке поле для мультичейн-інтеграцій, але вимагає значних 
технічних ресурсів та експертизи. 
Безпека залишається критичним аспектом, особливо з огляду на зростання 
кількості атак на мости, AMM-пули та інші DeFi-протоколи. Платформи повинні 
приділяти увагу аудитам, формальній верифікації та ретельному тестуванню для 
 
 17 
мінімізації ризиків. Також важливою є стабільність інфраструктури, яка залежить 
від якості роботи RPC-провайдерів, цінових оракулів та хмарних серверів, оскільки 
їхні збої безпосередньо впливають на стабільність і швидкість роботи DEX. 
Швидкість технологічних змін у Web3 надзвичайно висока – інструменти та 
стандарти можуть застаріти за пів року. Тому командам необхідно постійно 
оновлювати архітектуру платформи, додавати нові мережі та підтримувати 
актуальні стандарти токенів, щоб залишатися конкурентоспроможними в стрімко 
мінливому середовищі. 
Всі групи факторів, фактори та опис наведені в таблиці 1.3 
Таблиця 1.3 
Фактори та опис PEST-аналізу 
Група факторів Фактор Опис 
Політичні фактори Регулювання Різні країни по-різному 
 криптовалют та DeFi регулюють цифрові активи, що 
впливає на вимоги до KYC та 
можливість роботи в окремих 
регіонах. 
Політична Стабільність держави сприяє 
стабільність і цифрова розвитку Web3, тоді як кризи та 
стратегія санкції можуть ускладнювати 
роботу інфраструктури. 
Міжнародне Санкції можуть зменшувати 
регулювання торгівлі ліквідність і обмежувати доступ 
до фінансових інтеграцій. 
Економічні фактори Глобальні економічні Економічне зростання підсилює 
 тенденції інвестиції у DeFi, а кризи 
 зменшують ліквідність. 
 Інвестування у Web3- Доступність венчурного 
 проєкти капіталу визначає можливості 
розвитку DEX. 
 
 18 
Податкова політика Податки на криптооперації 
впливають на попит і 
прибутковість. 
Валютні коливання Нестабільність курсу впливає на 
витрати інфраструктури та 
активність користувачів. 
 
Соціальні фактори Популярність Зростання цифрової грамотності 
 криптовалют сприяє поширенню DEX-
платформ. 
Зміна поведінки Користувачі переходять до 
споживачів самостійного контролю активів. 
Попит на фінансову У країнах із нестабільною 
свободу економікою зростає 
використання DeFi. 
Рівень довіри до Попри популярність, існує 
технологій недовіра через ризики безпеки. 
Технологічні фактори Еволюція блокчейн- Нові мережі та L2-рішення 
 технологій розширюють можливості 
мультичейну. 
Безпека та Зростання атак підвищує вимоги 
смартконтракти до аудитів і тестування. 
Інфраструктурні Якість RPC та оракулів визначає 
постачальники стабільність роботи DEX. 
Швидкість Технології швидко застарівають, 
технологічних змін тому потрібні регулярні 
оновлення. 
 
Обмеження проєкту створення децентралізованої біржової платформи 
формують комплекс зовнішніх і внутрішніх чинників, що визначають умови його 
 
 19 
планування, реалізації та завершення. У Web3-сфері ці обмеження мають особливо 
вагоме значення через високий рівень технологічної динаміки, нестабільність 
регуляторного середовища та істотну залежність від інфраструктурних сервісів. Як 
зазначає PMBOK Guide – обмеження проєкту визначають рамки, в яких 
відбувається його планування та реалізація, обмежуючи доступні ресурси, час і 
можливості, що безпосередньо впливають на кінцевий результат» [14], що 
повністю узгоджується зі специфікою проєктів у сфері децентралізованих 
технологій. 
Зміст проєкту визначає обсяг функціональності, який повинен бути 
реалізований, і формується з урахуванням архітектури смартконтрактів, 
особливостей роботи мультичейну, вимог до модулів ліквідності, обміну активів, 
інтеграції гаманців і системи аналітики. У процесі реалізації проєкт може зазнавати 
впливу зовнішніх тенденцій Web3-ринку, що часто спричиняє розширення змісту: 
наприклад, необхідність інтеграції нової мережі, адаптації до змінених стандартів 
токенів чи оновлення протоколів безпеки. Будь-яке неконтрольоване збільшення 
змісту одразу впливає на інші обмеження проєкту. 
Тривалість реалізації проєкту залежить від складності розробки 
смартконтрактів, часу, необхідного для їх тестування та аудиту, швидкості роботи 
зовнішніх сервісів і можливих затримок, пов’язаних із включенням нових функцій 
чи партнерських інтеграцій. Особливістю блокчейн-проєктів є те, що аудит 
смартконтрактів може займати від кількох тижнів до місяців, а будь-які зауваження 
аудиторів вимагають доопрацювання, що подовжує загальний термін. Крім того, 
час виходу продукту на ринок має стратегічне значення, оскільки синхронізація з 
фазами ринку криптовалют може суттєво вплинути на його успіх. Затримка в релізі 
часто означає втрату сприятливого ринкового вікна. 
Важливо також враховувати інфраструктурні обмеження, характерні для 
Web3-середовища. Децентралізовані платформи істотно залежать від роботи 
мостів, RPC-вузлів, оракулів, сторонніх API та механізмів міжмережевої взаємодії. 
Як зазначено у дослідженні USENIX Security, «багатоланцюгові системи залежать 
від зовнішніх інфраструктурних компонентів – мостів, RPC-провайдерів та сервісів 
 
 20 
верифікації, і будь-які збої в них здатні порушити роботу всієї платформи» [15]. Це 
означає, що збої або перевантаження у зовнішніх сервісах можуть спричинити 
затримки транзакцій, падіння продуктивності або тимчасову недоступність 
окремих функцій платформи. 
Фінансові обмеження є ще одним визначальним аспектом. Бюджет проєкту 
включає витрати на розробку, тестування, аудит, побудову інфраструктури, 
підтримку сервісів, маркетингові активності та залучення ліквідності. В умовах 
високої волатильності криптовалютного ринку фінансові ресурси можуть 
змінюватися залежно від ринкової кон’юнктури чи доступності інвестицій. 
Особливо вагомими є витрати на аудит, адже якісний аудит смартконтрактів 
коштує значних сум, але є критично важливим для довіри користувачів. Зміна 
бюджету неминуче викликає необхідність перегляду змісту або термінів реалізації 
проєкту.  
Якість у Web3-проєктах має багатовимірний характер, що виходить далеко 
за межі класичних критеріїв. Вона включає безпеку смартконтрактів, стійкість 
платформи до атак, надійність механізмів маршрутизації, швидкість виконання 
транзакцій, відсутність вразливостей у логіці обміну активів і відповідність 
сучасним технологічним стандартам. Якість смартконтрактів є ключовим 
фактором безпеки блокчейн-платформ, оскільки виявлені вразливості можуть 
спричинити збої в роботі системи, втрату активів та необхідність повторного 
аудиту й перероблення архітектури [16]. Будь-яке підвищення вимог до якості 
тягне за собою необхідність збільшення бюджету або продовження термінів 
проєкту, оскільки потребує додаткового тестування, багатоетапних аудитів, 
удосконалення архітектури та оптимізації інфраструктури.  
Зміна одного обмеження автоматично викликає реакцію в інших. 
Розширення змісту потребує збільшення бюджету та часу; пришвидшення 
розробки без підвищення ресурсів неминуче знижує якість; скорочення бюджету 
вимагає зменшення змісту або відмови від окремих функцій. Взаємозалежність 
обмежень є ключовим аспектом управління проєктом, тому керівник проєкту 
 
 21 
повинен постійно контролювати баланс між ними, приймаючи рішення з 
урахуванням стратегічних цілей і поточного стану зовнішнього середовища. 
У прозорому та швидкозмінному середовищі Web3 обмеження проєкту 
поступово формують рамки, у яких має діяти команда, і визначають можливості 
подальшого масштабування платформи. Адекватний аналіз і своєчасна реакція на 
зміни дозволяють мінімізувати ризики, підвищити якість рішень та забезпечити 
стабільний хід реалізації проєкту. 
 
1.4 Концепція проєкту 
Проєкт створення децентралізованої біржової платформи (DEX) 
розглядається як сучасне віртуальне середовище взаємодії користувачів Web3-
екосистеми, що забезпечує виконання операцій обміну цифрових активів у режимі 
peer-to-peer без залучення централізованих посередників. У сучасних умовах 
розвитку блокчейн-технологій, швидкого зростання ринку цифрових активів та 
переходу світової економіки до моделі децентралізованих інформаційних систем, 
створення DEX-платформи є відповіддю на зростаючі потреби користувачів у 
безпечних, прозорих та доступних фінансових інструментах 
Враховуючи результати проведеного аналізу Web3-галузі та тенденцій до 
інституційної децентралізації, у межах даного проєкту прийнято рішення 
розробити комплексне програмне рішення, яке включатиме: 
• модуль обміну активів  
• модуль мульти-чейну з підключенням до різних блокчейнів 
• модуль аналітики 
• інструменти інтеграції гаманців та смартконтрактів, 
• зовнішній інтерфейс для інтеграторів. 
Особливе місце у структурі проєкту займають інтеграційні інструменти для 
роботи з гаманцями та смартконтрактами, оскільки саме вони визначають рівень 
безпеки й доступності платформи. Як відзначають дослідники, інтеграція гаманців 
та безпечне управління ключами є ключовими факторами зручності та поширення 
 
 22 
децентралізованих платформ [17], що підкреслює критичну важливість якісної 
реалізації цього модуля. 
Проєкт спрямований на створення конкурентоспроможної DEX-платформи, 
яка забезпечить високий рівень автоматизації операцій, підвищить якість взаємодії 
користувачів із цифровими активами та відповідатиме сучасним технологічним 
стандартам провідних світових протоколів. 
Головною метою проєкту є розроблення функціональної, безпечної та 
масштабованої децентралізованої біржової платформи, що дозволить отримувати 
прибуток за рахунок комісій з обмінів, крос-чейн обміну та додаткових сервісів, 
таких як стейкінг і плата за інтеграцію. Метою також є підвищення рівня 
фінансової незалежності користувачів та надання інструментів, що не залежать від 
централізованої інфраструктури. 
Для формування структури цілей проєкту виконано декомпозицію 
генеральної мети на підцілі та відповідні завдання, що дає можливість організувати 
послідовний перехід від концепції до її практичної реалізації. Декомпозиція 
використовується для побудови “дерева цілей”, що дозволяє чітко співвідносити 
ключові бізнес-показники, технологічні цілі та завдання команди. Стратегічні цілі 
представлено на рис. 1.1. 
 
Рисунок 1.1 – Стратегічні цілі DEX платформи. 
 
 23 
У DEX-платформі корпоративні веб-сайти замінюються веб-інтерфейсами 
для взаємодії з блокчейном, інтеграцією криптогаманців (MetaMask, WalletConnect, 
Phantom) та візуальними модулями, що забезпечують роботу обмінів, кросчейн-
операцій та відображення історії транзакцій. Корпоративні веб-додатки у випадку 
DEX виконують роль розподілених Web3-застосунків (dApp), де користувач 
взаємодіє з платформою без централізованих серверів, а всі дані зберігаються у 
блокчейні. Такий підхід відповідає сучасному визначенню dApp як систем, у яких 
інтерфейс взаємодіє безпосередньо з компонентами блокчейн-мережі без участі 
централізованих серверів [10]. 
Корпоративне програмне забезпечення в класичному розумінні відповідає 
смартконтрактам, які реалізують основну логіку системи, включаючи створення 
транзакцій, маршрутизацію токенів, управління комісіями та забезпечення 
кросчейн-взаємодії. dApp та смартконтракти повністю автоматизують операції та 
забезпечують прозорість кожної взаємодії завдяки використанню блокчейн-
технологій. 
У межах проєкту створення децентралізованої біржової платформи 
ключовим джерелом фінансування є банківський кредит, який покриває витрати на 
розробку, аудит, інфраструктуру, залучення спеціалістів та маркетингові 
активності. На відміну від проєктів, що повністю фінансуються венчурним 
капіталом, у даній моделі інвестори виконують допоміжну фінансову роль, але не 
є основним джерелом бюджету. 
Роль інвесторів полягає у: 
• покритті процентів за кредитом упродовж інвестиційної фази; 
• наданні безвідсоткової позики платформі для погашення тіла кредиту в разі 
збиткового фінансового року; 
• залученні партнерських можливостей і мережевого ефекту, що є типовими 
драйверами розвитку Web3-протоколів, адже інвестиційна активність у 
блокчейні часто стимулюється очікуванням майбутньої корисності, 
зростанням екосистеми та довгостроковим доходом [18]. 
 
 24 
У такій моделі інвестори не фінансують прямі операційні витрати, але 
підтримують фінансову стійкість проєкту на ранніх етапах, що зменшує ризики 
зупинки розробки та дозволяє контролювати кредитне навантаження протягом 
періоду становлення платформи. 
Замовником проєкту є організація, що ініціює створення DEX-платформи, 
визначає бізнес-вимоги, функціональні очікування та стратегічну мету продукту. 
Користувачами кінцевого рішення виступають трейдери, інтегратори, оператори 
ліквідності, арбітражні боти та сторонні сервіси, які взаємодіють із платформою 
через інтерфейс або API. Саме їхні потреби формують вимоги до швидкості 
обробки транзакцій, надійності смартконтрактів, доступності та масштабованості 
системи. 
Координацію роботи всієї команди забезпечує керівник проєкту, який 
відповідає за планування, управління строками, ризиками та комунікаціями, а 
також підтримує ефективну взаємодію між усіма зацікавленими сторонами. 
Необхідність такої ролі підкреслюється дослідженнями у сфері управління 
проєктами, згідно з якими успішна реалізація проєкту потребує чітко визначених 
ролей, ефективної координації та постійної комунікації зі стейкхолдерами [20]. 
Команда розробки охоплює Web3-фронтенд розробників, відповідальних за 
користувацький інтерфейс і взаємодію з гаманцями; бекенд-інженерів, які 
створюють позаланцюгову логіку та інтеграції; блокчейн-розробників, що 
реалізують смартконтракти та механізми ліквідності; а також DevOps-фахівців, які 
забезпечують хмарну інфраструктуру, безперервну інтеграцію, масштабованість і 
стабільну роботу компонентів системи. До команди належать і спеціалісти з 
контролю якості, що тестують вебінтерфейси, інтеграції та смартконтракти, 
гарантуючи безпомилкову роботу критично важливих функцій. UX/UI-дизайнер 
відповідає за побудову інтерфейсів, які поєднують зручність, функціональність і 
відповідність очікуванням користувачів. 
Важливу роль у забезпеченні ринкової присутності платформи відіграє 
маркетолог, який формує стратегію просування продукту, визначає канали 
комунікації, розробляє механізми залучення ліквідності та підвищення 
 
 25 
впізнаваності бренду. Поряд із цим HR/Recruiter виконує функції з підбору кадрів, 
оцінки компетенцій, адаптації спеціалістів і формування стабільної команди. 
Значущість правильної взаємодії всередині команди підтверджує 
дослідження, згідно з яким колаборативні команди з різними ролями мають 
постійно взаємодіяти та розділяти відповідальність, а ефективна комунікація й 
міжфункціональна співпраця є критично важливими у складних проєктах [19] . 
Архітектори смартконтрактів визначають структуру протоколу, логіку 
обміну, моделі управління ліквідністю та підходи до забезпечення безпеки. Їхня 
діяльність критично важлива, оскільки помилки на цьому рівні можуть спричинити 
втрату активів або створити загрози для всієї системи. 
До зовнішніх учасників належать постачальники технологічних сервісів – 
провайдери RPC-інфраструктури, аудитори смартконтрактів, сервіси аналітики й 
хмарні платформи. Ліцензіари та регуляторні структури відіграють роль у питаннях 
правової відповідності та токеномічних моделей. Посередниками виступають 
агрегатори ліквідності та мультичейнові маршрутизатори, що забезпечують 
додаткові канали залучення користувачів і ліквідності.Таким чином, система 
учасників проєкту формується як багаторівнева мережа взаємодій між внутрішніми 
та зовнішніми стейкхолдерами. Злагоджена робота інвесторів, розробників, 
дизайнерів, маркетингової команди, HR-фахівців, аудиторів і зовнішніх 
постачальників визначає стабільність, безпечність, конкурентоспроможність і 
життєздатність децентралізованої біржової платформи. Всю команду зображено 
схематично на рис. 1.2. 
 
 26 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Рисунок 1.2 – Команда розробки 
 
Корпоративний веб-сайт у межах DEX-проєкту виконує роль інформаційної 
та комунікаційної платформи, забезпечуючи онлайн-присутність, доступ до 
документації та формування довіри користувачів. На відміну від звичайних сайтів, 
ресурс децентралізованої біржі повинен містити інтеграцію з Web3-технологіями 
та відображення стану протоколу в реальному часі. 
Веб-додаток виступає основним інтерфейсом взаємодії користувачів із 
платформою. Через нього трейдери, інтегратори ліквідності та сторонні сервіси 
здійснюють обмін активів, підключають гаманці, керують ліквідністю та 
переглядають історію транзакцій. Його розвиток повинен відповідати 
архітектурним принципам Web3, адже, як зазначає Імран Башир, 
децентралізований застосунок складається зі смартконтрактів, бекенд-сервісів та 
інтерфейсу, що взаємодіє з гаманцями та вузлами блокчейну, а безпечна й надійна 
 
 27 
робота цих компонентів є критично важливою для коректного виконання 
транзакцій [21]. 
Програмне забезпечення DEX охоплює бекенд-сервіси та інфраструктурні 
модулі, що забезпечують виконання транзакцій, індексацію блоків, маршрутизацію 
ліквідності та захист від помилок або атак. Сукупно ці компоненти формують 
технічну основу протоколу та визначають його швидкість, безпечність і 
стабільність у різних мережевих умовах.Важливо відокремлювати функції цих 
компонентів: веб-сайт відповідає за комунікацію та репутацію, веб-додаток – за 
операційну взаємодію користувачів, програмне забезпечення – за роботу всієї 
мережевої та протокольної логіки. Разом вони створюють цілісну екосистему 
платформи. 
Розробка Web3-додатку потребує сучасних технологій для фронтенду й 
бекенду, хмарної інфраструктури та забезпечення високого рівня безпеки. 
Життєвий цикл DEX-виробу включає проєктування смартконтрактів, аудит, 
тестування, інтеграції, реліз у тестовій та основній мережах і подальший 
моніторинг. 
Цільовий сценарій проєкту складається з послідовних та паралельних 
процесів: написання смартконтрактів, створення UI, побудова індексаторів, 
впровадження джерел ліквідності, інтеграція гаманців та запуск протоколу. 
За класифікацією проєкт створення DEX є інноваційним монопроєктом 
інвестиційного характеру, середнього масштабу та підвищеної технічної 
складності. Його успіх залежить від доступності ресурсів, стану ринку 
криптоактивів, технологічних тенденцій та регуляторних вимог. 
Оточення проєкту формується інвесторами, користувачами, конкурентними 
протоколами, регуляторами, постачальниками інфраструктури та аудиторами. 
Сукупність цих зовнішніх і внутрішніх факторів визначає можливості, обмеження 
та стратегію розвитку децентралізованої біржі. 
Технічна реалізація децентралізованої біржової платформи базується на 
сучасному стеку Web3-технологій, який забезпечує стабільну роботу інтерфейсу, 
серверної логіки та смартконтрактів. Фронтенд побудовано на основі фреймворку 
 
 28 
Next.js та мови TypeScript із використанням бібліотек Wagmi, Viem та Ethers.js для 
взаємодії зі смартконтрактами та гаманцями. 
Бекенд реалізується на платформі Node.js з фреймворком NestJS, що дозволяє 
організувати мікросервісну архітектуру та ефективну обробку даних. Для побудови 
API використовується GraphQL, а тестування й документування інтеграцій 
здійснюється за допомогою Postman. Постгрес-серверна частина працює з базою 
даних PostgreSQL, яка забезпечує надійне зберігання структурованої інформації. 
Блокчейн-компонент проєкту побудовано на смартконтрактах, розроблених 
мовою Solidity. Їх компіляція, тестування та локальне налагодження виконуються 
у середовищі Hardhat, що підтримує всі необхідні інструменти для роботи з 
мережами EVM-сумісності. 
Інфраструктурна частина розгортається у хмарному середовищі AWS з 
використанням контейнеризації на основі Docker, що забезпечує масштабованість, 
стабільність і передбачуваність роботи сервісів. 
Застосування цього технологічного стеку дозволяє створити надійну, 
продуктивну та безпечну архітектуру децентралізованої біржової платформи. 
Повний список технологій представлено на рис. 1.3 
 
Рисунок 1.3 – Технології для розробки DEX платформи. 
У межах розробки децентралізованої біржової платформи важливу роль 
відіграють зовнішні інтеграції, які забезпечують доступ до ліквідності, аналітики, 
телеметрії та інфраструктурних сервісів. Для мультичейнової маршрутизації 
 
 29 
транзакцій використовується інтеграція з LiFi, яка дозволяє виконувати 
кросчейнові обміни та інтегрувати ліквідність з різних блокчейн-мереж. Moralis 
надає інфраструктуру для розробки Web3-рішень, забезпечуючи доступ до 
блокчейн-даних, індексацію подій і швидку взаємодію з мережами. Sentry 
використовується для моніторингу та сповіщення про помилки, що дозволяє 
оперативно виявляти збої та підтримувати стабільність застосунку. 
У свою чергу, Alchemy виконує роль інфраструктурного блокчейн-
провайдера для розробників, забезпечуючи надійні RPC-вузли та високу 
доступність мережі. Інтеграція з Reown забезпечує інструменти для управління 
цифровою ідентичністю та взаємодії з криптогаманцями. Завершує набір сервісів 
CoinGecko, який надає актуальні дані аналітики криптовалют, необхідні для 
відображення ринкових показників у межах DEX. 
Значення таких інтеграцій підтверджується тим, що, як зазначає Нараян 
Прасті – сучасні децентралізовані застосунки значною мірою залежать від 
зовнішніх блокчейн-сервісів, RPC-провайдерів, індексаторів даних та 
інтероперабельних шарів, які дозволяють агрегувати ліквідність, виконувати крос-
чейнові операції та підтримувати надійність мережевої взаємодії [22]. Всі інтеграції 
зображені на рис 1.4 
 
 
Рисунок 1.4 – Заплановані інтеграції платформи. 
 
 
 30 
Висновки до розділу 1 
У першому розділі розглянуто особливості створення децентралізованої 
біржової платформи, визначено її ключові технічні та організаційні параметри, а 
також проаналізовано специфіку роботи DEX у сучасній Web3-екосистемі. 
Проведені SWOT- та PEST-аналізи дали змогу окреслити внутрішні можливості й 
обмеження проєкту, а також зовнішні фактори, що впливають на його реалізацію. 
Окремо проаналізовано базові проєктні обмеження, які формують рамки 
подальшого планування. 
У межах розділу сформовано концепцію платформи, визначено її мету, 
стратегічні цілі та логіку досягнення результатів. Визначено склад команди 
розробки, її рольову структуру та основні функції. Також описано технологічний 
стек, що включає засоби фронтенд-, бекенд-, блокчейн-розробки та 
інфраструктурні рішення, а також інтеграції із зовнішніми сервісами, необхідними 
для забезпечення стабільної роботи платформи. 
Таким чином, перший розділ створює необхідну аналітичну основу для 
переходу до проєктування архітектури, визначення вартості розробки та 
планування практичної реалізації DEX-платформи. 
 
 
 
 
 
 
 
 
 
 
 
 
 31 
РОЗДІЛ ІІ Галузі знань створення децентралізованої біржової платформи на 
основі проєктного підходу 
 
2.1 Управління змістом та предметною областю проєкту 
 
Управління змістом у проєкті створення децентралізованої біржової 
платформи полягає у формуванні чітко визначених меж проєкту, встановленні 
макроцілей, детальному описі предметної області та декомпозиції функціональних 
елементів системи. Оскільки платформа не має власної ліквідності чи пулів, її 
предметна область зосереджена на побудові інтеграційного шару, маршрутизації 
транзакцій, безпечній роботі з гаманцями та підключенні до зовнішніх DEX, мостів 
і ліквідних агрегаторів. 
Макроцілі визначають стратегічне спрямування розвитку продукту та 
формують основу для деталізації змісту. Основними цілями є створення безпечної, 
продуктивної та масштабованої платформі, що забезпечує: 
• побудову децентралізованої інфраструктури для обміну активів без 
централізованих пулів; 
• підтримку мультичейнових обмінів із використанням зовнішньої ліквідності; 
• інтеграцію з гаманцями Web3 та інфраструктурними сервісами; 
• гнучку та модульну архітектуру, що дозволяє розширювати функціонал без 
змін основних компонентів системи. 
Таке формулювання цілей забезпечує відповідність між баченням проєкту та 
процесом його реалізації, а також створює основу для подальшої декомпозиції 
робіт. 
Зміст проєкту розкладається на кілька ключових груп компонентів. 
До функціональної частини платформи належать ядрові модулі, такі як 
інтерфейс обміну (Swap), модуль міжланцюгових транзакцій (Bridge), панель 
управління (Dashboard), система підключення гаманців та адміністративна панель. 
 
 
 32 
Технічна складова включає бібліотеки фронтенду, бекенд-сервіси, 
смартконтракти, API-інтеграції та інструменти моніторингу. Важливим елементом 
є інтеграційний шар, через який DEX підключається до LiFi, агрегаторів даних, 
RPC-провайдерів, аналітичних платформ та інших сервісів. Інфраструктурний шар 
охоплює серверні компоненти, CI/CD, систему контейнеризації та механізми 
безперервного розгортання. Як вважає Іан Сщммервіль, добре визначена 
архітектура системи та структурована декомпозиція функціональності є 
ключовими для управління складністю сучасних програмних проєктів, підвищення 
надійності, можливості розвитку та координації між командами розробки [23]. Це 
положення безпосередньо стосується DEX-платформи, оскільки її архітектура 
складається з багатьох інтеграцій, модулів та зовнішніх залежностей, що 
потребують чіткого планування. 
Для впорядкування робіт формується WBS (Work Breakdown Structure), яка 
деталізує кожен етап реалізації продукту. Структури декомпозиції робіт 
допомагають встановити чіткі межі системи, визначити необхідні компоненти, 
зменшити неоднозначність і підтримувати ефективне планування та контроль 
протягом усього життєвого циклу проєкту [24]. Структура WBS у даному проєкті 
поділяється на десять основних блоків, що відображають логіку створення DEX від 
дослідження до запуску: 
• R&D (аналіз вимог, технічні прототипи, формування архітектурних рішень); 
• архітектура системи (структура модулів, моделі даних, інтеграційні 
контури); 
• розробка фронтенду (UI/UX, логіка обмінів, підключення гаманців, 
взаємодія з API); 
• розробка бекенду (мікросервіси, аналітичні шлюзи, GraphQL API, 
маршрутизація транзакцій); 
• розробка смартконтрактів (функціональні контракти, адаптери, безпекові 
модулі); 
• тестування (функціональні тести, безпекові перевірки, навантажувальні 
тести, Web3-QA); 
 
 33 
• інтеграції (LiFi, Moralis, Alchemy, Reown, CoinGecko, Sentry, RPC-
провайдери); 
• DevOps (Docker, CI/CD, інфраструктура AWS, моніторинг, логування); 
• запуск MVP (фінальні перевірки, деплой, аудит, стабілізація); 
• підтримка (оновлення, оптимізація, реагування на інциденти). 
Весь процес розробки показано на рис. 2.1. 
 
Рисунок 2.1 – WBS-схема розробки DEX-платформи. 
Побудова WBS дозволяє визначити обсяг робіт, відповідальних осіб, ресурси 
та залежності між етапами. Це формує чітку модель послідовності дій та допомагає 
оцінювати терміни, вартість і ризики проєкту. 
 
2.2 Управління ресурсами проєкту 
Управління ресурсами в проєкті децентралізованої біржової платформи 
охоплює планування, розподіл і контроль трудових та матеріальних ресурсів, 
 
 34 
необхідних для реалізації всіх етапів розробки. Основою ресурсної моделі є трудові 
ресурси – проектна команда, до складу якої входять менеджер проєкту, blockchain-
розробники, backend- і frontend-фахівці, інженери DevOps, спеціалісти з 
тестування, UI/UX-дизайнери та інші учасники, залучені відповідно до WBS. Для 
кожної ролі визначається сфера відповідальності, завдання та рівень завантаження 
на різних етапах проєкту, що дозволяє забезпечити ефективну координацію робіт і 
збалансоване використання людських ресурсів. 
Як зазначає Г. Керцнер, ефективне управління ресурсами забезпечує 
наявність потрібних фахівців, інструментів та технологій у потрібний момент, що 
дозволяє проектним командам підтримувати продуктивність, зменшувати 
затримки та досягати стратегічних цілей [19]. 
Матеріальні ресурси в проєкті представлені переважно хмарними 
інфраструктурними сервісами та інструментами розробки, що забезпечують 
безперервну роботу платформи та всіх супутніх процесів. Враховуючи віддалений 
формат роботи команди, апаратне забезпечення не формує значної частини 
ресурсної бази, адже більшість фахівців використовують власну техніку, а 
необхідність додаткових робочих станцій виникає лише у виняткових випадках. 
Більш критичними є ресурси хмарної інфраструктури – сервери AWS, системи 
контейнеризації, CI/CD-середовища, інструменти моніторингу та логування. 
Окрему групу складають платні зовнішні сервіси, від яких залежить 
функціонування DEX-платформи: RPC-провайдери, агрегатори ліквідності, 
сервіси ончейн-даних, аудиторські компанії для перевірки смартконтрактів, сервіси 
аналітики та інструменти моніторингу на кшталт Sentry або Alchemy. Саме ці 
ресурси забезпечують доступність, безпеку та стабільність роботи системи в 
умовах активного використання зовнішніх API та мультичейнових 
маршрутизаторів. Ефективне управління ресурсами дозволяє оптимізувати 
витрати, мінімізувати ризики та забезпечити плавну реалізацію проєкту на всіх 
його етапах.  
 Всі ресурси проєкту представлено на Рис. 2.2  
 
 35 
 
Рисунок 2.2 – Ресурси проєкту 
 
2.3 Управління часом проєкту 
Управління часом у програмних проєктах ґрунтується на поділі роботи на 
малі, чітко визначені задачі, виявленні залежностей та забезпеченні безперервного 
потоку виконання, щоб уникнути вузьких місць і затримок [25]. Враховуючи, що 
розробка здійснюється за методологією Kanban, процеси виконуються без 
жорстких спринтів, але із чітко визначеними епіками, що дозволяє ефективно 
керувати пріоритетами, оперативно реагувати на зміни та забезпечувати 
безперервну поставку функціональних модулів через впроваджений CI/CD-
конвеєр. 
Структура робіт базується на декомпозиції проєкту на ключові епіки для 
кожної команди: фронтенд, бекенд, смартконтракти, DevOps та QA. Для кожної 
команди визначено набір функціональних етапів, обсяг задач і залежностей. Роботи 
плануються таким чином, щоб команди могли працювати максимально паралельно, 
мінімізуючи блокування та затримки. Як зазначає Дж. Сазерленд, малі 
кросфункціональні команди, що працюють короткими ітераціями, здатні значно 
швидше створювати цінність і адаптуватися до змін із мінімальними затримками 
[26]. 
 
 
 36 
До складу робіт входять: 
• Frontend епіки – побудова UI-скелетону, інтеграція гаманця, реалізація 
модулів Swap і Bridge, створення Dashboard та Admin Panel, оптимізація та 
E2E тест-покриття. 
• Backend епіки –  формування архітектури, модулі токенів і цін, транзакційний 
модуль, інтеграція з LiFi, логування та моніторинг, бекенд-функціонал 
адміністративної панелі. 
• Smart Contracts – підготовка середовища Hardhat, створення допоміжних 
контрактних модулів, реалізація функцій маршрутизації, інтеграція з 
backend, тестування та верифікація. 
• DevOps – організація CI/CD, налаштування інфраструктури AWS, 
моніторингу та логування, забезпечення захищених пайплайнів та 
промислового середовища. 
• QA – безперервне тестування кожної реалізованої функції, регресійне 
тестування після релізів, інтеграційне тестування, участь у Acceptance Testing  
перед релізом у реальне користувацьке серидовище. 
Загальна тривалість розробки становить 8 місяців. Проєкт структурований 
таким чином, що основні блоки працюють паралельно: 
• фронтенд і бекенд розпочинають роботу з перших тижнів, синхронізуючись 
за допомогою спільних API-контрактів; 
• смарт контракти розробляються паралельно із backend-логікою, із 
подальшою інтеграцією; 
• DevOps забезпечує інфраструктуру та безперервну доставку ще з початку 
проєкту; 
• QA процес є безперервним, оскільки кожний функціональний модуль 
проходить тестування перед перенесенням у клієнтське серидовище.  
Повний календарний графік робіт представлений у Додатку А. 
Такий підхід дозволяє зменшити час очікування між етапами, а також 
забезпечити прозорість прогресу в режимі реального часу. 
Критичний шлях проєкту пов’язаний із залежностями показаний на рис. 2.3 
 
 37 
 
 
Рисунок 2.3 – Критичний шлях проєкту. 
Затримка на будь-якому з цих етапів призведе до зміщення кінцевої дати 
запуску MVP, оскільки вони формують основу функціональності платформи. 
Для візуалізації плану побудовано детальну Гант-діаграму, що відображає: 
 • епіки кожної команди, 
 • тривалість робіт, 
 • залежності між компонентами, 
 • паралельну роботу фронтенду, бекенду, DevOps та smart contracts, 
 • постійний QA-процес, 
 • етапи аудиту та запуск MVP. 
 Діаграма Ганта зображена на Рис 2.4 
 
 
 
 38 
 
Рисунок 2.4 – Діаграма Ганта. 
Графік демонструє, як від початкових досліджень та архітектури команди 
переходять до реалізації ключових модулів, інтеграцій, тестування й подальшого 
релізу.  
Управління часом у даному проєкті базується на поєднанні Kanban-підходу, 
паралельної роботи команд, CI/CD-процесів та гнучкої епік-структури. Така 
модель сприяє швидкому зворотному зв’язку між командами, що є критично 
важливим для адаптації та прискорення розробки. Чим швидший цикл зворотного 
зв’язку, тим швидше команда навчається, адаптується та доставляє робочий 
продукт [26]. Це дозволяє оптимізувати календарний план, забезпечити високу 
швидкість розробки та своєчасний вивід MVP у клієнтське середовище. 
 
2.4 Управління вартістю проєкту 
Управління вартістю є одним із ключових елементів успішної реалізації 
проєкту створення децентралізованої біржової платформи. Розробка DEX 
 
 39 
належить до високотехнологічних проєктів, що вимагають значних трудових, 
інфраструктурних та фінансових ресурсів. Як зазначає Стів Макконел, вартісні 
параметри складних програмних продуктів формуються під впливом технічної 
складності, зовнішніх залежностей і високої невизначеності середовища розробки 
[27].  Основними статтями витрат виступають оплата праці команди, забезпечення 
хмарної інфраструктури, використання сторонніх сервісів, технічних провайдерів, 
а також проведення зовнішнього аудиту смартконтрактів – обов’язкового етапу для 
проєктів Web3. 
Формування бюджету здійснювалося з урахуванням тривалості розробки у 
вісім місяців та необхідності підтримки безперервного циклу CI/CD, тестування та 
релізів. Особливу увагу приділено витратам на інфраструктуру AWS, адже вона 
забезпечує продуктивність, масштабованість та безпеку, що є критично важливими 
для роботи DEX. 
До матеріальних ресурсів віднесено переважно хмарні потужності, оскільки 
команда працює віддалено та використовує власні робочі станції. Значну частку 
бюджету формують витрати на RPC-провайдерів, аналітичні API та інтеграційні 
сервіси (LiFi, Moralis, Alchemy, CoinGecko тощо), які забезпечують коректну 
маршрутизацію, ончейн-взаємодію та доступ до ринкових даних. Додатково 
враховано резерв непередбачених витрат і вартість зовнішнього аудиту 
смартконтрактів, що суттєво впливає на рівень безпеки протоколу та довіру 
користувачів. 
У результаті було сформовано комплексний бюджет, який охоплює всі 
основні статті витрат та забезпечує реалістичну фінансову модель для запуску MVP 
та подальшої експлуатації платформи. Такий підхід дозволяє ефективно 
контролювати витрати, прогнозувати майбутні фінансові потреби та приймати 
обґрунтовані управлінські рішення. 
 2.4.1 Грошова винагорода команді. 
Загальна винагорода команді за 8 місяців роботи становить 13 280 000 грн. 
Більш детально зображено на таблиці 2.1 
 
 
 40 
Таблиця 2.1 
Грошова винагорода команді 
Роль К-сть Ставка / міс (грн) Всього / міс (грн) Всього за 8 міс (грн) 
Project Manager 1 90 000 90 000 720 000 
Product Manager 1 100 000 100 000 800 000 
Backend 
2 180 000 360 000 2 880 000 
Developer/Lead 
Frontend 
2 150 000 300 000 2 400 000 
Developer/Lead 
Blockchain 
2 200 000 400 000 3 200 000 
Developer/Lead 
QA Engineer 1 120 000 120 000 960 000 
DevOps Engineer 1 180 000 180 000 1 440 000 
UI/UX Designer 1 90 000 90 000 720 000 
HR/Recruiter 1 20 000 20 000 160 000 
 
2.4.2. Податки та збори  
Таблиця 2.2 
Витрати на податки (на основі фонду 13 280 000 грн) 
Стаття Формула Сума (грн) 
ЄСВ (22%) 13 280 000 × 0.22 2 921 600  
ПДФО (18%) 13 280 000 × 0.18 2 390 400  
Військовий збір (1.5%) 13 280 000 × 0.015 199 200  
 
Загальні витрати на податки, на основі фонду 13 280 000 грн – 5 511 200 грн. 
 
 
2.4.3 Хмарна інфраструктура 
 
 41 
Таблиця 2.3 
Витрати на хмарну інфраструктуру 
Категорія Сума (грн) 
AWS EC2 / ECS / Kubernetes 360 000 
AWS RDS PostgreSQL 120 000 
AWS S3 40 000 
CloudFront + Shield + ALB 80 000 
CloudWatch + Sentry 60 000 
DevOps інструменти 40 000 
 
Загальні витрати на хмарну інфраструктуру – 700 000 грн. 
 
2.4.4 Провайдери, інтеграції, API, аудит. 
Таблиця 2.4 
Витрати на інтеграції та провайдерів 
Сервіс Сума (грн) 
RPC (Alchemy / Moralis) 120 000 
Інтеграції LiFi, Reown, CoinGecko 80 000 
Аналітичні API 40 000 
Аудит смартконтрактів 300 000 
 
Загальні витрати на провайдерів, інтеграції, API та аудит становлять – 540 000 грн. 
 
 
 
2.4.5 Інші витрати та резерв 
 
Таблиця 2.5 
 
 42 
Резерв та інші витрати 
Витрата Сума (грн) 
Навчання, документація, консультації 115 000 
Маркетинг і запуск MVP 350 000 
Корпоративні аккаунти Google, Slack, ClickUp 123 600 
Резерв 1 435 000 
Резерв складає 7% від решти витрат. 
 
2.4.6 Фінальний бюджет 
Таблиця 2.6 
Загальний бюджет 
Категорія Сума (грн) 
Зарплата команди 13 280 000 
Податки та збори 5 511 200 
Хмарна інфраструктура 700 000 
Інтеграції, провайдери та аудит 540 000 
Інші витрати 588 600 
Резервний фонд 1 443 386 
 
Фінальна сума складає 22 063 186 грн. 
 
2.5 Управління якістю проєкту 
Управління якістю у процесі розробки DEX-платформи спрямоване на 
забезпечення відповідності продукту визначеним вимогам, стандартам безпеки та 
очікуванням користувачів. Система якості охоплює планування, організацію та 
контроль якості протягом усього життєвого циклу розробки, включаючи створення 
 
 43 
архітектури, програмування, інтеграцію зовнішніх сервісів, тестування та 
підготовку до запуску. Як слушно зазначає Майк Кон, якість – це не разова дія, а 
звичка, інтегрована в кожен етап процесу розробки: від планування та дизайну до 
тестування і розгортання  [28].  
Критерії якості визначаються за основними характеристиками продукту. 
Перш за все оцінюється продуктивність – швидкість виконання обмінів та 
маршрутизації, стабільність API й мінімізація затримок бекенд-сервісів. Важливо, 
щоб користувач отримував результат оперативно й без збоїв, що особливо 
критично для децентралізованих фінансових систем. 
Другим важливим аспектом є безпека. DEX обробляє криптоактиви та 
інтегрується зі сторонніми гаманцями, тому необхідно гарантувати захист даних, 
надійність підпису транзакцій, відсутність уразливостей у внутрішніх сервісах та 
стійкість до зовнішніх атак. 
Якість смартконтрактів також має значний вплив на надійність системи. 
Смартконтракти піддаються різноманітним вразливостям, які в разі експлуатації 
можуть призвести до значних фінансових втрат [16]. Навіть за відсутності пулів 
ліквідності мінімальна логіка маршрутизації та валідації повинна бути захищеною 
від переповнень та маніпуляцій. Використання стандартів SWC та проведення 
зовнішнього аудиту знижують ризики експлуатації вразливостей. 
UX/UI стосується зручності, зрозумілості й прозорості взаємодії користувача 
з платформою. Інтерфейс повинен надавати повну інформацію про транзакцію, 
попереджати про ризики та забезпечувати передбачувану поведінку. Як зазначає 
Дональд Норман, хороший дизайн настільки точно відповідає потребам 
користувача, що стає фактично непомітним [29], що особливо важливо для 
складних фінансових Web3-інтерфейсів. 
Надійність бекенд- і фронтенд-частини визначається стабільністю роботи 
сервісів, коректною обробкою помилок, високим uptime та здатністю системи 
відновлюватися після збоїв. У наукових дослідженнях підкреслюється, що 
продуктивність є фундаментальним обмеженням блокчейн-рішень, оскільки 
пропускна здатність та затримки безпосередньо впливають на якість роботи DEX 
 
 44 
[30]. Також важливо забезпечити масштабованість, оскільки навантаження на DEX 
може суттєво коливатися. 
 
Таблиця 2.7 
Метрики та цільові значення 
Категорія Метрика Цільове значення 
Продуктивність Час виконання обміну ≤ 2 секунди середньо 
Затримка API ≤ 150 мс 
Uptime бекенду ≥ 99.5% 
Час маршрутизації ≤ 1 секунда 
через LiFi 
Безпека Кількість критичних 0 
вразливостей 
Успішність 100% без критичних 
зовнішнього аудиту зауважень 
Виявлення аномалій ≤ 0.1% запитів 
(DevOps/Sentry) 
Смартконтракти Reentrancy, overflow, Відсутні 
MEV-ризики 
Покриття тестами ≥ 90% 
UX/UI Показник відмов (% ≤ 5% 
користувачів, що 
покинули обмін) 
Час завантаження ≤ 1 секунда 
сторінки 
Надійність Час відновлення після ≤ 10 хв 
збою 
Втрата даних 0 
Інтеграції Успішність викликів ≥ 99% 
зовнішніх API 
 
Проаналізовані ключові показники якості DEX-платформи дозволяють 
визначити конкретні метрики, за якими оцінюється продуктивність, безпека, 
надійність, UX/UI та стабільність інтеграцій. Проте для ефективного управління 
якістю недостатньо лише встановити цільові значення – важливо розуміти, які 
саме фактори можуть призвести до їх невиконання. 
Після формування таблиці показників наступним кроком є виявлення та 
систематизація причин, що здатні негативно вплинути на якість продукту. У 
 
 45 
межах аналізу були розглянуті основні групи чинників: людські фактори, 
внутрішні процеси, технологічні ризики, інструменти, вимоги та зовнішні 
інтеграції. Кожна з цих категорій може створювати окремий набір ризиків, які у 
підсумку формують потенційні дефекти платформи та відхилення від 
запланованих метрик. 
Таке структурування причин дозволяє чіткіше зрозуміти природу можливих 
проблем, оцінити їхній вплив на систему та визначити пріоритети для 
запровадження превентивних заходів. Нижче наведено узагальнену модель, що 
демонструє, як різні категорії чинників можуть сприяти виникненню потенційних 
дефектів у DEX-платформі. Список потенційних дефектів зображено на рис 2.5. 
 
 
Рисунок 2.5 – Діаграма Ісікави - потенційні дефекти DEX 
 
 
 
2.6 Управління інформаційним зв’язком та комунікаціями 
Ефективна система комунікацій забезпечує узгодженість дій між усіма 
учасниками DEX-проєкту та створює прозоре середовище для прийняття рішень. З 
огляду на складність Web3-інфраструктури, інтеграції з зовнішніми сервісами та 
мультидисциплінарність команд, правильно організована комунікація є критично 
 
 46 
важливою для стабільної та передбачуваної розробки. Ефективність команди 
фундаментально залежить від дисциплінованої комунікації, спільного розуміння та 
безперервної координації [31]. 
У проєкті застосовується набір перевірених каналів взаємодії. Slack 
використовується як основний інструмент оперативного внутрішнього 
спілкування, що дозволяє швидко вирішувати робочі питання та координувати дії 
між командами. Для планування, ведення задач та контролю прогресу 
використовується ClickUp, який забезпечує структурованість процесу розробки, 
прозорість пріоритетів та можливість повноцінного спринт-менеджменту. GitHub 
виконує роль централізованої платформи для роботи з кодом – включно з 
репозиторіями, pull request-процесом, code review та CI/CD автоматизацією. 
Проведення зустрічей, технічних дискусій та презентацій функціоналу 
здійснюється через Google Meet, а підготовка документації, аналітики та описів – у 
Google Docs/Sheets/Drive. 
Комунікаційний цикл підтримується регулярними активностями, які 
забезпечують передбачуваність і ритмічність роботи. Щоденні стендапи 
дозволяють синхронізувати команди щодо поточного статусу задач і виявити 
блокери. Щотижневі синхронізації узгоджують прогрес у межах функціональних 
команд, допомагають виявляти міжкомандні залежності та коригувати пріоритети. 
Після завершення спринтів проводяться демо-сесії, де команда презентує 
реалізований функціонал та отримує зворотний зв’язок. Планування спринтів 
визначає обсяг задач на наступний період, а технічні рев’ю спрямовані на оцінку 
архітектурних рішень, оптимізацію підходів і контроль якості коду. 
Окремий напрям – комунікація з інвесторами та зовнішніми стейкхолдерами. 
Її метою є забезпечення прозорості, демонстрація виконаних результатів та 
підтримка довіри до проєкту. У рамках цього підходу команда готує місячні, 
квартальні звіти, що містять дані про прогрес, фінансові показники, ризики, 
досягнуті цілі. Крім того, інвесторам надаються короткі аналітичні огляди та 
оновлення дорожньої карти, які дозволяють відстежувати зміну пріоритетів і 
планувати подальші кроки проєкту. 
 
 47 
Таким чином, система управління комунікаціями у DEX-проєкті ґрунтується 
на структурованих каналах зв’язку, регулярній координації між командами та 
прозорій взаємодії зі стейкхолдерами, що забезпечує контрольовану та 
передбачувану реалізацію продукту. Комунікація в команді представлена 
схематично на рис. 2.6. 
 
Рисунок 2.6 – Схема комунікації в команді 
 
2.7 Управління ризиками 
Управління ризиками є важливою складовою розробки DEX-платформи, 
оскільки проєкт функціонує у середовищі з підвищеною технологічною та 
операційною невизначеністю. Для забезпечення стабільності, безпеки та 
передбачуваності розвитку системи необхідно заздалегідь визначити потенційні 
загрози, що можуть вплинути на терміни, бюджет, функціональність або прийняття 
продукту користувачами. 
Технічні ризики пов’язані зі складністю Web3-інфраструктури та залежністю 
від багатьох взаємодіючих компонентів – серверів, бекенд-модулів, блокчейн-
мереж та сторонніх API. Збої в роботі інфраструктури, невдалий вибір технологій 
 
 48 
або помилки інтеграції можуть призвести до зупинки сервісів, ускладнень під час 
масштабування або зниження продуктивності. Особливо критичними є ризики, 
пов’язані з роботою зовнішніх провайдерів, адже їхня нестабільність 
безпосередньо впливає на якість роботи DEX. 
Організаційні ризики стосуються роботи команди, процесів та управління 
проєктом. До них належать можливі затримки виконання задач, неповна або 
неточна оцінка обсягів робіт, недостатня кваліфікація окремих спеціалістів, а також 
ризики, пов’язані з комунікацією між командами. У Web3-проєктах ці фактори 
особливо впливають на злагодженість роботи через високу залежність між 
фронтендом, бекендом, DevOps та інтеграційним шаром. 
Фінансові ризики пов’язані з невідповідністю фактичних витрат 
запланованому бюджету, можливими непередбаченими витратами на 
інфраструктуру чи аудит, а також імовірними затримками у фінансуванні. Оскільки 
проєкт передбачає роботу з дорогими сервісами, такими як AWS, аудит 
смартконтрактів чи преміальні API-провайдери, відсутність фінансової 
стабільності може зупинити ключові етапи розробки. 
Соціальні ризики виникають на етапі взаємодії з користувачами та ринком. 
Невдалий UX/UI, низький рівень довіри або недосконалі бізнес-процеси можуть 
зменшити активність користувачів і негативно вплинути на сприйняття платформи. 
Такі ризики необхідно враховувати заздалегідь, оскільки Web3-аудиторія є 
чутливою до стабільності сервісу, прозорості та зручності використання. 
Юридичні ризики пов’язані з регуляторними вимогами, які постійно 
змінюються у сфері криптоактивів. Невідповідність нормам захисту даних, 
фінансового регулювання чи антифрод-політик може призвести до штрафів або 
обмежень у роботі продукту. Важливо забезпечити відповідність юридичним 
вимогам з самого початку, щоб уникнути подальших переробок або юридичних 
наслідків. 
Системне визначення ризиків у цих категоріях дозволяє заздалегідь оцінити 
їхній вплив, сформувати плани реагування та мінімізації, а також побудувати 
цілісну систему контролю ризиків. Усі виявлені ризики разом із їхніми 
 
 49 
характеристиками, оцінками та стратегіями управління наведені у зведеній таблиці 
2.8. 
Таблиця 2.8 
Управління ризиками та їх вирішення 
Категорія Ризик Ймовірність Вплив Risk План реагування 
Score 
Технічні Збої в роботі 30% 4 120 Перемикання на 
серверного резервні 
обладнання інстанси 
 
Невдалий 25% 5 125 Рефакторинг, 
вибір заміна бібліотек 
технологій  
Організаційні Невчасна 40% 3 120 Пріоритизація, 
 реалізація розблокування 
етапів задач 
 
Недостатня 35% 4 140 Залучення 
кваліфікація експертів 
команди  
Фінансові Перевищення 20% 5 100 Перегляд 
бюджету функціоналу, 
оптимізація 
 
Затримка 30% 4 120 Заморозка non-
фінансування critical задач 
 
Соціальні Супротив 25% 3 75 Хотфікси, 
користувачів комунікація 
 
Юридичні Невідповідніс 15% 5 75 Впровадження 
ть KYC/AML 
законодавству  
 
2.8 Взаємодія компонентів системи 
 Взаємодія компонентів системи DEX-платформи побудована таким чином, 
щоб фронтенд, бекенд, смартконтракти, інтеграції та інфраструктура AWS 
працювали як єдиний узгоджений комплекс. Фронтенд взаємодіє з бекендом через 
HTTP/HTTPS-запити (REST або GraphQL), відповідає за відображення інтерфейсу, 
 
 50 
відправку даних користувача, формування параметрів свопу чи бриджу та 
отримання агрегованої інформації від серверної частини. На цьому рівні 
реалізуються маршрутизація запитів, базова авторизація користувача та валідація 
даних перед їх передачею на бекенд. 
Бекенд, у свою чергу, виступає оркестратором бізнес-логіки: опрацьовує 
запити від фронтенду, звертається до бази даних, розраховує маршрути свопів і 
бриджів, а також взаємодіє зі смартконтрактами через web3-провайдери. Саме 
бекенд формує й надсилає транзакції в блокчейн, використовуючи підпис із боку 
користувача або службових ключів (де це передбачено архітектурою), та відстежує 
статус виконання операцій swap/bridge у мережі. 
Смартконтракти взаємодіють з інтеграційним шаром через зовнішні 
протоколи та сервіси, такі як агрегуючі протоколи ліквідності, ончейн-оракули, 
мультичейнові маршрутизатори. Ці компоненти забезпечують доступ до 
зовнішньої ліквідності, отримання актуальних цінових даних, побудову складних 
маршрутів між мережами та використання сторонньої інфраструктури без 
необхідності тримати власні великі пули ліквідності. Розподілені системи виграють 
від роз’єднаної взаємодії сервісів, що дозволяє масштабувати компоненти 
незалежно та оптимізувати пропускну здатність системи [32] 
Бекенд розгортається та масштабуються за допомогою сервісів AWS: EC2 
використовується для запуску серверних компонентів, RDS – для керування базою 
даних, API Gateway – для публікації API, Lambda – для виконання окремих 
безсерверних задач, а інші сервіси AWS відповідають за балансування 
навантаження, безпеку та логування. Таким чином забезпечується гнучкий деплой, 
автоматичне масштабування та стійкість до збоїв. 
Моніторинг та спостережуваність реалізуються через системи на кшталт 
Sentry або Kibana, які збирають інформацію про помилки, затримки, аномалії в 
роботі фронтенду та бекенду. Це дозволяє оперативно виявляти проблеми, 
аналізувати причини інцидентів і підтримувати стабільний рівень якості 
платформи. 
 
 
 51 
2.9 Управління персоналом 
Управління персоналом у межах розробки DEX-платформи є одним із 
визначальних факторів успішності проєкту, оскільки якість кінцевого продукту 
безпосередньо залежить від компетентності, злагодженості та мотивації команди. 
Цей процес охоплює планування кадрових потреб, організацію роботи фахівців, 
формування чітких ролей і відповідальностей, а також розвиток команди протягом 
усього життєвого циклу проєкту. 
Одним з основних етапів є найм спеціалістів, необхідних для реалізації 
функціональних модулів DEX. Проєкт вимагає таких ключових ролей, як 
blockchain-розробники, backend-та frontend-інженери, DevOps-фахівці, QA-
інженери, дизайнери інтерфейсів, а також менеджери, які забезпечують 
координацію та стратегічний розвиток платформи. Підбір персоналу орієнтований 
на досвід у Web3-технологіях, роботу з мультичейновими системами та розуміння 
безпекових вимог. 
Наступним важливим компонентом є чітке визначення ролей і зон 
відповідальності. Кожен учасник команди повинен розуміти свої задачі: від 
створення архітектури та реалізації бізнес-логіки до тестування, деплою та 
спостереження за стабільністю сервісів. Такий розподіл дозволяє уникнути 
дублювання функцій та підвищує ефективність взаємодії між групами, зокрема між 
FE, BE, DevOps та QA. Команди з високою продуктивністю досягають кращих 
результатів не за рахунок збільшення годин роботи, а завдяки поліпшенню 
співпраці, зменшенню передавань між ролями та наданню фахівцям більшої 
автономії у прийнятті рішень [33].  
Особливу увагу приділено балансу навантаження. Робота над DEX-
платформою включає паралельні процеси, інтеграції та безперервне тестування, 
тому важливо забезпечити оптимальний розподіл задач між членами команди. Це 
дозволяє підтримувати стабільний темп розробки, мінімізувати професійне 
вигорання та уникнути перевантаження під час інтенсивних релізів. 
Мотиваційна складова також відіграє значну роль. До мотиваційних 
інструментів можуть належати бонуси за результатами виконаних етапів, 
 
 52 
винагороди за відсутність критичних дефектів, а також моделі участі в успіху 
продукту (performance bonuses). Це стимулює команду до підвищення якості та 
швидкості реалізації функціональних модулів. Психологічна безпека дає змогу 
командам швидше навчатися, ефективніше співпрацювати та знижувати вартість 
помилок завдяки створенню середовища, у якому люди можуть висловлюватися 
без страху [33]. 
Основні обов’язки відповідно до позиції представлено в Таблиці 2.9 
 
Таблиця 2.9 
Основні обов’язки відповідно до позиції 
Роль Основні обов’язки 
Планування робіт, керування строками та бюджетом, 
Project Manager 
комунікація між командами та зі стейкхолдерами. 
Формування бачення продукту, пріоритизація 
Product Manager функціональних модулів, управління вимогами, 
користувацькі сценарії. 
Реалізація UI, інтеграція WalletConnect/Reown, робота з 
Frontend Developer 
Wagmi/Viem та API бекенду. 
Побудова API, інтеграція з LiFi/Moralis/Alchemy, 
Backend Developer 
реалізація бізнес-логіки, робота з БД. 
Розробка Solidity-контрактів, аудит логіки, оптимізація 
Blockchain Developer 
газу, інтеграція з backend. 
Побудова CI/CD, інфраструктура AWS, моніторинг, 
DevOps Engineer 
управління контейнерами. 
Написання тест-кейсів, E2E-тестування DEX, валідація 
QA / Web3 QA Engineer 
транзакцій, тестування інтеграцій. 
UI/UX Designer Дизайн інтерфейсу, прототипування, дизайн-система. 
 
 53 
Роль Основні обов’язки 
Найм спеціалістів, координація онбордингу, HR-
HR / Recruiter 
процеси. 
Технічні консультанти Експертний аналіз архітектурних рішень, оцінка ризиків, 
(за потреби) аудит технологій. 
 
Для вимірювання ефективності роботи персоналу застосовуються KPI, 
зокрема: швидкість доставки функціоналу, якість коду та результатів тестування, 
кількість знайдених і виправлених дефектів, стабільність сервісів  і відповідність 
релізів запланованим термінам. Використання цих показників дозволяє 
контролювати продуктивність команди та своєчасно виявляти потреби в 
оптимізації процесів чи додатковому навчанні. 
Таким чином, управління персоналом у проєкті DEX включає комплекс 
заходів, спрямованих на формування професійної, мотивованої та ефективної 
команди, здатної забезпечити високу якість продукту та його 
конкурентоспроможність у середовищі Web3-технологій. 
 
Висновки до Розділу 2 
У другому розділі було сформовано системне бачення організації та 
управління проєктом зі створення мультичейнової DEX-платформи. Визначено 
зміст проєкту, його функціональні межі та побудовано WBS, що дало змогу 
структурувати роботи та встановити логічну послідовність виконання завдань. 
Сформовано RBS-структуру, яка окреслює всі типи ресурсів – трудові, 
матеріальні, технологічні, інформаційні та фінансові. Визначено склад команди, 
ролі учасників та принципи взаємодії. У межах управління часом розроблено 
деталізовану діаграму Ганта, що враховує паралельність робіт між 
функціональними командами та встановлює залежності між ключовими етапами. 
Здійснено оцінку вартості проєкту на 8 місяців, включно з витратами на 
персонал, інфраструктуру, аудит, інтеграційні сервіси та резервними фондами. 
 
 54 
Визначені критерії якості продукту та проведений причинно-наслідковий аналіз 
дозволили окреслити ключові фактори, що впливають на продуктивність, безпеку, 
UX/UI та надійність системи. 
Окремо розглянуто комунікаційні процеси та встановлено канали взаємодії 
між командами й інвесторами. Проведена ідентифікація ризиків та побудована 
матриця їх оцінювання дали змогу визначити найбільш критичні загрози та заходи 
щодо їх мінімізації. 
Узагальнюючи, другий розділ формує повний структурований план 
управління проєктом, який забезпечує контрольованість, передбачуваність та 
ефективну координацію робіт у процесі створення DEX-платформи. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 55 
РОЗДІЛ ІІІ Оцінка економічної ефективності проєкту 
3.1 Планування фінансових ресурсів інвестиційної фази IT-проєкту 
 Формування фінансової моделі проєкту повинно враховувати структуру 
фінансових потоків та специфіку інвестиційної фази. У науковій літературі 
підкреслюється, що фінансові результати підприємства формуються в процесі 
основної, операційної, інвестиційної та фінансової діяльності [34], що повністю 
узгоджується з логікою створення DEX-платформи, де інвестиційна фаза охоплює 
витрати на розробку, інфраструктуру, аудит і інтеграції. Саме цей комплекс витрат 
формує первинну фінансову базу майбутньої операційної діяльності та забезпечує 
здатність платформи генерувати дохід після запуску. 
Інвестиційна фаза розробки DEX-платформи охоплює період активних робіт 
тривалістю вісім місяців і включає витрати на оплату праці команди, 
інфраструктуру, інтеграції, аудит смартконтрактів, корпоративні сервіси та інші 
супутні потреби. Загальний обсяг фінансових ресурсів, необхідних для виконання 
проєкту, становить 22,06 млн грн. Узагальнена таблиця поточних фінансових 
потреб наведена у табл. 3.1. 
Таблиця 3.1  
Поточні фінансові потреби інвестиційної фази DEX-проєкту 
Місяць Потреба у фінансуванні, грн 
1 2 491 850 
2 2 491 850 
3 2 487 850 
4 2 551 850 
5 2 551 850 
6 2 651 850 
7 2 721 850 
8 4 114 236 
Разом 22 063 186 
 
 56 
 
Витрати поступово зростають через збільшення обсягу розробки, інтеграції 
та DevOps-активностей, а в останній місяць значно підвищуються у зв’язку з 
проведенням зовнішнього аудиту та завершальними роботами. Накопичені 
потреби показані у таблиці 3.2. 
Таблиця 3.2  
Накопичені витрати 
Місяць Накопичена потреба, грн 
1 4 114 236 
2 4 983 700 
3 7 470 550 
4 10 022 400 
5 12 574 250 
6 15 226 100 
7 17 947 950 
8 22 063 186 
 
Оскільки весь обсяг кредиту залучається одразу, відсотки починають 
нараховуватися на повну суму з першого місяця. 
При ставці 13% річних: 
- Щомісячний відсоток = 0,13/12 = 0,0108333 = 1,08333% 
- Відсотки за місяць = 22,063,186 * 0,0108333 =  238,278 грн 
Вцілому, дані наведені вище формують собою графік інвестиційної фази проєкту. 
 
3.2 Оптимізація плану фінансування інвестиційної фази проєкту 
Оптимізація фінансування інвестиційної фази є важливою умовою 
зменшення вартості капіталу та забезпечення стійкості реалізації проєкту. З огляду 
 
 57 
на значний обсяг початкових витрат та повну відсутність доходів у перші місяці, 
доцільно порівняти два підходи до залучення кредитних ресурсів: 
 1. Залучення повної суми кредиту на початку реалізації проєкту. 
 2. Траншове фінансування відповідно до графіка витрат із покриттям 
відсотків інвесторами та кредитними канікулами. 
Мета оптимізації –  мінімізувати сумарні витрати на обслуговування кредиту та 
забезпечити рівномірне фінансове навантаження протягом розробки. 
У базовому сценарії передбачається, що підприємство залучає повну суму 
кредиту (22,06 млн грн) одразу в першому місяці. При цьому: 
• відсотки нараховуються на всю суму кредиту протягом усієї інвестиційної 
фази; 
• у перші 8 місяців проєкт не генерує доходів, але повинен сплачувати 
нараховані відсотки; 
• фактична вартість кредиту є максимальною, оскільки тіло позики залучається 
повністю незалежно від фактичних потреб. 
Такий підхід є найменш ефективним, адже призводить до надмірної 
переплати за користування кредитними ресурсами. Умовно, при ставці 13 % річних 
витрати на обслуговування кредиту за перші 8 місяців становлять значну частку 
бюджету, що зменшує інвестиційну привабливість проєкту 
 Що стосується траншового фінансування з покриттям відсотків інвесторами 
та кредитними канікулами, то у цьому підході кредитні кошти залучаються 
частинами, відповідно до помісячного графіка потреб у фінансуванні. Це дозволяє: 
- зменшити суму залученого капіталу на ранніх етапах; 
- відповідно, зменшити базу для нарахування відсотків; 
- оптимізувати навантаження на фінансові ресурси. 
У межах оптимізованої моделі фінансування інвестиційної фази проєкту 
застосовується траншовий принцип залучення кредитних коштів, що означає 
отримання лише тієї суми, яка фактично необхідна в кожному конкретному місяці 
відповідно до графіка потреб у фінансуванні. Такий підхід дозволяє уникнути 
 
 58 
передчасного накопичення боргу та значно скорочує обсяг нарахованих відсотків 
у порівнянні з моделлю одноразового повного залучення кредиту. 
Оскільки протягом перших восьми місяців розробки проєкт не генерує 
доходи, виплата відсотків у цей період покривається за рахунок інвестиційного 
капіталу зовнішніх інвесторів. Це забезпечує безперервність фінансування та 
дозволяє уникнути дефіциту оборотних коштів, не створюючи додаткового 
навантаження на команду і не перериваючи процес розробки. Одночасно в 
інвестиційний період запроваджуються кредитні канікули щодо погашення 
основної суми боргу: компанія не здійснює виплати тіла кредиту до завершення 
восьмимісячної фази. Таке рішення дозволяє спрямувати всі доступні ресурси на 
створення продукту, забезпечити фінансову стійкість і зменшити ризик 
неспроможності виконувати боргові зобов’язання на етапі, коли бізнес ще не є 
прибутковим. 
Завдяки траншовому характеру фінансування та відтермінуванню погашення 
основної суми кредиту загальна вартість фінансового ресурсу суттєво знижується. 
Відсотки нараховуються лише на фактично отримані кошти, що робить модель 
значно ефективнішою та економічно доцільною порівняно з форматом 
одноразового кредитування на повну суму ще до початку робіт. Порівняння  
нарахованих відсотків різних моделей можна побачити на таблиці 3.3. 
 
Таблиця 3.3 
Порівняння нарахованих відсотків за перші 8 місяців 
Процентна база Нараховані Процентна база Нараховані 
Місяць Модель А (повна відсотки Модель B відсотки 
сума) Модель А (транші) Модель B 
1 22 063 186 грн 238 690 грн 2 491 850 грн 26 997 грн 
2 22 063 186 грн 238 690 грн 4 983 700 грн 53 994 грн 
3 22 063 186 грн 238 690 грн 7 470 550 грн 80 870 грн 
4 22 063 186 грн 238 690 грн 10 022 400 грн 108 067 грн 
 
 59 
Процентна база Нараховані Процентна база Нараховані 
Місяць Модель А (повна відсотки Модель B відсотки 
сума) Модель А (транші) Модель B 
5 22 063 186 грн 238 690 грн 12 574 250 грн 136 245 грн 
6 22 063 186 грн 238 690 грн 15 226 100 грн 165 044 грн 
7 22 063 186 грн 238 690 грн 17 947 950 грн 194 341 грн 
8 22 063 186 грн 238 690 грн 22 063 186 грн 238 357 грн 
 
Загальна економія при використанні траншової моделі складає 905 608 грн.  
Порівняння двох моделей по різних показниках наведені у Таблиці 3.4 
 
Таблиця 3.4 
Порівняння двох моделей 
Повне залучення 
Показник Траншове фінансування 
кредиту 
Обсяг залучених 
22,06 млн грн лише 2,49 млн грн 
коштів у 1-й місяць 
Відсотки за перші 8 максимальні, на всю мінімальні, на фактичну 
місяців суму заборгованість 
Погашення тіла з першого місяця після завершення інвестиційної 
кредиту після канікул фази 
Джерело сплати власні ресурси 
інвестиційний бюджет 
відсотків проєкту 
Фінансове 
навантаження в високе оптимізоване 
інвестиційний період 
Рівень ризику підвищений помірний 
 
 
 60 
3.3 Зведений кошторис планових витрат інвестиційної фази DEX-проєкту 
Формування зведеного кошторису витрат інвестиційної фази проєкту 
здійснюється на основі детального прогнозу витрат за всіма процесами розробки 
DEX-платформи та розрахованої загальної суми виплат процентів за кредит (за 
оптимізованою моделлю фінансування – траншовим залученням коштів та оплатою 
відсотків інвесторами у перші 8 місяців).  
Зведений кошторис є окремим планово-фінансовим документом, що 
визначає обсяг інвестиційних ресурсів, необхідних для реалізації всіх робіт, 
пов’язаних із створенням DEX-платформи, включаючи витрати на розробку, 
інфраструктуру, аудит, інтеграції, маркетинг та супутні організаційні процеси. 
Документ затверджується керівником проєкту та є ключовою основою для 
подальшого бюджетного контролю (Таблиця 3.5). 
 
“Затверджую” 
Керівник проєкту ___________________ 
Підпис ______________ 
Дата «___»___________2025 р. 
 
Таблиця 3.5 
Зведений кошторис 
планових витрат інвестиційної фази DEX-проєкту 
№ п/п Стаття витрат Шифр Сума, тис. грн 
1 Зарплата команди SAL 13 280,0 
2 Податки та обов’язкові збори TAX 5 511,2 
3 AWS EC2 / Kubernetes-кластери INF1 350,0 
4 AWS RDS (база даних) INF2 120,0 
5 AWS S3 та резервне копіювання INF3 80,0 
6 CDN, WAF, мережеві сервіси INF4 70,0 
7 Моніторинг та логування INF5 80,0 
8 LiFi інтеграція (API) INT1 80,0 
9 Moralis / Web3 API INT2 60,0 
10 Alchemy RPC-провайдер INT3 60,0 
11 Reown / WalletConnect INT4 20,0 
12 CoinGecko API INT5 20,0 
 
 61 
13 Аудит смартконтрактів INT6 300,0 
14 Навчання, консультації OTH1 115,0 
15 Маркетинг та запуск MVP OTH2 350,0 
16 Корпоративні акаунти Google/Slack/ClickUp OTH3 123,6 
17 Інші операційні витрати OTH4 8,39 
18 Резервний фонд (7%) RSV 1 435,0 
19 Відсотки за кредит (13 %, траншове фін.) CRP 1 003,9 
 Всього витрат K 23 067,1 
 
 
Розрахунок виконав бухгалтер-економіст проєкту ___________________ 
 
Зведений кошторис інвестиційної фази проєкту є фінансовою основою 
успішної реалізації DEX-платформи. Він охоплює всі ключові напрями витрат, 
дозволяє контролювати використання ресурсів та формує базу для оптимізації 
фінансування. Врахування траншового механізму кредитування зменшило 
загальну суму процентних витрат на понад 900 тис. грн, що позитивно впливає на 
економічну ефективність проєкту та підвищує інвестиційну привабливість. 
 
3.4 Прогнозування показників операційної діяльності 
Метою даного підрозділу є визначення та кількісне прогнозування 
показників операційної діяльності DEX-платформи на перспективу десяти років. 
Прогнозування дозволяє оцінити майбутні доходи, витрати, операційний 
результат, а також здатність проєкту забезпечувати погашення кредитних 
зобов’язань та формувати прибуток. 
Оскільки DEX-платформа функціонує за принципом стягнення комісії з 
кожної транзакції, ключовими драйверами операційної діяльності є: 
середньодобовий обсяг транзакцій, 
• річна кількість транзакцій, 
• середня комісія за операцію, 
• операційні витрати  
• тенденція зростання/спаду активності користувачів. 
 
 62 
Активність користувачів може суттєво змінюватися залежно від ситуації на 
ринку, оскільки вона чутлива до макроекономічних подій, настроїв трейдерів та 
загальної динаміки крипторинку. Комісія також може як підвищуватися, так і 
знижуватися, залежно від завантаженості мережі, попиту на операції та загального 
настрою спільноти. Тому для побудови прогнозу використано різні сценарії 
зростання кількості транзакцій та варіації розміру комісії – залежно від часу, зміни 
ринкових умов та рівня впізнаваності платформи серед користувачів Web3. 
Прогноз показників та динаміки операційної діяльності показані у Таблиціях 3.6 
та 3.7 відповідно. 
Таблиця 3.6 
Прогноз показників операційної діяльності 
Показники Значення 
1. Середньорічний обсяг транзакцій (ТР), млн од. 1,35 млн 
2. Середня комісія за 1 транзакцію (К), грн 6 грн 
3. Прямі витрати на інфраструктуру на 1 транзакцію (М), 
1,20 грн 
грн 
4. Прямі витрати на оплату праці на 1 транзакцію (ОП), 
3,15 грн 
грн(у перерахунку з річного фонду зарплат) 
5. Постійні витрати операційної діяльності (ПВ), тис. грн 
7 245,00 тис. грн 
/ рік 
 
Таблиця 3.7 
Прогноз динаміки показників операційної діяльності 
Назва Показник 
1. ΔК – зростання комісії 1,05 
2. ΔМ – зміна собівартості транзакції 0,85 
3. ΔОП – зростання витрат на оплату праці 1,05 
4. ΔПВ – зростання операційних витрат 1,05 
 
 63 
 
На відміну від традиційних бізнес-моделей, де розрахунки виконуються для 
декількох пакетів послуг, DEX-платформа надає уніфікований вид операційної 
діяльності – обробку транзакцій користувачів. Тому прогноз формується для 
єдиного «пакета» послуги, що охоплює всі види транзакцій, які генерують комісію 
для платформи. 
Прогноз здійснено на 10 років операційної діяльності. У Таблиці 3.8 наведено 
основні вартісні показники, що застосовуються для подальших розрахунків 
операційних доходів і витрат проєкту. Зокрема, відображено динаміку зміни 
середньої комісії, собівартості інфраструктури, витрат на оплату праці та рівня 
постійних операційних витрат упродовж прогнозного періоду. 
Постійні операційні витрати подано у таблиці як сукупні для всієї платформи, 
оскільки вони не залежать від структури транзакцій і забезпечують безперервне 
функціонування DEX у цілому. Отримані показники використовуються в 
наступному етапі для розрахунку операційних доходів, витрат та визначення 
фінансових результатів діяльності проєкту за роками. 
Розраховані прогнозні значення вартісних показників операційної діяльності 
систематизовано у Таблиці 3.8. 
Таблиця 3.8 
Прогноз динаміки вартісних показників операційної діяльності DEX 
Ціна 
одиниці Собівартість Прямі витрати на Постійні 
Рік продукції інфраструктури (М₁), оплату праці (ОП₁), витрати (ПВₜ), 
грн/од. грн/од. грн/рік 
(fee), грн/од. 
1 6.00 5.37 1.02 7 245 000 
2 6.30 4.56 0.54 7 607 250 
3 6.62 3.88 0.51 7 987 612 
4 6.95 3.30 0.49 8 386 993 
 
 64 
Ціна Собівартість Прямі витрати на Постійні 
Рік одиниці інфраструктури (М₁), оплату праці (ОП₁), витрати (ПВₜ), 
продукції 
(fee), грн/од. грн/од. грн/од. грн/рік 
5 7.29 2.81 0.47 8 806 343 
6 7.66 2.39 0.49 9 246 660 
7 8.04 2.03 0.79 9 708 993 
8 8.44 1.73 1.28 10 194 443 
9 8.86 1.47 2.07 10 704 165 
10 9.30 1.25 3.34 11 239 373 
 
. Ціна одиниці продукції (fee) визначає середню комісію за одну транзакцію. 
Зміна цього показника у прогнозному періоді відображає загальну стратегію 
зростання вартості послуг та вплив ринкових умов. 
 Собівартість інфраструктури (М₁) показує витрати на обробку однієї 
транзакції. Значення зменшуються щороку відповідно до коефіцієнта ΔМ, що 
пояснюється ефектом масштабу та оптимізацією інфраструктурних витрат. 
 Прямі витрати на оплату праці (ОП₁) визначають частку витрат на персонал, 
яка припадає на одну транзакцію, у перерахунку з річного фонду оплати праці. 
Коливання величини ОП₁ обумовлені зміною обсягів транзакцій у різні роки. 
 Постійні витрати (ПВ) включають витрати на інфраструктуру, технічну 
підтримку та персонал, що забезпечує функціонування платформи, і зростають 
відповідно до прийнятого коефіцієнта ΔПВ. 
Отримані значення вартісних показників використовуються у подальших 
розрахунках операційних доходів, витрат та прогнозованого фінансового 
результату за роками проєкту. 
 
 
 
 65 
3.5 Планування амортизаційних витрат операційної діяльності 
У рамках DEX-платформи операційна діяльність здійснюється повністю в 
онлайн-середовищі та не потребує використання матеріальних основних засобів, 
які б перебували на балансі підприємства. 
Серверні ресурси та інфраструктура платформи надаються у вигляді хмарних 
сервісів (AWS), оплата яких здійснюється відповідно до моделі операційних витрат 
та не підлягає амортизації відповідно до вимог облікових стандартів. Також 
підприємство не має власних офісних приміщень або комп’ютерного обладнання: 
команда використовує особисті робочі станції, що виключає можливість їх обліку 
як основних засобів. 
Отже, у зв’язку з відсутністю матеріальних активів зі строком корисного 
використання понад один рік, амортизаційні витрати у складі операційних витрат 
DEX-платформи не формуються, а показник амортизації приймається рівним 0 грн 
протягом усього прогнозного періоду. 
 
3.6 Планування кредитних процесів операційної діяльності 
Фінансування інвестиційної фази розробки DEX-платформи здійснювалося 
за рахунок банківського кредиту, який надавався траншами протягом восьми 
місяців. Такий формат кредитування дав змогу покривати витрати поступово, 
відповідно до календарного графіка робіт, та уникнути неефективного залучення 
надмірного обсягу капіталу на ранніх етапах проєкту. Кредит було надано під 13% 
річних строком на п’ять років із траншовим механізмом видачі та пільговим 
періодом у перші вісім місяців, протягом якого компанія не здійснювала погашення 
тіла кредиту. Замість цього впродовж інвестиційної фази банк нараховував 
відсотки лише на фактичну суму виданих траншів, а всі ці відсоткові витрати 
повністю покривалися інвесторами, що дозволило не збільшувати фінансове 
навантаження на компанію до моменту запуску платформи. 
Загальна сума інвестиційних витрат становила 22 063 186 грн, і саме цей 
обсяг був профінансований кредитними коштами. Відсотки, нараховані протягом 
 
 66 
восьми місяців інвестиційної фази, склали 1 003 912 грн і не були включені до 
операційних витрат DEX-платформи, оскільки їх погашення здійснили інвестори. 
Після завершення інвестиційної фази розпочинається п’ятирічний період 
погашення кредиту. Для цього застосовано ануїтетну модель, яка забезпечує 
рівномірне навантаження на бюджет упродовж усього строку кредитування та 
дозволяє ефективно планувати грошові потоки. Особливістю такої моделі є 
поступове зменшення частки виплат за відсотками й відповідне збільшення частки 
погашення основної суми боргу з кожним наступним роком. Річний розмір 
ануїтетної виплати становить 6 273 000 грн, що забезпечує повне погашення 
кредиту протягом п’ятирічного періоду операційної діяльності. Графік погашення 
представлено на таблиці 3.9 та на рис. 3.1 
Таблиця 3.9 
Графік використання та повернення кредиту за роками діяльності 
Залишок на 
Відсотки Погашення Загальний Залишок на 
Рік початок року, 
(13%), грн тіла, грн платіж, грн кінець року 
грн 
1 22 063 186 2 868 214 3 404 786 6 273 000 18 658 400 
2 18 658 400 2 425 592 3 847 408 6 273 000 14 810 992 
3 14 810 992 1 925 429 4 347 571 6 273 000 10 463 421 
4 10 463 421 1 360 245 4 912 755 6 273 000 5 550 666 
5 5 550 666 721 586 5 551 414 6 273 000 0 
 
 67 
 
Рисунок 3.1 – Візуалізація виплат відсотків та тіла кредиту. 
 
3.7 Прогноз доходів операційної діяльності  
 Операційні доходи за роками операційної діяльності DEX-платформи 
визначаються запланованими обсягами обробки транзакцій та рівнем середньої 
комісії за одну операцію. Розрахунок річних сум доходів виконується для 10 років 
операційної фази проєкту як добуток середньорічної кількості транзакцій та 
середньої комісії за одну транзакцію. Отримані значення систематизовано в 
таблиці 3.10  
Таблиця 3.10 
Прогноз доходів операційної діяльності DEX 
Середньорічна кількість Середня комісія за 1 Річний дохід 
Рік транзакцій (TP), од. транзакцію (K), грн (Dₜ), грн 
1 1 350 000 6,00 8 100 000 
2 2 700 000 6,30 17 010 000 
3 3 270 000 6,62 21 647 400 
 
 68 
Рік Середньорічна кількість Середня комісія за 1 Річний дохід 
транзакцій (TP), од. транзакцію (K), грн (Dₜ), грн 
4 3 967 000 6,95 27 570 650 
5 4 293 700 7,29 31 301 073 
6 4 293 700 7,66 32 889 742 
7 2 335 905 8,04 18 780 676 
8 1 518 338 8,44 12 814 773 
9 986 820 8,86 8 743 225 
10 641 520 9,30 5 966 136 
 
З таблиці 3.10 видно, що у перші шість років проекту спостерігається стале 
зростання доходів DEX-платформи. Це зумовлено як збільшенням середньорічної 
кількості транзакцій, так і поступовим підвищенням середньої комісії відповідно 
до прогнозованого темпу зростання. 
Починаючи з 7-го року, передбачається скорочення обсягів транзакцій, що 
пов’язано з посиленням конкуренції, поступовим насиченням ринку та зниженням 
активності користувачів. Це призводить до зменшення річних доходів, попри 
подальше зростання рівня комісії. 
Таким чином, прогноз доходів відображає етап активного розширення DEX-
платформи протягом перших років, а далі – фазу стабілізації та поступового 
зниження операційної активності, що враховується при оцінці фінансових 
результатів і строків окупності проекту. 
 
3.8 Прогноз витрат операційної діяльності DEX-платформи 
 Операційні витрати DEX-платформи протягом t-го року операційної 
діяльності формуються з таких основних складових: 
 
 69 
• постійні операційні витрати (ВПₜ), які включають витрати на персонал, 
хмарну інфраструктуру (AWS, RPC, ноди, моніторинг, логування, CDN), 
сторонні сервіси та операційну підтримку; 
• витрати на повернення кредиту (ПКₜ) відповідно до графіка погашення 
ануїтетними платежами. 
На відміну від традиційних виробничих або сервісних підприємств, у 
діяльності DEX-платформи змінні витрати на обробку транзакцій є незначними, 
оскільки збільшення обсягів операцій не створює суттєвої додаткової собівартості. 
Хмарна інфраструктура масштабується автоматично та включена до складу 
постійних витрат. Таким чином, модель витрат включає лише дві групи: 
ОBt = ВПt + ПКt, де: 
ВПt – постійні витрати t-го року, грн; 
ПКt – виплати за кредитом у t-му році, грн (тільки роки 1–5). 
Щорічні постійні витрати визначені на основі базового рівня 7 245 000 грн та 
їхнього зростання на 5% щороку: 
ВПₜ = 7 245 000 × 1.05(t-1) 
Повернення кредиту здійснюється ануїтетними платежами упродовж п’яти років із 
річною виплатою: 
ПКₜ = 6 273 000  грн,    t = 1..5 
Для років 6–10 погашення кредиту завершено, тому ПКₜ = 0. 
Розраховані витрати подано у таблиці 3.11 
Таблиця 3.11 
Прогноз витрат операційної діяльності 
Постійні 
Рік витрати (ПВₜ), Повернення кредиту (ПКₜ), Разом операційні витрати 
грн (ОВₜ), грн 
грн 
1 7 245 000 6 273 000 13 518 000 
2 7 607 250 6 273 000 13 880 250 
3 7 987 612 6 273 000 14 260 612 
 
 70 
Постійні Повернення кредиту (ПКₜ), Разом операційні витрати 
Рік витрати (ПВₜ), грн (ОВₜ), грн 
грн 
4 8 386 993 6 273 000 14 659 993 
5 8 806 343 6 273 000 15 079 343 
6 9 246 660 0 9 246 660 
7 9 708 993 0 9 708 993 
8 10 194 443 0 10 194 443 
9 10 704 165 0 10 704 165 
10 11 239 373 0 11 239 373 
 
3.9 Прогноз грошових потоків операційної діяльності 
Прогнозний аналіз грошових потоків операційної діяльності DEX-
платформи виконується на основі зіставлення доходів та операційних витрат за 
роками цієї фази та дає змогу оцінити динаміку формування фінансового 
результату. Розрахунки проводяться для десятирічного горизонту, що забезпечує 
можливість визначити довгострокову фінансову стійкість проєкту. 
Операційні доходи формуються за рахунок комісій, що надходять від 
обробки транзакцій користувачів. Структура витрат включає постійні операційні 
витрати (зарплата персоналу, витрати на хмарну інфраструктуру, сторонні сервіси 
та технічну підтримку), а також виплати за кредитом протягом перших п’яти років 
реалізації проєкту. 
Оскільки DEX-платформа не має матеріальних основних засобів, 
амортизаційні відрахування у проєкті не формуються, тому прибуток до 
оподаткування дорівнює балансовому прибутку. Поточний податок на прибуток 
розраховується за ставкою 18% і застосовується лише в разі отримання додатного 
фінансового результату. Узагальнені показники операційних доходів, витрат та 
прибутку представлені у таблиці 3.12. 
 
 71 
Таблиця 3.12 
Прогноз грошових потоків операційної діяльності 
Балансовий 
Доходи від Постійні Повернення прибуток (ПБₜ = Податок Чистий 
Рік реалізації витрати кредиту Dₜ – ПВₜ – ПКₜ), (18%), прибуток 
(Dₜ), грн (ПВₜ), грн (ПКₜ), грн грн грн (ЧПₜ), грн 
1 8 100 000 7 245 000 6 273 000 –5 418 000 0 –5 418 000 
2 17 010 000 7 607 250 6 273 000 3 129 750 563 355 2 566 395 
3 21 647 400 7 987 612 6 273 000 7 386 788 1 329 622 6 057 166 
4 27 570 650 8 386 993 6 273 000 12 910 657 2 323 918 10 586 739 
5 31 301 073 8 806 343 6 273 000 16 221 730 2 919 911 13 301 819 
6 32 889 742 9 246 660 0 23 643 082 4 255 754 19 387 328 
7 18 780 676 9 708 993 0 9 071 683 1 632 903 7 438 780 
8 12 814 773 10 194 443 0 2 620 330 471 659 2 148 671 
9 8 743 225 10 704 165 0 –1 960 940 0 –1 960 940 
10 5 966 136 11 239 373 0 –5 273 237 0 –5 273 237 
 
У перший рік діяльності DEX-платформа залишається збитковою, що 
пов’язано зі значним кредитним навантаженням та відносно невеликим обсягом 
транзакцій. З огляду на це, під час планування фінансової моделі було передбачено 
спеціальний механізм підтримки – інвестори беруть на себе виконання кредитних 
платежів першого року, забезпечуючи безперервність операційної діяльності 
платформи та уникнення дефіциту грошових коштів на стартовому етапі. 
Компенсація цих витрат інвесторам запланована у третьому році, коли фінансовий 
результат переходить у стійку позитивну зону, що узгоджується з їхньою 
зацікавленістю у довгостроковій прибутковості проєкту. 
 
 72 
У другому році фінансовий результат покращується, а з третього по п’ятий 
роки проєкт демонструє стале зростання прибутковості завдяки збільшенню 
кількості транзакцій та підвищенню середньої комісії. 
 
3.10 Прогноз грошових потоків проєкту 
 Прогноз грошових потоків проєкту охоплює інвестфазу (1–8 місяців) та 
операційну фазу (1–10 років) і базується на узгодженні потоків інвестиційної, 
операційної та фінансової діяльності. 
У межах інвестфази відображено витрати на розробку та запуск платформи, 
що фінансуються кредитними траншами. Відсотки за кредитом у цей період 
покриваються інвесторами, тому не включаються до операційних витрат. 
Починаючи з першого року операційної діяльності, формуються грошові 
потоки від роботи DEX-платформи: чистий прибуток, операційні витрати та 
виплати за кредитом (ануїтетна схема протягом перших п’яти років). Це дає змогу 
оцінити фактичне сальдо реальних грошових потоків за кожен рік. 
Для аналізу ефективності проєкту здійснено дисконтування грошових 
потоків за ставкою 12%. Отримані значення відображені в Таблиці 3.13, зокрема 
дисконтовані потоки за періодами та їх накопичений підсумок.
 
 73 
Таблиця 3.13 
 Прогноз грошових потоків проєкту 
1. 2. 4. Грошові 5. Сальдо 7. 8. 
Період Грошові Чистий потоки 6. Коеф. Дисконтований Дисконтований 
потоки ІД прибуток фінансової реальних 
грошей дисконту потік за потік 
(витрати) ОД діяльності) періодом (кумулятивно) 
1–3 
міс –7 470 550 – 7 470 550 0 0,97 0 0 
4–6 
міс –7 755 550 – 7 755 550 0 0,94 0 0 
7–8 
міс –6 836 090 – 6 836 090 0 0,92 0 0 
1 рік 0 –5 418 
000 –6 273 000 –11 691 
000 0,89 –10 387 990 –10 387 990 
2 рік 0 2 566 395 –6 273 000 –3 706 
605 0,80 –2 965 284 –13 353 274 
3 рік 0 6 057 166 –6 273 000 –215 834 0,71 –153 246 –13 506 520 
10 586 
4 рік 0 739 –6 273 000 4 313 739 0,64 2 760 796 –10 745 724 
5 рік 0 13 301 
819 –6 273 000 7 028 819 0,57 4 006 629 –6 739 095 
19 387 19 387 
6 рік 0 328 0 328 0,51 9 888 537 3 149 442 
7 рік 0 7 438 780 0 7 438 780 0,45 3 347 451 6 496 893 
8 рік 0 2 148 671 0 2 148 671 0,40 859 468 7 356 361 
9 рік 0 –1 960 
940 0 –1 960 
940 0,36 –706 738 6 649 623 
10 рік 0 –5 273 0 –5 273 
237 237 0,32 –1 687 436 4 962 187 
 
 
 74 
 
Рисунок 3.2 – Грошові притоки та відтоки протягом 10 років. 
 
Аналіз грошових потоків показує, що після початкового збиткового етапу 
проєкт виходить на стабільну прибутковість і демонструє позитивні фінансові 
результати до 8-го року включно. Починаючи з 8-го року, фінансові показники 
погіршуються через зменшення операційних обсягів та зростання витрат, що 
призводить до втрати економічної доцільності. За таких умов раціональним є 
припинення підтримки та експлуатації проєкту після 8-го року його 
функціонування. 
3.11 Оцінка показників ефективності проєкту 
Розрахунок показників ефективності проєкту виконано на основі прогнозу 
грошових потоків за 10 років операційної діяльності. Абсолютний ефект від 
реалізації проєкту визначається як різниця між накопиченими грошовими 
притоками та відтоками з урахуванням тимчасової вартості грошей. Для оцінки 
комерційної ефективності використовується показник чистого дисконтованого 
прибутку (ЧДП), що обчислюється за формулою: 
ЧДП = Σ(Пt · КДt) – Σ(Вt · КДt), де  
Пt – грошові притоки проєкту в t-му році, грн; 
Вt – грошові відтоки проєкту в t-му році, грн; 
 
 75 
КДt – коефіцієнт дисконтування для t-го року. 
У розрахунках застосовано ставку дисконту 12 %, тому коефіцієнти дисконтування 
!
визначаються як      КДt = (  
!#$,!&)!
На основі даних таблиці 3.13 позитивні дисконтовані грошові потоки 
розглядаються як притоки, а від’ємні – як відтоки. 
Сума дисконтованих притоків = 20 862 881 грн 
Сума дисконтованих відтоків = 15 900 694 грн 
ЧДП = 20 862 881 – 15 900 694 = 4 962 187 грн 
Отже, ЧДП > 0, що свідчить про позитивну комерційну ефективність проєкту за 
ставкою дисконту 12 %. 
((П*	·	КД*)	
Індекс прибутковості (ІД) визначається як  ІД = ≈ 1,31 
((В*	·	КД*)
Значення ІД > 1 означає, що дисконтована вартість притоків перевищує 
дисконтовану суму відтоків. 
Динамічний строк окупності визначається за кумулятивним дисконтованим 
потоком (табл. 3.13). Перехід через нуль відбувається між 5-м і 6-м роками, тому 
строк окупності становить приблизно 5,7 року. 
Внутрішня норма дохідності (ВНД) визначається як значення r, при якому ЧДП = 
01
0:    Σ = ( )! = 0 
!#2
Чисельні розрахунки показали, що ВНД ≈ 20,7 %. Оскільки ВНД > 12 %, проєкт 
забезпечує дохідність, що перевищує нормативну ставку дисконту. 
Узагальнюючи, можна зробити висновок, що за всіма основними критеріями 
(ЧДП, ІД, строк окупності, ВНД) проєкт є економічно доцільним та фінансово 
ефективним. 
 
3.12 Розробка проєкту кредитного договору 
Завершальним етапом роботи є підготовка проєкту кредитного договору між 
банком та підприємством-позичальником (додаток А). 
 
 76 
До договору обов’язково формується графік отримання та повернення 
кредитних коштів (додаток Б), який містить інформацію про обсяги фінансування, 
динаміку погашення основної суми боргу та нарахованих відсотків. 
Розрахунки, виконані у попередніх розділах, утворюють фінансово-
економічну основу техніко-економічного обґрунтування (ТЕО) проєкту. Для будь-
якого інвестора або кредитора саме ці матеріали є ключовими: розпочинаючи 
переговори, вони насамперед вимагатимуть надати документи, які відображають 
концепцію проєкту, економічні передумови його реалізації, прогнозовані 
результати та очікувану ефективність. 
Таким чином, проведені розрахунки виступають необхідним додатком і 
структурною передумовою укладення кредитного чи інвестиційного договору. 
Вони підтверджують доцільність фінансування, демонструють рівень ризиків та 
забезпечують обґрунтований підхід до прийняття рішення щодо виділення коштів. 
  
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 77 
 РОЗДІЛ ІV Практичні аспекти впровадження DEX-платформи 
 
Процес впровадження платформи організовано як поетапну роботу, що 
охоплює аналіз вимог, технічне планування, проєктування архітектури, розробку, 
інтеграцію з зовнішніми сервісами, тестування та підготовку до експлуатації. 
Кожен етап включає зворотний зв’язок між усіма учасниками проєкту, що 
забезпечує узгодженість технічних рішень та відповідність очікуваному 
результату. 
DEX-платформа використовує модульний підхід, що дозволяє розширювати 
функціональність, інтегрувати нові сервіси та масштабувати операції без зміни 
базової архітектури. Основою процесу впровадження є постійна комунікація між 
бізнес-стейкхолдерами, технічною командою та інтеграторами Web3-
інфраструктури. 
 
4.1. Дослідницько-аналітична робота в процесі впровадження платформи 
У процесі впровадження DEX-платформи важливе місце посідає 
дослідницько-аналітична діяльність, спрямована на перевірку ефективності 
обраних архітектурних рішень, аналіз поведінки системи в різних умовах та 
уточнення параметрів подальшої експлуатації. Така робота забезпечує 
обґрунтованість управлінських рішень і дозволяє адаптувати платформу до 
специфіки багатомережевої інфраструктури. 
Одним зі стратегічних напрямів є аналіз маршрутизації транзакцій через 
агрегатор ліквідності LiFi. Досліджуються швидкість відповіді, стабільність 
взаємодії із зовнішнім API, витрати часу на виконання обмінів та можливі фактори 
затримки. Це дає змогу визначити, за яких умов обміни залишаються 
передбачуваними та конкурентоспроможними для користувачів. 
Окремим напрямом є уточнення комісійної моделі. Для 
внутрішньомережевих обмінів (Polygon, Ethereum) використовується власна логіка 
комісій, що вимагає експериментальної перевірки стійкості смартконтрактних 
механізмів. Для міжмережевих та крос-чейнових операцій моделюється розподіл 
 
 78 
комісій між платформою та LiFi, аналізується вплив різних параметрів на валовий 
дохід платформи. 
У межах дослідження оцінюється робота платформи в умовах нестабільності: 
різких змін вартості газу, тимчасової недоступності RPC-вузлів, підвищених 
затримок у зовнішніх сервісах. Визначаються вимоги до систем моніторингу 
(Sentry, Kibana, CloudWatch), що дозволяють своєчасно реагувати на відхилення. 
Спостережність і безперервний моніторинг є необхідними для раннього виявлення 
збоїв компонентів, що дозволяє системі адаптуватися або відновитися до того, як 
відмови поширяться. 
Технічний аналіз включає оцінку масштабованості архітектури, конфігурації 
хмарної інфраструктури та якості CI/CD-процесу, який має забезпечувати 
контрольоване оновлення системи. Паралельно проводиться аналіз інтерфейсу та 
користувацьких сценаріїв, що дозволяє сформувати пропозиції щодо покращення 
зручності взаємодії з платформою. 
Результатом дослідницько-аналітичної діяльності є оптимізована модель 
роботи DEX-платформи, узгоджена комісійна політика, визначені вимоги до 
інфраструктури та сформовані рекомендації щодо подальшого розвитку сервісу. 
 
4.2 Організація впровадження та взаємодія учасників проєкту 
 Впровадження DEX-платформи вимагає чіткої координації між усіма 
учасниками процесу – замовником, інвесторами, керівником проєкту, технічними 
спеціалістами та аналітиками. Це дозволяє оцінювати не лише короткострокові 
KPI, а й загальний вектор розвитку DEX-платформи. 
Успішність реалізації значною мірою залежить від того, наскільки злагоджено 
відбувається обмін інформацією, ухвалення рішень та контроль виконання задач. 
Як зазначає Наталія Блага, необхідною умовою успішної діяльності організації є 
узгодженість дій та ефективна координація між учасниками проєкту [35]. 
Комунікації реалізовано через Slack, що забезпечує швидкий обмін 
інформацією всередині команди та підтримує фокусованість на операційних 
завданнях. Документація, технічні специфікації та історія змін зберігаються у 
 
 79 
GitHub, що створює централізоване середовище для оцінки прогресу та контролю 
якості коду. 
ClickUp використовується як інтегрований інструмент управління проєктом: 
фіксація вимог, створення беклогу, відстеження дедлайнів, узгодження 
відповідальності. Такий підхід забезпечує прозорість процесу впровадження та 
підвищує дисципліну виконання. Важливо, що чіткий поділ ролей та визначені 
режими взаємодії між командами зменшують когнітивне навантаження і 
підвищують ефективність координації робіт у межах складної DEX-системи [37]. 
Для забезпечення довгострокової відповідності системи стратегічним орієнтирам 
важливо застосовувати підходи стратегічного контролінгу, оскільки, як 
зазначається в літературі, стратегічний контролінг – система, яка спрямована на 
забезпечення виживання та відслідковування руху підприємства до наміченої 
стратегічної мети розвитку [38]. 
 
4.3 Інтеграція DEX-платформи в інформаційне середовище 
 Платформа функціонує у взаємодії з кількома зовнішніми сервісами, 
інфраструктурою хмарного середовища та блокчейн-мережами. Її робота 
спирається на API LiFi, що виконує маршрутизацію обмінних транзакцій у 
багатомережевому середовищі. Обробка внутрішньомережевих обмінів 
реалізується власними смартконтрактами, що забезпечують стягнення комісій та 
перевірку валідності операцій. 
Системні компоненти розгорнуті у хмарі AWS, що забезпечує стійкість до 
навантаження та гнучке масштабування. Зокрема, згідно з AWS Well-Architected 
Framework, надійна хмарна система повинна бути масштабованою, 
спостережуваною та здатною до автоматичного відновлення після збоїв [39]. 
Для управління контейнерами застосовується Kubernetes, який забезпечує 
високу стабільність роботи та можливість швидкого оновлення сервісів. Як 
зазначає Бьорнс, Kubernetes надає уніфікований API для розгортання та 
масштабування застосунків, формуючи самовідновлювані системи для динамічних 
навантажень [40].  
 
 80 
Моніторинг інфраструктури здійснюється за допомогою CloudWatch та 
Kibana. Для відстеження помилок та некоректної поведінки застосовується Sentry, 
що дозволяє оперативно реагувати на технічні збої. 
 
4.4 Взаємодія учасників проєкту та управління процесами впровадження 
Успішне впровадження DEX-платформи базується на злагодженій взаємодії 
між усіма учасниками проєкту. Комунікаційна модель передбачає постійний обмін 
інформацією, погодження рішень і координацію дій між управлінськими, 
технічними та зовнішніми сторонами, що забезпечує узгоджений рух проєкту від 
планування до експлуатації. 
Ефективна координація, як підкреслюють Бас Водде та Крейг Лармен, 
потребує постійної комунікації та регулярного узгодження між командами і 
стейкхолдерами [42]. 
Інвестор, замовник та керівник проєкту взаємодіють на стратегічному рівні. 
Замовник транслює бачення й очікування щодо платформи, інвестор визначає 
обсяг доступних ресурсів, а керівник проєкту узгоджує обмеження та формує план 
реалізації. На регулярних зустрічах сторони уточнюють пріоритети, коригують 
дорожню карту та отримують оновлення щодо прогресу. 
Керівник проєкту координує роботу команди розробки, проєктувальників, 
маркетологів і інтеграторів. Усі ключові технічні рішення проходять погодження в 
межах технічних рев’ю, де розробники, інтегратори та інженери обговорюють 
архітектурні зміни, ризики та залежності. Проєктувальники тісно співпрацюють із 
розробниками, узгоджуючи логіку роботи інтерфейсів та поведінку 
користувацьких сценаріїв. Команди з високою продуктивністю ґрунтуються на 
швидких зворотних зв’язках, чітких каналах комунікації та тісній співпраці між 
функціями, що дає змогу швидко та надійно створювати програмні продукти [43].  
Команда розробки підтримує постійний цикл синхронізації з інженерами 
моніторингу та безпеки (наприклад, через інструменти Sentry, CloudWatch, Kibana). 
Виявлені інциденти або закономірності в поведінці системи передаються в беклог 
задач, де вони пріоритезуються спільно з керівником проєкту. У разі критичних 
 
 81 
подій рішення ухвалюється негайно, а зміни проходять прискорений цикл 
перевірки. 
Маркетингова команда взаємодіє зі стороною замовника та аналітиками, щоб 
адаптувати функціональність платформи до ринкових потреб. Вони отримують 
інформацію про плани релізів, готують матеріали та координують комунікації з 
користувачами. Маркетологи також передають відгуки замовнику й керівнику 
проєкту, що дозволяє коригувати пріоритети розвитку. 
HR-відділ взаємодіє з керівником проєкту та технічними лідерами для 
забезпечення команди необхідними фахівцями. На основі запитів щодо 
компетенцій HR координує процес пошуку, проводить онбординг і передає новим 
учасникам інформацію про структуру взаємодій та робочі процеси. 
Користувачі та бета-тестери беруть участь у зворотному зв’язку. Їхні 
зауваження збираються через маркетингові канали, технічну підтримку або A/B-
тестування й передаються проєктній команді. Цей зворотний зв’язок впливає на 
рішення про вдосконалення функцій, зміни UI та пріоритезацію майбутніх релізів. 
Ліцензіар та юридичні консультанти взаємодіють із замовником і проєктним 
менеджером у питаннях відповідності нормативним вимогам. Будь-які 
рекомендації чи зміни нормативного характеру передаються технічній команді для 
оцінки впливу на архітектуру та реалізацію функціоналу. 
Окремий напрям – це  комунікація із замовником та інвесторами. Згідно з 
висновками Яна Боша, сучасні цифрові продукти потребують безперервної 
взаємодії між бізнес-сторонами та технічними командами для відповідності 
постійно змінним очікуванням користувачів [44]. 
Таким чином, взаємодія в межах проєкту відбувається за моделлю 
багатоаспектної координації, де кожна сторона отримує інформацію саме в тому 
форматі й у той момент, коли вона необхідна для ефективного виконання функцій. 
Така структура забезпечує узгодженість рішень, прозорість процесів і 
безперервність розвитку DEX-платформи. 
4.5 Управління відхиленнями від плану та зовнішні фактори впливу на строки 
впровадження 
 
 82 
 У процесі реалізації DEX-платформи виникають ситуації, які потребують 
коригування попередніх планових рішень. Найпоширенішими джерелами 
відхилень від графіку є зовнішні залежності, інтеграції із сервісами сторонніх 
постачальників та регуляторні або безпекові вимоги, що потребують додаткових 
перевірок. 
Одним із ключових чинників можливих затримок є проходження незалежних 
аудитів смартконтрактів. Безпекові аудити виконуються сторонніми 
спеціалізованими компаніями й мають власні часові рамки, які іноді можуть не 
збігатися з планом команди розробки. Крім того, зауваження, отримані в результаті 
аудиту, часто потребують повторного аналізу архітектури, виправлення логіки або 
перероблення окремих модулів. Це природно збільшує тривалість етапу 
впровадження. 
Джерелом відхилень можуть бути також інтеграції з зовнішніми сервісами, 
серед яких LiFi, Moralis, Alchemy, Reown та CoinGecko. На відміну від внутрішніх 
компонентів платформи, зовнішні інструменти працюють за власними циклами 
оновлення, що може викликати несумісність з API, нестабільність відповідей або 
тимчасове обмеження доступності. Наприклад, інтеграція з LiFi потребує 
налаштування кількох середовищ, синхронізації маршрутів обмінів та перевірки 
відповідності структур даних. У свою чергу, Moralis може запроваджувати зміни у 
своїй SDK, що вимагатиме адаптації бекенд-компонентів. Аналогічно, сервіси 
CoinGecko та Alchemy іноді обмежують частоту запитів або змінюють формати 
відповіді, що впливає на стабільність інтеграції. Як зазначає Сем Ньюман, команда 
проєкту має обмежений контроль над стабільністю та еволюцією зовнішніх API, 
що часто змінюються без попередження і здатні порушувати роботу залежних 
систем [45]. 
Додатковим фактором невизначеності є специфіка блокчейн-мереж. 
Дослідження Генсер та ін. показує, що мережі Ethereum та інші публічні блокчейни 
мають природні коливання затримок, часу підтвердження транзакцій і доступності 
інфраструктури, що прямо впливає на роботу залежних застосунків [46]. 
 
 83 
Для мінімізації наслідків відхилень застосовується постійний моніторинг 
інфраструктури за допомогою Sentry, CloudWatch та Kibana, що дозволяє 
оперативно виявляти потенційні проблеми та вчасно переглядати план робіт. На 
основі зібраних даних команда застосовує зміни до дорожньої карти або переглядає 
пріоритети, що забезпечує контрольоване впровадження платформи за складних 
зовнішніх умов. 
 
4.6 Використання інформаційних систем у менеджменті проєкту 
 Використання цифрових інструментів у DEX-проєкті потребує не лише 
організації комунікацій, але й коректного подання процесів управління, що 
забезпечує їхню повну прозорість та контрольованість. Як зазначає Т. О. 
Прокопенко – розроблені інформаційні технології управління організаційно-
технологічними об’єктами, враховуючи особливості функціонування, мають 
забезпечити подання процесів управління із необхідним ступенем деталізації, що 
дозволить враховувати ряд додаткових (якісних) характеристик і в умовах неповної 
й неточної вихідної інформації формувати раціональні рішення [47]. 
Це безпосередньо корелює з потребами DEX-платформи, де рішення приймаються 
на основі множини технічних сигналів, аналітичних панелей, станів інтеграцій та 
даних моніторингових систем. 
ClickUp відіграє роль основної системи управління проєктом. У ньому 
формується беклог, дорожня карта, планування ієрархії задач, визначаються 
виконавці та дедлайни. Kanban-борди забезпечують прозорість робочого процесу 
та дозволяють стежити за динамікою виконання завдань у режимі реального часу. 
Як зазначають дослідники, візуалізація робочого процесу за допомогою 
інформаційних панелей та канбан-бордів є ключовим елементом гнучких методів 
керування, оскільки дозволяє оперативно виявляти відхилення, контролювати 
завантаженість та координувати роботу команди. 
GitHub використовується як інструмент контролю версій та спільної роботи 
над кодом. Історія змін, pull-реквести та протоколи обговорень створюють 
централізоване джерело технічної інформації. Це повністю узгоджується зі 
 
 84 
спостереженням Діомідіса Спінелліса, що сучасні платформи спільної розробки 
об’єднують контроль версій, рев’ю коду, документацію та трекінг задач, формуючи 
єдиний комунікаційний центр для інженерних команд [48] 
Інтегрований CI/CD-процес забезпечує автоматизоване тестування, 
розгортання та моніторинг якості оновлень. Комунікація всередині команди 
організована через Slack, що забезпечує швидкий і структурований обмін 
повідомленнями. Регулярні стендапи, спринт-планування та технічні обговорення 
проводяться у Google Meet, що сприяє узгодженню рішень та швидкому 
реагуванню на зміни. 
Для роботи з документацією та підготовки звітів використовуються Google 
Docs та Google Sheets, що полегшує спільне редагування й зберігання інформації. 
У контексті розподіленої роботи це відповідає висновкам Гарі та Джуді Олсен, які 
зазначають, що розподілені команди значною мірою залежать від комунікаційних 
технологій для координації, підтримання обізнаності та спільного розуміння між 
усіма учасниками [49] 
Окремий напрям – комунікація з інвесторами, яка включає підготовку 
місячних та квартальних звітів, аналітичних оглядів і оновлень дорожньої карти. 
Google Slides застосовується для створення презентацій результатів та планів 
розвитку, що робить процес звітування структурованим і прозорим. 
Таке поєднання інструментів формує ефективну цифрову екосистему 
управління проєктом, у якій усі учасники мають доступ до актуальної інформації 
та можуть оперативно впливати на перебіг роботи. Як підкреслює Люк Треденнік, 
хмарні платформи співпраці забезпечують синхронну координацію, спільне 
редагування документів та прозорі управлінські процеси, що є критично важливим 
для сучасного менеджменту [50]. 
 
 
4.7 Оцінка ефективності впровадження та відповідність прогнозам 
 Оцінка ефективності впровадження DEX-платформи здійснюється шляхом 
порівняння прогнозних фінансових показників, визначених на етапі моделювання, 
 
 85 
із фактичними операційними результатами роботи системи. Таке порівняння 
дозволяє оцінити точність початкових припущень, виявити відхилення та 
визначити напрями подальшого вдосконалення. 
Аналіз здійснюється за кількома ключовими параметрами: 
Фінансові показники. Порівнюються прогнозні та фактичні значення доходів 
від комісій, операційних витрат, обсягів обмінів і структурних змін у поведінці 
користувачів. Відхилення можуть бути зумовлені змінами ринкових умов, вартості 
газу або зовнішніх інтеграційних факторів. 
Технічна стабільність. Оцінюється частота інцидентів, пов’язаних із 
роботою API зовнішніх сервісів, продуктивність внутрішніх компонентів та якість 
обробки транзакцій. Звіти з моніторингових систем (Sentry, CloudWatch, Kibana) 
використовуються як джерело даних для аналізу. 
Користувацька взаємодія. Аналізуються відгуки користувачів, показники 
успішності транзакцій, тривалість операцій та поведінкові патерни. Додатково 
оцінюється вплив UX-змін на зростання активності або відтік користувачів. 
Інтеграційні ризики. Проводиться аналіз того, як зовнішні сервіси впливають 
на роботу платформи: зміни API, періоди нестабільності, введення нових політик 
або лімітів. Окремо розглядається взаємодія з LiFi, як основним маршрутизатором 
міжмережевих транзакцій. 
Результати порівняння дозволяють оцінити, наскільки платформа відповідає 
прогнозним очікуванням і де саме необхідна оптимізація. Якщо фактичні 
показники демонструють відхилення від прогнозних у межах допустимих значень, 
проєкт вважається реалізованим ефективно. Якщо ж спостерігаються систематичні 
відхилення – вони слугують підставою для перегляду архітектури, стратегії 
розвитку або комісійної моделі. 
Таким чином, оцінка ефективності впровадження є безперервним процесом, 
що формує основу для ухвалення управлінських рішень та забезпечує стійкість 
платформи до змін зовнішнього середовища.  
 
Висновки до розділу 4 
 
 86 
 
 Практична частина впровадження DEX-платформи показала, що успішна 
реалізація проєкту залежить від поєднання технічної роботи, ефективної взаємодії 
учасників та використання сучасних інструментів управління. Узгоджена 
комунікація між ключовими стейкхолдерами, якісна організація процесів і 
правильно вибудовані інтеграції з LiFi, Moralis, Alchemy та іншими сервісами 
забезпечили стабільність і передбачуваність розробки. Аналіз отриманих 
результатів підтвердив відповідність реалізованих рішень очікуванням і визначив 
основні напрями для подальшого розвитку платформи. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 87 
ВИСНОВКИ 
 
У результаті проведеного дослідження було сформовано комплексну модель 
управління проєктом створення децентралізованої біржової платформи (DEX), яка 
враховує технічні, фінансові, організаційні та ризикові аспекти сучасних Web3-
рішень. Робота поєднує проєктний підхід із практичними особливостями розробки 
продуктів у сфері блокчейн-технологій, що дало змогу отримати цілісне бачення 
життєвого циклу DEX-платформи – від концепції до фінансового аналізу 
довгострокової ефективності. 
На основі проведеного SWOT- та PEST-аналізів визначено позицію майбутнього 
продукту в ринковому середовищі, ключові конкурентні переваги, обмеження та 
зовнішні чинники впливу. Результати аналізу засвідчили, що DEX-платформи 
мають значний потенціал масштабування завдяки мультичейновій архітектурі, 
безкастодіальній моделі роботи та зростаючому попиту на прозорі фінансові 
сервіси. Разом із тим на платформу впливають регуляторні невизначеності, ризики 
інтеграції зі сторонніми сервісами та стрімкий розвиток технологій, що потребує 
високого рівня адаптивності управління проєктом. 
У роботі систематизовано предметну область та визначено зміст проєкту 
відповідно до принципів сучасного управління ІТ-проєктами. Побудовано 
структуру WBS, яка включає всі етапи – дослідження, архітектуру, розробку 
фронтенду, бекенду та смартконтрактів, інтеграції (LiFi, Moralis, Alchemy, 
CoinGecko, Reown), DevOps-процеси, тестування, аудит та запуск MVP. Така 
структуризація дозволила окреслити ролі, відповідальність, залежності між 
командами та критичний шлях реалізації. 
Значну увагу приділено ресурсному та фінансовому плануванню. Було 
сформовано повний бюджет проєкту, що включає витрати на команду, податки, 
інфраструктуру AWS, зовнішні сервіси, аудит смартконтрактів та резервний фонд. 
Фінальна вартість реалізації склала 22 063 186 грн, що є реалістичною оцінкою для 
комплексного Web3-продукту з високими вимогами до безпеки, масштабованості 
та стійкості. 
 
 88 
Важливою складовою дослідження став фінансовий прогноз та економічна 
оцінка ефективності платформи. За результатами моделювання грошових потоків 
встановлено, що: 
• у перші роки діяльності прибутковість обмежується операційними витратами 
та кредитним навантаженням, 
• починаючи з 3–4-го років проєкт демонструє стійку позитивну динаміку, 
• після завершення кредитних виплат прибутковість помітно зростає, 
• після 8-го року можливе поступове зниження доходів через падіння 
транзакційної активності та зростання витрат. 
Дисконтування грошових потоків дозволило оцінити реальну вартість 
проєкту на горизонті 10 років та сформувати висновки щодо доцільності підтримки 
продукту у довгостроковій перспективі. 
Сформувати У розділі, присвяченому практичній частині, було сформовано 
модель взаємодії учасників, методи організації робіт, описано цифрову екосистему 
управління (Slack, ClickUp, GitHub, Google Workspace), а також процес роботи з 
відхиленнями, що виникають унаслідок аудитів, інтеграційних обмежень та 
зовнішніх факторів блокчейн-екосистеми. 
Створена модель управління якістю охоплює тестування, аудит 
смартконтрактів, моніторинг інфраструктури (Sentry, Kibana, CloudWatch), вимоги 
до безпеки та процедури реагування на інциденти. Це забезпечує відповідність 
продукту технічним стандартам DeFi-ринку та очікуванням користувачів. 
Практична значущість роботи полягає в тому, що сформована модель 
управління є придатною для реальних Web3-проєктів різного масштабу, а 
розроблена фінансова модель може використовуватися для планування бюджету 
стартапів і оцінки прибутковості DeFi-рішень. Описана архітектура та реалізовані 
інтеграції відповідають сучасним технічним практикам, що робить їх застосовними 
у комерційних розробках. Крім того, запропоновані управлінські рекомендації 
сприяють зниженню ризиків, оптимізації витрат і підвищенню якості 
впровадження продукту. 
 
 89 
Узагальнюючи, сформовано системний підхід до створення 
децентралізованої біржової платформи, який поєднує бізнес-аналітику, технічне 
проєктування, фінансове моделювання та організацію командної роботи. Отримані 
результати підтверджують, що реалізація DEX-платформи є економічно 
виправданою за умови контролю витрат, якісного технічного впровадження та 
адаптивного управління з урахуванням динамічних факторів Web3-екосистеми. 
Запропонована модель може використовуватися як основа для подальших 
досліджень, удосконалення економічних розрахунків, розширення 
функціональності платформи та розроблення нових блокчейн-продуктів. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 90 
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ 
 
1. Ward J. & Daniel E. Benefits Management: Delivering Value from IS and IT 
Investments, [ Chichester: Wiley, 2005]. 
2. Bytheway, A. Investing in Information: the Information Management Body of 
Knowledge, [ Geneva: Springer, 2015ƒtre ]. 
3. PMBOK  Guide (4th Edition). Project Management Institute, 2008. 
4. Antonopoulos, A. M., & Wood, G. Mastering Ethereum: Building Smart Contracts 
and DApps. – O’Reilly Media, 2018. 
5. Buterin, V. Ethereum Whitepaper: A Next-Generation Smart Contract and 
Decentralized Application Platform. 2014. 
6. Schär, F. Decentralized Finance: On Blockchain- and Smart Contract-Based 
Financial Markets. Federal Reserve Bank of St. Louis Review, 2021. 
7. The Evolution of AMM: From Concept to Capital Efficiency. tenexdefiofficial. 
Medium, 2021. URL: https://medium.com/@tenexdefiofficial/the-evolution-of-
amm-from-concept-to-capital-efficiency-3f741dd52215 
8. Angeris, G., Chitra, T., “Improved Price Oracles: Constant Function Market 
Makers,” ACM Conference on Advances in Financial Technologies, 2020. 
9. Narayanan A., Bonneau J., Felten E., Miller A., Goldfeder S. 
Bitcoin and Cryptocurrency Technologies: A Comprehensive Introduction. 
Princeton University Press, 2016. – 328 p. 
10. Tapscott, D., & Tapscott, A. Blockchain Revolution. Penguin, 2016. 
11. Керівництво з питань проєктного менеджменту / Під ред. С.Д. Бушуєва, 2-е 
вид., перероб. – К.: Видавничій дім “Ділова Україна”, 2000. – 198 с. 
12. Chainalysis. 2023 Global Crypto Adoption Index. 2023 
13. Messari. Crypto Theses for 2024. – 2024. 
14. PMI. A Guide to the Project Management Body of Knowledge (PMBOK® Guide), 
6th Edition. – Project Management Institute, 2017. 
15. Miller, A., Bentov, I., Kumaresan, R., McCorry, P. (2021). SoK: Communication 
Across Distributed Ledgers. USENIX Security Symposium. 
 
 91 
16. Atzei, N., Bartoletti, M., & Cimoli, T. (2017). A Survey of Attacks on Ethereum 
Smart Contracts. Proceedings of the 6th International Conference on Principles of 
Security and Trust (POST). Springer. 
17. Bonneau, J. et al., SoK: Research Perspectives and Challenges for Bitcoin and 
Cryptocurrencies, IEEE SP, 2015 
18. Campbell-Verduyn, M. Bitcoin and Beyond: Cryptocurrencies, Blockchains and 
Global Governance. Routledge, 2017. 
19. Kerzner H. Project Management: A Systems Approach to Planning, Scheduling, and 
Controlling. 12th Edition. Wiley, 2017. – 1296 p. 
20. Highsmith, Jim. Adaptive Software Development: A Collaborative Approach to 
Managing Complex Systems, 1999 
21. Bashir I. Mastering Blockchain (3rd ed.). Packt Publishing, 2020. – ISBN 978-
1839213199 
22. Prusty, N. Building Blockchain Projects. Packt Publishing, 2017. – ISBN 978-
1787122147 
23. Sommerville, Ian. Software Engineering (10th Edition), 2015 
24. IEEE Std 1074-2006 – Standard for Developing a Software Project Lifecycle 
Process 
25. Robert K. Wysocki, Effective Project Management: Traditional, Agile, Extreme, 7th 
Edition, Wiley, 2013 
26. Jeff Sutherland, Scrum: The Art of Doing Twice the Work in Half the Time, Crown 
Publishing, 2014. 
27. McConnell, S. Software Project Survival Guide. Microsoft Press, 1997. 
28. Cohn, Mike. Succeeding with Agile: Software Development Using Scrum. Addison-
Wesley, 2009. 
29. Norman, D. The Design of Everyday Things. MIT Press, 2013. 
30. Zhang, R., Xue, R., & Liu, L. Security and Privacy on Blockchain. ACM Computing 
Surveys, 2019. 
31. Katzenbach, J.R., Smith, D.K. – The Wisdom of Teams: Creating the High-
Performance Organization (Harvard Business Review Press, 2005) 
 
 92 
32. Villamizar, M., et al. Evaluating the Impact of Microservices Architecture on 
Software Development. IEEE Access, 2016–2020. 
33. Forsgren, N., Humble, J., Kim, G. Accelerate: Building and Scaling High-
Performing Technology Organizations. IT Revolution, 2018.Skelton 
34. Момот Т. В., Безугла В. О., Тараруєв Ю. О., Каднічанський М. В., Чалий І. Г. 
Фінансовий менеджмент: навч. посіб. / За ред. Момот Т. В. – Київ: Центр 
учбової літератури, 2011 
35. Блага Н. В. Управління проєктами: навч. посібник. Львів : Львівський 
державний університет внутрішніх справ, 2021. 152 с 
36. Edmondson, A. The Fearless Organization: Creating Psychological Safety in the 
Workplace for Learning, Innovation, and Growth. Wiley, 2019. 
37. Matthew Skelton & Manuel Pais – Team Topologies: Organizing Business and 
Technology Teams for Fast Flow . IT Revolution, 2019 
38. Федулова Л. І. Менеджмент організацій. Львів, 2002 
39. Amazon Web Services – AWS Well-Architected Framework. AWS, актуальна 
редакція 2023. URL: 
https://docs.aws.amazon.com/wellarchitected/latest/framework/welcome.html 
40. Burns, Brendan; Oppenheimer, David. Designing Distributed Systems, O’Reilly, 
2018 
41. Burns, B., Hightower, K., & Beda, J. – Kubernetes: Up and Running. O’Reilly 
Media, 3rd Edition, 2022. 
42. Larman, Craig & Vodde, Bas – Large-Scale Scrum: More with LeSS. Addison-
Wesley, 2016. 
43. Forsgren, N., Humble, J., Kim, G. – Accelerate: The Science of Lean Software and 
DevOps. IT Revolution, 2018. 
44. Bosch, Jan – Speed, Data and Ecosystems: Excelling in a Software-Driven World. 
CRC Press, 2017. 
45. Newman, Sam – Building Microservices: Designing Fine-Grained Systems. 2nd 
Edition, O’Reilly, 2021 
 
 93 
46. Gencer, A. E., Basu, S., Eyal, I., van Renesse, R., & Sirer, E. G. Decentralization in 
Bitcoin and Ethereum Networks, 2018 
47. Прокопенко Т. О: Інформаційні технології управління організаційно-
технологічними об’єктами в умовах невизначеності та ризиків: дисертація д-
ра техн. наук : 05.13.06 – інформаційні технології. Черкаси : Черкаський 
державний технологічний університет, 2021. – рукопис 
48. Spinellis, D., & Gousios, G. Software Engineering: Code Reading, Code Review, 
and Developer Collaboration. Addison-Wesley, 2020. 
49. Olson, J. S., & Olson, G. M. Working Together Apart: Collaboration over the 
Internet. Synthesis Lectures on Human-Centered Informatics, MIT Press, 2014. 
50. Tredinnick, L. Digital Information and Collaboration Systems: Managing Enterprise 
Communication in the Cloud Era. Routledge, 2017. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 94 
Додаток А 
Календарний графік робіт 
Етап Період Відповідальні Опис 
Формування 01.01.2026 – PM, HR Пошук та 
команди та найм 31.01.2026 найм FE, BE, BC, 
фахівців QA, DevOps; 
оформлення 
доступів та 
онбординг. 
Архітектурне 01.01.2026 – PM, BE Lead, Формування 
проєктування та 31.01.2026 BC Lead, FE Lead архітектури 
R&D системи, вибір 
технологій, 
прототипування. 
Інфраструктура 01.01.2026 – DevOps Налаштування 
та DevOps 15.02.2026 CI/CD, AWS, 
Docker, 
моніторингу. 
Розробка 01.02.2026 – FE Lead, FE UI skeleton, 
фронтенду (Epics) 30.06.2026 Dev WalletConnect, 
Swap UI, Bridge 
UI, Dashboard, 
Admin UI. 
Розробка 01.02.2026 – BE Lead, BE GraphQL API, 
бекенду (Epics) 30.06.2026 Dev модуль токенів, 
роутинг, 
інтеграції LiFi, 
логування. 
Розробка 01.02.2026 – BC Lead, BC Dev Hardhat, 
смартконтрактів 31.05.2026 маршрутизація, 
fee-модуль, 
інтеграція з 
бекендом. 
QA та тестування 15.01.2026 – QA Lead Функціональні, 
31.08.2026 інтеграційні та 
навантажувальні 
тести. 
Зовнішній аудит 01.06.2026 – Аудитор, BC Перевірка 
контрактів 30.06.2026 Lead контрактів, 
усунення 
виявлених 
вразливостей. 
Підготовка до 01.07.2026 – PM, DevOps, FE Фінальна збірка, 
релізу та MVP 31.08.2026 Lead, BE Lead деплой, 
проведення 
демонстрацій та 
документація. 
 
 
 95 
Додаток Б 
Типова форма кредитного договору 
 
 
 
 
Затверджено 
 Постановою Правління 
 Національного банку України 
 № 246 від 28 вересня 1995 р. 
 (із змінами, внесеними листом № 306 
 від 10 жовтня 1995р., постановами Правління НБУ 
 від 22 квітня 1996р. №97, 17 лютого 1997р. 
 № 35, 4 квітня 1997 р. № 80)' 
 
 
КРЕДИТНИЙ ДОГОВІР №____ 
 
 м. Черкаси 
 “__”_______ 202_ р. 
 Акціонерно-комерційний банк Приват Банк (у подальшому іменується Банк), 
в особі __________________ 
що діє на підставі 
Статуту________________________Банку________________________________________________, 
з одного боку, та ФОП _____________ (в подальшому іменується Позичальник), 
в особі ___________________ 
що діє на підставі _______________статуту ФОП___________________________________, з другого боку, 
 уклали цей договір про таке. 
 
1. Предмет договору 
1.1 Банк надає Позичальнику кредит на розробку децентралізованої платформи обміну 
криптовалют______________      _____________                                                                  _____ 
(зазначити на які цілі) 
                                                                                ________________________________________          _ 
номер та дата договору) 
 у сумі 22 063 186 грн (двадцять два мільйони шістдесят три тисячі сто вісімдесят шість____________ 
гривень)___________________ _________________________________________________               _ _ 
(сума цифрами і словами) 
 строком___60______місяців з __________01.09.2025___________по________01.09.30_________ із 
сплатою______13________відсотків річних. 
2. Умови забезпечення кредиту 
     2.1 В забезпечення зобов’язань за договором Банком прийняті:_____________договір застави рухомого та 
нерухомого майна __________________________________________________________________________ 
         (вказати конкретно: 
_____________________________________________________________________________________________ 
укладений договір застави, договір поруки (гарантія), цінні папери, 
_____________________________________________________________________________________________ 
що здані на зберігання в Банк, інші документи) 
 
     2.2. Кредит, наданий Банком, забезпечується всім належним Позичальнику майном та коштами, на які може бути 
звернено стягнення в порядку, встановленому законодавством України. 
3. Банк зобов'язується 
3.1. Відкрити Позичальнику позичковий рахунок №___________ для видачі кредиту. 
 
 96 
3.2. Забезпечити Позичальника консультативними послугами з питань виконання договору. 
3.3. На підставі даних бухгалтерської звітності (місячної, квартальної) аналізувати кредитоспроможність 
Позичальника, перевіряти забезпеченість та цільове використання кредиту і вносити пропозиції про подальші 
відносини з Позичальником. 
4. Позичальник зобов'язується 
4.1. Використати кредит на зазначені у договорі цілі і забезпечити повернення одержаного кредиту та сплату 
нарахованих відсотків із свого розрахункового рахунка № __________________________________ 
в ______________________________________________Банку________________________________________ 
(установа банку Позичальника) 
в такі строки_________________________60 місяців_________________________ відповідно до строкових 
зобов’язань. Відсотки за кредит Позичальник сплачує платіжним дорученням на рахунок доходів Банку № _________ 
до 21 числа кожного місяця. 
4.2. Кошти для погашення заборгованості в першу чергу направляти для оплати відсотків за кредит, потім — 
простроченої заборгованості. Сума, що залишилася, направляється для погашення кредиту. 
4.3. За порушення строків повернення кредиту і відсотків за кредит сплачувати Банку додатково до 
встановленої відсоткової ставки за кредит пеню в розмірі__0,1_ відсотків за кожний день прострочення платежу. 
4.4. Самостійно надавати Банку до 25_числа кожного місяця бухгалтерський баланс, планові, звітні 
документи, зміни і доповнення до угод поставки, реалізації об'єктів, що кредитуються, та інші матеріали для видачі, 
перевірки забезпечення кредиту і контролю за його використанням і поверненням. 
4.5. Періодично інформувати Банк про хід виконання угоди. 
4.6. Надати Банку право самостійно стягувати відсотки у разі настання строків платежів і пені за несвоєчасну 
сплату відсотків. 
4.7. Надати банку право після перевірки цільового використання кредиту стягувати штраф _5____відсотків від 
суми коштів, що використані не за цільовим призначенням. 
5. Банк має право 
5.1. Дозволяти за клопотанням Позичальника в окремих випадках у разі наявності вільних кредитних ресурсів 
перенесення строків повернення кредиту зі стягненням підвищеної відсоткової ставки в розмірі __30_____ відсотків 
річних. 
5.2. Проводити перевірку на місці забезпечення банківських позичок, а у разі потреби — і попередню перевірку 
заставних можливостей Позичальника та третіх осіб, які гарантують повернення позички. 
5.3. Проводити перевірку цільового використання кредитів на місці у позичальника. У разі виявлення 
нецільового використання кредитів стягувати з позичальника штраф у розмірі ____5____ відсотків від суми нецільового 
використання. 
5.4. У разі недотримання Позичальником умов кредитного договору розірвати договір і достроково стягнути 
кредит зі сплатою штрафу у розмірі ____5____ відсотків від суми позички. 
5.5. У разі недостатнього забезпечення кредитними ресурсами обмежити надання кредиту за відкритою 
кредитною лінією, повідомивши про це Позичальника за 7 днів до призупинення кредитування. 
6. Позичальник має право 
6.1. Порушувати перед Банком питання про перенесення строків платежу у разі виникнення тимчасових 
фінансових або інших ускладнень з незалежних від нього причин, пов'язаних з виконанням контрактів, угод за 
кредитним договором. 
6.2. Достроково погашати кредит і сплачувати відсотки за кредит. 
6.3. Достроково розірвати договір, повністю повернувши одержаний кредит, включаючи відсотки за його 
користування, повідомивши про це Банк не пізніше ніж за 7 днів. 
 
7. Особливі умови 
    7.1. У разі відсутності коштів на розрахунковому рахунку Позичальника відшкодування боргів банку проводиться 
шляхом ______________застави нерухомого та рухомого майна___________________________ 
(вказати конкретно: звернення стягнення на предмет застави, 
_______________________________________з Позичальника________________________________________. 
стягнення з гаранта, поручителя тощо у встановленому чинним законодавством порядку) 
7.2. У разі зміни кредитної політики згідно з рішеннями Верховної Ради України, Національного банку України, а 
також Банку в договір за погодженням з Позичальником вносяться в десятиденний строк відповідні зміни з моменту 
введення нових положень. При розбіжностях сторін Банк пред'являє кредит до стягнення. У разі відсутності коштів 
кредит виноситься на рахунок прострочених позичок з нарахуванням відсотків і пені відповідно до п. 4.2. 
7.3. Плата за кредит підлягає коригуванню при зміні облікової ставки Національного банку України. 
7.4. У разі зміни національної грошової одиниці сума кредиту підлягає перерахунку відповідно до чинного 
законодавства. 
7.5. Спірні питання за цим договором розглядаються згідно з чинним законодавством в арбітражному порядку. 
 
 97 
7.6. Позичальник зобов'язується у триденний строк повідомити Банк про зміну юридичної та фактичної адреси, 
номера телефону. 
7.7. Зміни в договорі оформляються додатковою угодою сторін і є невід'ємною частиною угоди. 
7.8. Строк дії цього договору встановлюється з дня надання кредиту і до повного погашення кредиту та відсотків 
за ним. 
8. Юридична адреса та реквізити 
Адреса Банку 
___________________________ 
___________________________ 
 (підпис керівника) 
______________________________ 
 (підпис гол. бухгалтера) 
“__” __________________202_р. 
 
 
Поштова адреса і банківські реквізити Позичальника____________________ 
________________________ 
________________________ 
 (підпис керівника) 
___________________________ 
 (підпис гол. бухгалтера) 
“__”_________________202_р. 
Паспортні дані керівників Позичальника: _ _______________ 
Керівник____________________________________________ 
___________________________________________________ 
Гол. бухгалтер_______________________________________ 
___________________________________________________ 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 98 
Додаток В 
Додаток до кредитного договору №2145 
   “Узгоджено”      “Узгоджено” 
   Представник Банка     Представник Позичальника 
   П.І.Б. __________________     П.І.Б. __________________ 
   Підпис______Дата _________    Підпис_______Дата ___________ 
 
 
 
 
Графік отримання та повернення кредиту 
Проценти за кредит Суми повернення, 
Календарні періоди Сума кредиту, грн. 
Грн. % тис. грн. 
1 рік     
1 місяць 2 491 850 26 997 1,08333 - 
2 місяць 2 491 850 53 994 1,08333 - 
3 місяць 2 487 850 80 870 1,08333 - 
4 місяць 2 551 850 108 067 1,08333 - 
5 місяць 2 551 850 136 245 1,08333  
6 місяць 2 651 850 165 044 1,08333 - 
7 місяць 2 721 850 194 341 1,08333 - 
8 місяць 4 114 236 238 357 1,08333 - 
1 рік - 2 868 214 13 3 404 786 
2 рік - 2 425 592 13 3 847 408 
3 рік - 1 925 429 13 4 347 571 
4 рік - 1 360 245 13 4 912 755 
5 рік - 721 586 13 5 551 414 
Строки надання кредитних сум, сплати процентів та повернення сум кредиту – кінець відповідних періодів.
ChSTU repository

ChSTU repository preserves and enables easy and open access to all types of digital content including text, images, moving images, mpegs and data sets
