Как устроена платформа ТМГТ

Центральный объект интеграции — намерение совершить операцию. Оно описывает инициатора, актив, сеть, сумму, получателя и требуемое действие. Защита ключа дополняется проверкой того, какой эффект создаст транзакция и имеет ли инициатор право его создавать.

• Намерение → симуляция → эффект транзакции.
• Политики → риск T1 → формальный допуск.
• MPC-исполнение → контролируемая публикация → мониторинг и аудит.

Один технологический контур используется в четырех продуктовых моделях. Кошельки подходят для встраивания в клиентский продукт; полный контур объединяет управление активами и операциями; отдельный слой безопасности проверяет операции существующей инфраструктуры; депозитарная технология поддерживает работу профильной организации.

• Digital Asset Control Infrastructure.
• Wallet Infrastructure / WaaS.
• Digital Depositary Technology.
• Transaction Security & Compliance Layer.

Прикладной backend передает бизнес-намерение и получает состояние операции. Доли ключа и секретные криптографические артефакты остаются в MPC/HSM-контуре. T1 оценивает риск, но не получает прямого доступа к ключам и не отменяет детерминированные политики.

ТМГТ предоставляет технологическую инфраструктуру. Использование API или депозитарного модуля само по себе не предоставляет банковский, брокерский или иной регулируемый статус. Услуга qualified custody не входит в описанный набор возможностей.

Для первого прохода достаточно одного инициатора, кошелька, актива, получателя и лимита. Используйте тестовые идентификаторы и заранее запишите ожидаемый результат: допустимая операция проходит проверки, превышение лимита останавливается до подписи.

• Укажите назначение проекта и ответственного за политики.
• Зафиксируйте сеть, актив и бизнес-действие будущей интеграции.
• Разделите пользовательское подтверждение, решение политик и криптографическое исполнение.

Передайте инициатора, кошелек, актив, получателя и сумму. Сопоставьте результат симуляции с намерением, примените политики и оценку риска. Свяжите разрешение на подпись с конкретным контекстом операции.

Проверьте превышение лимита, запрещенного получателя, высокий риск и исчерпание бюджета комиссии. Каждый отказ должен оставлять понятную причину и останавливать переход к подписи.

Зафиксируйте адреса окружений, механизм аутентификации, версию API и настройки событий для проекта. Назначьте владельцев политик, доступа, мониторинга и восстановления.

Создание кошелька должно быть связано с идентичностью клиента или организации, назначением и набором разрешенных операций. Кошелек в интерфейсе продукта и криптографический ключ — разные сущности: приложение управляет доступом и намерениями, а защищенный контур управляет криптографическим исполнением.

Передавайте смысл операции, затем проверяйте рассчитанный эффект, лимиты, согласования и риск. Изменение получателя, суммы или прав контракта создает другой контекст проверки. Ранее полученный допуск не следует считать разрешением на измененную операцию.

Изменение MPC-конфигурации и восстановление узлов относятся к отдельным контролируемым процедурам. Приложение должно понимать состояния остановки или конфликта и не пытаться решать их повторным независимым подписанием той же бизнес-операции.

Аутентификация устанавливает, кто обращается к продукту: пользователь, сотрудник, сервис или программный агент. В бизнес-контексте операции сохраняйте устойчивый идентификатор инициатора и его связь с организацией. Конкретный провайдер и формат сессии задаются рабочей конфигурацией проекта.

Наличие сессии не означает право распоряжаться любым кошельком или активом. Политики учитывают роль, владельца ресурса, сеть, тип действия, лимиты и согласования. Для агента дополнительно проверяется его мандат: какие операции и в каких пределах ему разрешены.

• Разделяйте доступ к чтению, созданию намерения и согласованию.
• Не переносите клиентские признаки роли в доверенный контекст без проверки.
• Применяйте изменения доступа к новым операциям и явно обрабатывайте незавершенные.

