Уявіть: мультисиг-гаманець із 5 підписантами, daily limit $2M. Співробітник ініціює виведення $1.8M на адресу, яка годину тому потрапила до санкційного списку OFAC. Підписи зібрані, але policy engine на етапі pre-check звертається до Chainalysis KYT, отримує risk-скор 85 — транзакція блокується. Без такого движка гроші були б заморожені на тижні, а компанія отримала б штраф до $500 000. Ми проектуємо та впроваджуємо систему правил для кастодіальних гаманців і корпоративних мультисигів. Движок застосовує набір правил до підписання — це ключова відмінність від пост-обробки. Наша команда має 8 років досвіду в блокчейн-розробці та понад 40 впроваджень для великих кастодіальних рішень.
Як працює система управління транзакціями?
Policy engine — шар між ініціатором і виконанням. Він оцінює правила до того, як транзакція йде на підпис і в мемпул. Правила перевіряють параметри, контекст (роль відправника, час), зовнішні дані (compliance API) та on-chain стан. Результат: дозволити, відхилити, запитати дод. підписи або відкласти.
Згідно зі специфікацією Safe{Core} Protocol Hooks, preCheck викликається до виконання транзакції.
Архітектура системи правил
Рівні застосування політик — розробка системи policy
Движок політик може існувати на кількох рівнях — їх часто змішують, що породжує проблеми:
- Off-chain pre-execution — найпоширеніший. Правила перевіряються в сервісі до підписання. Гнучкий, дешевий, підтримує будь-яку логіку. Недолік: потребує довіри до цього сервісу.
- On-chain enforcement — смарт-контракт, точка входу для всіх транзакцій. Safe{Core} Protocol Hooks — приклад. Гарантії сильніші, але логіка обмежена on-chain: немає доступу до зовнішніх даних без оракулів, кожна перевірка коштує gas.
- Hybrid — політики верифікуються off-chain, контракт приймає proof (commitment scheme або trusted signer attestation).
Чому варто комбінувати off-chain і on-chain?
Off-chain evaluation в 10 разів швидше і не витрачає gas, але on-chain дає незмінні гарантії. Оптимальне рішення — гібридна архітектура: швидкі off-chain правила як перший фільтр, критичні політики (ліміти протоколу) — у смарт-контрактах. В одному проєкті ми обробляємо 500+ правил з latency під 5 мс, економія часу на ручній модерації сягає 70%. Вартість розробки оцінюється індивідуально, але окупається за рахунок скорочення compliance-інцидентів. Одна не заблокована транзакція може зекономити понад $1 млн, а річна економія — до $5 млн.
Модель правил
Правило складається з умови та дії. Умови можуть бути:
- Параметричні:
amount > threshold,recipient in whitelist,token == USDC - Контекстуальні:
sender.role == OPERATOR,time_of_day in 09:00-18:00,daily_volume + amount <= limit - Зовнішні:
chainalysis_risk_score(recipient) < 70,ofac_check(recipient) == CLEAR - On-chain:
recipient.is_contract == false,token.paused == false
Дії: ALLOW, DENY, REQUIRE_APPROVAL(n_signers), DELAY(duration), NOTIFY(channels).
Правила мають пріоритети, можливі конфлікти. Потрібна чітка семантика: first-match, all-must-pass, whitelist-overrides-blacklist. Це проєктне рішення.
Приклад інтерфейсу правила
interface PolicyRule {
id: string;
priority: number;
conditions: Condition[];
conditionLogic: 'AND' | 'OR';
action: PolicyAction;
metadata: { name: string; owner: string; updatedAt: number };
}
interface PolicyAction {
type: 'ALLOW' | 'DENY' | 'REQUIRE_APPROVAL' | 'DELAY';
params?: {
requiredApprovers?: string[];
minApprovals?: number;
delaySeconds?: number;
notifyChannels?: string[];
};
}
Evaluator: порядок обчислення
Движок повинен обробляти правила ефективно — особливо коли правил сотні, а частина потребує зовнішніх викликів (API compliance провайдера).
Оптимальна стратегія: short-circuit evaluation з кешуванням. Спочатку перевіряються дешеві локальні умови (параметри транзакції, ролі), потім кешовані зовнішні дані, останніми — свіжі API-виклики з таймаутом.
class PolicyEvaluator:
def evaluate(self, tx: Transaction, context: EvalContext) -> PolicyDecision:
sorted_rules = sorted(self.rules, key=lambda r: r.priority, reverse=True)
for rule in sorted_rules:
cheap_conditions = [c for c in rule.conditions if c.type == 'PARAMETRIC']
if not self._eval_conditions(cheap_conditions, tx, context):
continue
expensive_conditions = [c for c in rule.conditions if c.type == 'EXTERNAL']
cache_key = self._cache_key(expensive_conditions, tx)
cached = self.cache.get(cache_key)
results = cached if cached else self._eval_external(expensive_conditions, tx)
self.cache.set(cache_key, results, ttl=300)
if self._eval_conditions_with_results(rule.conditions, results, rule.conditionLogic):
return PolicyDecision(action=rule.action, rule_id=rule.id)
return PolicyDecision(action=DEFAULT_ACTION)
On-chain реалізація: Safe Hooks
Safe{Core} Protocol (EIP-7579 сумісний) надає механізм хуків:
interface ISafeProtocolHooks {
function preCheck(
Safe safe,
SafeTransaction calldata tx,
uint256 executionType,
bytes calldata executionMeta
) external returns (bytes memory preCheckData);
function postCheck(
Safe safe,
bool success,
bytes calldata preCheckData
) external;
}
preCheck викликається до виконання. Якщо revert — транзакція не проходить. Тут можна: перевірити whitelist/blacklist (зберігається в storage хука), перевірити ліміти (через акумулятори за адресами/токенами), вимагати додатковий approval через timelock.
Приклад лімітного хука:
contract DailyLimitHook is ISafeProtocolHooks {
mapping(address => mapping(address => uint256)) public dailyVolume;
mapping(address => mapping(address => uint256)) public lastResetDay;
mapping(address => mapping(address => uint256)) public dailyLimit;
function preCheck(Safe safe, SafeTransaction calldata tx, uint256, bytes calldata)
external returns (bytes memory)
{
address token = _extractToken(tx.data);
uint256 amount = _extractAmount(tx.data);
uint256 today = block.timestamp / 1 days;
address safeAddr = address(safe);
if (lastResetDay[safeAddr][token] < today) {
dailyVolume[safeAddr][token] = 0;
lastResetDay[safeAddr][token] = today;
}
require(
dailyVolume[safeAddr][token] + amount <= dailyLimit[safeAddr][token],
"DailyLimitExceeded"
);
return abi.encode(token, amount);
}
function postCheck(Safe safe, bool success, bytes calldata preCheckData) external {
if (success) {
(address token, uint256 amount) = abi.decode(preCheckData, (address, uint256));
dailyVolume[address(safe)][token] += amount;
}
}
}
Як інтегрувати compliance API?
Для фінансових продуктів policy engine неминуче включає інтеграцію з compliance провайдерами. Основні:
- Chainalysis — KYT API перевіряє адреси (risk-скор) і транзакції (exposure до відомих кластерів). Latency: 200–800ms, потрібен кеш і graceful degradation.
- Elliptic — аналогічний функціонал, інша модель оцінки ризику. Використовується в Fireblocks.
- TRM Labs — спеціалізується на cross-chain аналізі, добре покриває Solana і Tron.
- OFAC screening — можна через ті ж провайдери або через самостійно підтримуваний snapshot SDN списку (оновлюється нечасто, можна зберігати локально та оновлювати через webhook).
Важливий момент: compliance API мають SLA і можуть бути недоступні. Policy engine повинен мати явну політику для випадку EXTERNAL_CHECK_TIMEOUT: fail-open (дозволити з логом) vs. fail-closed (заблокувати). Це бізнес-рішення, але його потрібно зафіксувати.
| Провайдер | Особливості | Latency | Покриття мереж |
|---|---|---|---|
| Chainalysis | KYT, risk-скори | 200-800ms | Ethereum, Bitcoin, 10+ мереж |
| Elliptic | Акцент на санкції | 300-600ms | Основні L1 |
| TRM Labs | Крос-чейн, Solana | 150-500ms | 30+ мереж |
Як ми реалізуємо policy engine?
- Аналіз вимог — визначаємо бізнес-правила, compliance-зобов'язання, технічні обмеження (latency, throughput).
- Проектування моделі правил — проектуємо ієрархію правил, умови, дії, політики при конфліктах.
- Розробка evaluator'а — пишемо ядро движка з short-circuit evaluation, кешем та інтеграцією із зовнішніми API.
- Інтеграція та тестування — підключаємо движок до гаманця або мультисигу, проводимо навантажувальне та регресійне тестування.
Замовте розробку policy engine, щоб захистити свої активи.
Моніторинг та аудит
Система правил без повного audit log марна для compliance. Кожне рішення повинно містити:
- Transaction hash або pre-tx ID
- Список застосованих правил та їх результати
- Значення всіх умов на момент оцінки
- Фінальне рішення та виконавець
- Timestamp з точністю до мілісекунди
Це незмінний лог. Зберігання: PostgreSQL з append-only таблицею + реплікація в S3/Arweave для long-term retention. Для регуляторних вимог — мінімум 5 років.
| Компонент | Технологія |
|---|---|
| Rule storage | PostgreSQL + Redis cache |
| Evaluator | Go / Python service |
| On-chain hooks | Solidity (Safe Protocol) |
| Compliance API | Chainalysis / Elliptic / TRM |
| Audit log | PostgreSQL → S3 |
| Admin UI | React + role-based access |
Що входить у розробку
- Проєктна документація (архітектура, модель правил)
- Вихідний код движка (off-chain evaluator та on-chain hooks)
- Інтеграція з compliance-провайдерами (Chainalysis, Elliptic та ін.)
- Налаштування кешування та graceful degradation
- Розгортання та налаштування audit log
- Навчання команди та документація адміністратора
- Пост-релізна підтримка на 3 місяці
Отримайте консультацію з впровадження policy engine — ми допоможемо спроектувати та впровадити рішення під ключ.