Техническая архитектура протокола RUBT и технологии управляемых кошельков
Преамбула
RUBT обращается в глобальной криптосреде как стандартный ERC-20-токен,. Исполнение денежного требования 1 RUB за 1 RUBT возможно на выбранных Платформах исполнения, путем обращения к Агенту-исполнителю . Ключевая техническая задача — связать свободное on-chain обращение с контролируемым контуром исполнения так, чтобы операции перехода прав требования, были синхронизированы с реестром партнёрской Платформы исполнения и не могли «разъехаться». Ответом является двухслойная архитектура «публичный блокчейн + Платформы исполнения» и технология управляемых кошельков, разработанная Tetris как интеграционный слой для подключения широкого спектра партнёров-платформ исполнения.
4.1. Двухслойная модель: публичные блокчейны + Платформы исполнения
Архитектура RUBT строится как связка двух логически разделенных слоев.
1) Глобальный криптослой (Ethereum и совместимые сети) RUBT функционирует как стандартный ERC-20-совместимый токен, свободно обращающийся в криптосреде и совместимый с DeFi-протоколами (DEX, лендинг, деривативы и т.п.). Токен может находиться как на обычных EOA-адресах, так и на смарт-аккаунтах EIP-4337 (управляемых кошельках).
2) Регулируемый слой (Платформы исполнения) Платформа исполнения — это партнёрская инфраструктура, имеющая юридическое право работать с цифровыми правами с расчётами в фиатных рублях и обеспечивающая (i) допуск цифрового права, (ii) ведение юридически значимого реестра/учёта, (iii) подачу и исполнение заявок, включая buyback 1 RUBT = 1 RUB через Агента, действующего от имени и за счёт Эмитента. При размещении RUBT в периметре конкретной Платформы исполнения возникает денежное требование к Эмитенту в размере 1 RUB за 1 RUBT, которое реализуется исключительно в рублях и исключительно через обращение к Агенту-исполнителю на Платформе исполнения.
Технический «шлюз» между слоями — управляемый кошелёк Управляемый кошелёк связывает криптографически on-chain баланс RUBT и запись (учёт) на Платформе исполнения, обеспечивая инвариант синхронности операций, влияющих на денежное требование.
4.2. Смарт-контракт RUBT
Контракт RUBT реализован как ERC-20-совместимый токен с расширенной ролевой моделью и набором стандартных функций для инфраструктурной совместимости.
Базовые функции и расширения
стандартные ERC-20 операции: transfer, transferFrom, approve;
поддержка EIP-2612 (Permit) и EIP-3009 (off-chain authorizations) для безопасных и удобных сценариев авторизаций вне сети.
Роли управления
Owner — верхнеуровневый администратор токен-контрактов, контролируемый DAO-уровнем;
Master Minter — назначает/отзывает минтеров и устанавливает лимиты выпуска;
Minter — выполняет выпуск и сжигание в пределах установленных лимитов;
Pauser — приостанавливает трансферы в аварийных ситуациях в рамках политики безопасности.
Принципиальная граница комплаенса Контракт RUBT не содержит ончейн-механизмов блокировки адресов (blacklist): комплаенс и проверки реализуются на стороне Платформ Исполнения с соответствующими процедурами, а не через цензуру транзакций в токен-контракте.
4.3. Управляемые кошельки как технология интеграции с партнёрами-Платформами исполнения
Управляемые кошельки (managed wallets) — это технологический интеграционный слой, разработанный Tetris для подключения партнёров-Платформ исполнения к протоколу RUBT без потери инвариантов «on-chain ↔ реестр/учёт Платформы исполнения».
Техническая форма: EIP-4337 (Account Abstraction) Управляемый кошелёк пользователя — это смарт-аккаунт в Ethereum, работающий через EIP-4337 и инфраструктурные контракты (включая контракт-релейер WhitelistRelayer). Tetris предоставляет партнёрам технологическую реализацию и контрактную обвязку для интеграции; конкретная Платформа исполнения встраивает её в собственный контур процессов проверок и исполнения заявок по своим правилам и в рамках применимого права.
Требования к свойствам управляемых кошельков
Генерация ключей и единая идентичность действий Платформа исполнения предоставляет возможность генерации ключей для подписи управляемого кошелька в сети Ethereum.
Двойная подпись и whitelisting операций Любое действие с RUBT, которое влияет на объём/статус денежного требования в периметре Платформы исполнения, требует:
подписи пользователя;
технической подписи (авторизации) Платформы исполнения. WhitelistRelayer проверяет соответствие операции конкретной заявке/событию на Платформе исполнения и отклоняет транзакции, не прошедшие проверку.
Инварианты зеркальности «учёт Платформы исполнения ↔ on-chain» Смарт-кошелёк и релейер блокируют операции, которые приводят к рассинхронизации: транзакции, не подтверждённые Платформой исполнения, не исполняются. Тем самым технически исключается сценарий, при котором:
в учёте Платформы исполнения появляется запись без равного on-chain баланса на управляемом кошельке;
on-chain операция, происходит без соответствующей операции в контуре Платформы исполнения.
4.4. Взаимодействие с Платформами исполнения: ввод, вывод и операции с RUBT
Платформы исполнения реализуют операции с RUBT через стандартные пользовательские сценарии в соответствии с требованиями ниже:
Ввод (размещение) RUBT на Платформе исполнения Размещение RUBT Пользователем на Платформе исполнения происходит по правилам Платформы исполнения, на основании заявки пользователя. Это запускает AA-операцию с управляемого кошелька и формирует синхронную запись (учёт) в контуре Платформы исполнения в соответствии с её правилами допуска, KYC/AML и процедурой учёта цифрового права.
Вывод RUBT из периметра Платформы исполнения Вывод RUBT Пользователем на Платформе исполнения происходит по правилам Платформы исполнения, на основании заявки пользователя. После этого управляемый кошелёк разблокирует вывод RUBT в свободное on-chain обращение.
Операции внутри Платформы исполнения (торги/переводы в периметре) Сделки между пользователями и/или Агентом-исполнителем отражаются и в учёте Платформы исполнения, и в сети Ethereum на управляемых кошельках. Денежное требование следует за токеном RUBT в периметре выбранной Платформы исполнения и реализуется через обращение к Агенту по процедуре buyback.
4.5. DAO-уровень и безопасность протокола
Управление протоколом и критическими изменениями реализуется через связку смарт-контрактов инфраструктуры и процедур DAO-контроля.
Компоненты управления и защиты
смарт-контракты RUBT и управляющей инфраструктуры (включая WhitelistRelayer, UserWallet, Beacon, EntryPoint);
DAO-мультисиг, timelock и CRC (Compliance & Risk Committee), контролирующие критичные изменения и emergency-функции;
голосование veTETRIS-держателей по вопросам апгрейдов, лимитов и архитектурных параметров.
Цель этой конструкции — обеспечить устойчивость протокола и управляемость рисков при сохранении способности адаптироваться к изменениям регуляторного и рыночного ландшафта, не нарушая базовые юридические инварианты RUBT и модель исполнения денежного требования через Агента- исполнителя и партнерские Платформы исполнения.
Последнее обновление