Вход в кабинет, подтверждение пользовательского намерения и разрешение MPC-контуру — самостоятельные события. Даже успешно аутентифицированный инициатор проходит симуляцию, политики и оценку риска. Положительное решение связывается с конкретной операцией, а не с неограниченным использованием ключа.

Gas sponsorship позволяет оплатить сетевую комиссию за пользователя в рамках заданных правил. Возможность спонсирования не означает бесплатную сеть. Комиссия зависит от операции и состояния сети; бюджет спонсора учитывается отдельно от стоимости инфраструктурного тарифа.

Определите проект, разрешенные сети и действия, допустимых инициаторов, период и предел расходов. До публикации операция должна соответствовать одновременно бизнес-политике и правилам спонсирования. Наличие средств у спонсора не отменяет ограничения на сам перевод.

• Общий бюджет и лимит на одну операцию.
• Допустимые получатели, контракты или типы действия.
• Поведение при исчерпании бюджета и изменении оценки комиссии.
• Уведомления и история расходования.

Оценка комиссии до публикации может отличаться от итогового расхода. Сохраняйте оценку, принятое решение о спонсировании и фактическую комиссию отдельно. Если новый расход выходит за разрешенные пределы, используйте предусмотренный процесс повторной проверки, а не молчаливое увеличение лимита.

Политика проверяет инициатора и его роль, актив и сеть, тип действия, сумму, адрес назначения, согласования, время и сигналы риска. Начинайте с минимального набора разрешенных действий. Отсутствие подходящего разрешающего правила должно оставлять операцию без допуска.

Прикладной контур проверяет бизнес-полномочия и контекст допуска. Onchain-политики задают ограничения, исполняемые в соответствующей сетевой или контрактной конфигурации. Их конкретная модель зависит от поддерживаемой сети; правило в приложении не следует автоматически считать опубликованным смарт-контрактом.

Сохраняйте версию правил, действовавшую при проверке, результаты отдельных условий и причины отказа. После изменения политики незавершенные операции должны обрабатываться по явно определенному правилу повторной проверки. Одноразовое разрешение нельзя переносить на другой контекст.

• Лимиты и разрешенные адреса.
• Роли и необходимые согласования.
• Порог риска и реакция на недоступность внешних данных.
• Версия конфигурации и правила отмены или повторной проверки.

Симуляция помогает выявить перемещение активов, изменение балансов и разрешений, вызовы контрактов, создаваемые события и комиссии. Для другой модели сети анализ учитывает ее структуру: например, входы, выходы, адреса и скрипты. Набор доступных результатов зависит от сети и типа операции.

Пользователь может намереваться перевести определенную сумму, тогда как подготовленная транзакция дополнительно меняет права распоряжения активами. Передавайте рассчитанный эффект в политики и T1 и проверяйте соответствие исходной задаче, получателю, активу и допустимым изменениям полномочий.

Симуляция описывает результат для использованного состояния сети. До публикации состояние может измениться, поэтому симуляция не является гарантией будущего исполнения. Фиксируйте контекст расчета и условия, при которых операция должна быть проверена повторно.

T1 использует намерение, результат симуляции, состояние сети, KYT-данные, историю операций, клиентский и поведенческий контекст, а также графовые признаки. Доступность конкретного сигнала зависит от подключенных источников и модели использования.

Оценка риска нужна не только в виде числа. Для расследования и согласования полезны факторы, повлиявшие на результат, исходный контекст и примененная политика реакции. Сохраняйте различие между обнаруженным признаком, оценкой риска и окончательным решением о допуске.

Положительная оценка T1 не разрешает действие, запрещенное политикой. Превышение установленного порога риска блокирует переход к подписи. T1 и AI Assistant не получают полномочий самостоятельно использовать доли ключа или изменить решение политик.

В распределенной генерации на независимых MPC-узлах формируются доли ключа. Для подписи требуется заданный криптографический порог участников. Профили FROST, DKLS23 и CGGMP24 выбираются с учетом требований сети, кривой и формата подписи; прикладной разработчик не должен самостоятельно подменять этот выбор в клиентском коде.

