Разработка системы policy engine для управления транзакциями

Представьте: мультисиг-кошелек с 5 подписантами, daily limit $2M. Сотрудник инициирует вывод $1.8M на адрес, который час назад попал в санкционный список OFAC. Подписи собраны, но policy engine на этапе pre-check обращается к Chainalysis KYT, получает риск-скор 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 проверяет адреса (риск-скор) и транзакции (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 (заблокировать). Это бизнес-решение, но его нужно зафиксировать.

Как мы реализуем policy engine?

1. Анализ требований — определяем бизнес-правила, compliance-обязательства, технические ограничения (latency, throughput).
2. Проектирование модели правил — проектируем иерархию правил, условия, действия, политики при конфликтах.
3. Разработка evaluator'а — пишем ядро движка с short-circuit evaluation, кэшем и интеграцией с внешними API.
4. Интеграция и тестирование — подключаем движок к кошельку или мультисигу, проводим нагрузочное и регрессионное тестирование.

Закажите разработку policy engine, чтобы защитить свои активы.

Мониторинг и аудит

Система правил без полного audit log бесполезна для compliance. Каждое решение должно содержать:

• Transaction hash или pre-tx ID
• Список применённых правил и их результаты
• Значения всех условий в момент оценки
• Финальное решение и исполнитель
• Timestamp с точностью до миллисекунды

Это неизменяемый лог. Хранение: PostgreSQL с append-only таблицей + репликация в S3/Arweave для long-term retention. Для регуляторных требований — минимум 5 лет.

Что входит в разработку

• Проектная документация (архитектура, модель правил)
• Исходный код движка (off-chain evaluator и on-chain hooks)
• Интеграция с compliance-провайдерами (Chainalysis, Elliptic и др.)
• Настройка кэширования и graceful degradation
• Развёртывание и настройка audit log
• Обучение команды и документация администратора
• Пост-релизная поддержка на 3 месяца

Получите консультацию по внедрению policy engine — мы поможем спроектировать и внедрить решение под ключ.