Разработка системы 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 — мы поможем спроектировать и внедрить решение под ключ.