Представьте: мультисиг-кошелек с 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 (заблокировать). Это бизнес-решение, но его нужно зафиксировать.
| Провайдер | Особенности | Latency | Покрытие сетей |
|---|---|---|---|
| Chainalysis | KYT, риск-скоры | 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 — мы поможем спроектировать и внедрить решение под ключ.