Розробка системи еськроу для сделок з недвижимістю на блокчейні
Сделка з недвижимістю в традиційній системі — це нотаріус, банк-агент, реестр прав, риелтори з двох сторін, ланцюжок документів, 30-60 днів очікування та 3-5% комісії. Смарт-контракт еськроу видаляє з цього ланцюжка агентів, які не несуть відповідальності за результат, а тільки передають документи. Але видаляти можна тільки те, що дійсно замінюється on-chain логікою — і тут починаються нетривіальні питання.
Що блокчейн-еськроу реально вирішує, а що ні
Смарт-контракт відмінно справляється з утриманням коштів та автоматичним їх розподілом при виконанні умов. Це класичний multi-party escrow: покупець вносить суму, продавець підтверджує готовність, незалежний арбітр підтверджує виконання умов, контракт автоматично переводить кошти.
Що контракт не вирішує сам по собі: правове підтвердження переходу права власності. Передача NFT, яка символізує об'єкт недвижимості, не змінює запис у державному реєстрі прав. Це розрив між on-chain та off-chain світами, який поки не закривається без trusted third party або спеціального законодавства (ОАЕ, Грузія, кілька штатів США експериментують з blockchain title registry).
Реалістичні сценарії застосування:
- Токенізована доля в SPV (Special Purpose Vehicle), яка володіє недвижимістю — юридично оформлений актив, блокчейн для прозорості та ліквідності
- Умовне утримання коштів при сделці між довіряючими сторонами з арбітром як fallback
- Міжнародні сделки, де традиційна ланцюжок транзакцій особливо довга та дорога
Архітектура еськроу-контракту
Сторони та ролі
Класична трьохстороння структура:
- Buyer — вносить кошти, ініціює сделку
- Seller — отримує кошти при виконанні умов
- Arbiter — нейтральна третя сторона з правом вирішення спорів
Розширена модель для real estate:
- Inspector — верифікує фізичний стан об'єкту (on-chain підтвердження через підпис)
- LenderAgent — якщо сделка з іпотечним фінансуванням (не типово для крипто, але можливо при частковому фінансуванні)
- TitleAgent — off-chain нотаріус чи юрист, підписує on-chain документ про правову чистоту
Життєвий цикл сделки
CREATED → FUNDED → INSPECTION_PENDING → INSPECTION_PASSED → CLOSING → COMPLETED
↓
INSPECTION_FAILED → CANCELLED (refund)
↓
DISPUTED → ARBITER_RESOLVED → COMPLETED / CANCELLED
Кожен перехід стану — on-chain транзакція з перевіркою прав. FUNDED — тільки після отримання коштів. INSPECTION_PASSED — тільки після підпису Inspector. CLOSING — тільки з згоди обеих сторін. Оспорювання (DISPUTED) може ініціювати будь-яка сторона в певний період.
Мультиумовна логіка
Найскладніше — conditional release. Кошти розповсюджуються не одним платежем, а по milestones:
- 10% при підписанні договору
- 80% при юридично підтвердженій передачі прав
- 10% через 30 днів після вселення (inspection period)
Це реалізується як масив Milestone[] у storage, кожний з флагом виконання та сумою. releaseFunds() ітерує по виконаним milestone та переводить відповідну частку.
Критичні уязвимості еськроу
Проблема застрявших коштів
Якщо всі сторони перестають реагувати — кошти заблоковані назавжди. Покупець помер, продавець зник, арбітр недоступний. Без timeout-механізму контракт перетворюється на black hole.
Рішення: таймаут на кожен етап. Якщо INSPECTION_PENDING триває > N днів без дій — автоматичний перехід в DISPUTED, арбітр обов'язаний прийняти рішення протягом M днів. Якщо арбітр мовчить дольше — кошти повертаються покупцю. Це гіршає позицію продавця, але це краще, ніж вічна блокування.
Reentrancy при виплаті кільком отримувачам
Якщо releaseFunds виплачує послідовно кільком адресам (продавець + агент + комісія протоколу), класичний pull payment pattern важливий: накопичуємо суми в mapping, кожний забирає сам через withdraw(). Прямі переводи в loop з зовнішніми адресами — reentrancy ризик, особливо якщо отримувач — контракт.
Арбітражна централізація
Єдиний арбітр — single point of failure та single point of trust. Якщо арбітр скомпрометирований або підкуплений — рішення не оспорити. Для крупних сделок рекомендуємо:
- Комітет арбітрів (3-of-5 мультисиг) з незалежними учасниками
- Timelock на виконання арбітражного рішення (24-72 години), протягом яких сторони можуть звернутися в суд
- Публічний лог всіх арбітражних рішень для репутації арбітра
Юридична інтеграція
Чисто технічний смарт-контракт еськроу не має юридичної сили без відповідного правового оформлення. Робоча схема:
- Сторони підписують традиційний договір купівлі-продажу
- У договорі прописана прив'язка до адресу смарт-контракту
- On-chain події (депозит, підтвердження, переведення) мають юридичне значення як підтвердені факти
- Арбітр — ліцензований юрист або арбітражний суддя в юрисдикції сторін
Хеш договору зберігається в контракті (bytes32 public agreementHash). Це пов'язує on-chain та off-chain документи без необхідності публікувати повний текст договору в блокчейні.
Стек реалізації
Ethereum / Polygon — для сделок з великими сумами у стабільних токенах (USDC, USDT). Polygon зменшує газ на рутинні операції (підтвердження етапів).
OpenZeppelin AccessControl для управління ролями: BUYER_ROLE, SELLER_ROLE, ARBITER_ROLE, INSPECTOR_ROLE. Смена арбітра — тільки через спеціальну функцію з згоди обеих сторін.
Chainlink Automation для таймаутів — автоматичне переведення сделки в наступний статус при истечении дедлайну без зовнішнього виклику.
EIP-712 підписи для off-chain підтверджень (інспектор підписує звіт off-chain, on-chain перевіряється тільки підпис) — зменшує газ на інспекційні підтвердження.
Процес розробки
Проектування (1 тиждень). Визначаємо юрисдикцію, тип сделки, список учасників, структуру milestone, таймаути, арбітражний механізм.
Контракти + тести (2-3 тижні). EscrowFactory для деплоя окремого контракту на кожну сделку (не одного шареного), тести всіх життєвих циклів включаючи spoiled scenarios (таймаут, спір, частковий рефанд).
Юридична документація (паралельно). Шаблон договору з прив'язкою до контракту, опис арбітражного процесу.
Аудит (2-3 тижні). Фокус на логіці таймаутів, multi-party fund release, reentrancy при виплатах.
Пілотний запуск. Перші сделки з маленькими сумами на тестових об'єктах, юридичне супроводження.
Ориєнтири по строкам
Базовий еськроу контракт (два учасники + арбітр, один milestone) — 1-2 тижні. Повнофункціональна система з multiple milestones, EscrowFactory, Chainlink Automation для таймаутів та фронтендом для сторін сделки — 4-8 тижнів. Інтеграція з tokenized title registry (якщо доступна в юрисдикції) — окремий проект від 3 місяців.
Вартість визначається складністю юридичної структури та вимогами до автоматизації.