Backend управляет запросами и состоянием операции. Доли ключа, nonce и presign-артефакты остаются в защищенном MPC/HSM-контуре. Разрешение на криптографический шаг связано с конкретной операцией, ключом, конфигурацией и стадией; оно не дает универсального доступа к ключу.

Если необходимый порог сохраняется, оставшиеся участники продолжают контролировать тот же публичный ключ. При потере порога используется отдельно защищенная процедура восстановления. Зашифрованное состояние восстановления отделяется от полномочий и средств расшифрования; полный приватный ключ не используется как постоянно хранящаяся резервная копия.

Сформированная подпись еще не означает, что транзакция отправлена или исполнена сетью. После криптографического шага применяется отдельный контроль публикации. Отслеживайте отправку, наблюдаемое состояние и итоговый результат и связывайте их с исходным намерением.

Webhook сообщает о событии, а состояние операции остается предметом сверки. В интеграции заранее предусмотрите повторную доставку и изменение порядка событий. Обрабатывайте идентификатор события идемпотентно и сверяйте допустимость перехода состояния. Это рекомендации для потребителя событий, а не обещание конкретного режима доставки ТМГТ.

• Храните идентификатор события и связанной операции.
• Повторная доставка не должна создавать второй перевод или учетную запись.
• Проверяйте подлинность уведомления по фактической схеме рабочего API.
• Уточните расписание повторов, срок хранения и способ восстановления пропусков в контракте интеграции.

Аудиторский след связывает намерение, симуляцию, версию политик, решение T1, согласования, криптографическую стадию, решение о публикации и внешний результат. Если после сбоя надежно зафиксирован выполненный шаг, восстановление использует этот результат вместо новой независимой операции.

Пользовательский интерфейс, backend, согласующий сотрудник, агент и криптографический контур выполняют разные роли. Предоставляйте каждому только необходимые полномочия. Изменение политики, управление доступом и восстановление требуют самостоятельных контролируемых процедур.

Рабочие секреты интеграции передаются через защищенную конфигурацию среды. Не помещайте их в клиентский код, URL, журналы или скачиваемые примеры. В аудит записывайте идентификаторы, решения и причины переходов; секретные MPC-артефакты туда не входят.

Тайм-аут не доказывает, что операция не была выполнена. Сначала восстановите ее состояние по устойчивому идентификатору, затем решайте вопрос продолжения. При конфликте состояний остановите автоматический сценарий и используйте предусмотренный процесс разбирательства.

• Один бизнес-запрос — один устойчивый идентификатор намерения.
• Повторная попытка должна сохранять идентичность запроса.
• Измененное содержимое требует новой проверки.
• Политика отказа при недоступном риск-сигнале задается заранее.

Dedicated Managed Environment и On-premise / Customer-Controlled Deployment сохраняют разделение управления и криптографии. Размещение компонентов, HSM и участников порога определяется моделью доверия клиента. Конкретные сетевые требования и инфраструктурные профили берутся из рабочего комплекта развертывания.

Проверьте адреса сред, версию API, механизм доступа, лимиты и правила совместимости.

• Поддерживаемые сети, активы и операции.
• Форматы сумм, комиссий, ошибок и идентификаторов.
• Состояния операции и идемпотентность.
• Аутентификация, роли и параметры событий.

Пройдите допустимую операцию, отказ по политике, недостаток бюджета спонсора, изменившийся эффект, высокий риск, тайм-аут и повторную доставку события. Отдельно проверьте восстановление незавершенной операции и сверку внешнего результата с внутренним учетом.

Назначьте владельцев политик, доступа, инфраструктуры, реагирования и учета. Зафиксируйте источники мониторинга, формат аудита, правила хранения и процедуру восстановления. Численные SLA и сроки реакции используются только из реально согласованных условий сервиса.

Зафиксируйте включенный объем, дополнительные операции, сетевые комиссии и внешние провайдерские расходы. Право пользоваться тарифом и право выполнять регулируемую деятельность определяются отдельно.