Центробанки внедрили Scroll (SCR) в международные расчеты?

Оригинал отчета: BIS

Project Rialto: что именно протестировали на Scroll и почему вокруг этого столько шума.

Предисловие
Кроссбордер‑переводы «для обычных людей» (ремиттансы, P2P‑платежи, небольшие международные переводы через банки и финтех‑провайдеров) до сих пор часто проигрывают внутренним переводам по цене, скорости и предсказуемости. Причина обычно не в одном «злодее», а в цепочке: иностранная валюта (FX), несколько посредников, разные правила и инфраструктуры, а также риски на этапе расчётов (settlement).

В декабре 2025 BIS Innovation Hub опубликовал технический отчёт Project Rialto. Это не рекламный анонс и не запуск «гос‑платежей на блокчейне», а инженерный proof‑of‑concept: собрали и прогнали архитектуру, которая связывает привычные мгновенные платёжные системы с токенизированным FX и расчётом в токенизированных деньгах центрального банка. Для «DLT‑части» эксперимента смарт‑контракты развернули на публичном L2‑тестнете Scroll (Scroll Sepolia).

Кто участвовал: какие именно организации
В Project Rialto участвовали:

• BIS Innovation Hub — исследовательско‑инженерное подразделение Банка международных расчётов (BIS), которое делает прикладные прототипы для центральных банков и регуляторов.
• Banque de France (Банк Франции) — центральный банк Франции, часть Евросистемы.
• Banca d’Italia (Банк Италии) — центральный банк Италии, часть Евросистемы.
• Bank Negara Malaysia — центральный банк Малайзии.
• Monetary Authority of Singapore (MAS) — центральный банк и финансовый регулятор Сингапура.

Дополнительно в списке наблюдателей/контрибьюторов фигурируют представители Deutsche Bundesbank и Европейского центрального банка (как observers), но ядро эксперимента — пять организаций выше.

Что пытались доказать и почему это важно
Цель Rialto — показать техническую реализуемость связки:

1. «обычная» платёжная инфраструктура (мгновенные платежи, ISO 20022‑сообщения, комплаенс у провайдеров);
2. автоматизированный FX на смарт‑контрактах (через AMM‑механизм);
3. расчёт по FX‑ноге в токенизированных деньгах центрального банка (tokenised CeBM) как в наиболее надёжном расчётном активе;
4. всё это — с логикой PvP (payment‑versus‑payment), чтобы минимизировать риск «одна сторона заплатила, а другая — нет».

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

Как устроен Rialto: два блока, которые связали между собой
Архитектура разделена на два функциональных блока.

Блок 1: мгновенные платежи и “межсистемная связка”
Это симуляция привычного мира платежей:

• PSP (Payment Service Provider) — платёжный провайдер клиента (банк/финтех): принимает поручение, проводит комплаенс‑проверки, блокирует/списывает/зачисляет средства клиентам.
• IPS (Instant Payment System) — национальная/региональная система мгновенных платежей: проводит маршрутизацию и расчёт внутри юрисдикции.
• IPS link — «хаб», который связывает IPS разных юрисдикций по стандартной логике (аналогично идеям из Project Nexus): передаёт сообщения, считает комиссии, валидирует котировки, трансформирует форматы сообщений между странами.
• Сообщения используются из семейства ISO 20022: основная платёжная инструкция — pacs.008; статусы/подтверждения — pacs.002.

Блок 2: DLT‑слой для FX и расчёта
Это экспериментальная «нейтральная» кроссбордер‑DLT‑сеть (в отчёте обозначена как XDN), где происходят:

• FX‑обмен между валютами;
• расчёт в токенизированном CeBM (между участниками);
• атомарность (всё или ничего) и PvP‑логика.

И вот здесь появляется Scroll.

Причём тут Scroll: роль блокчейна в эксперименте
Scroll использован как инфраструктурная среда для блока 2.

В PoC смарт‑контракты разработали под EVM (Ethereum Virtual Machine), то есть под «совместимую с Ethereum» среду исполнения. Затем для развёртывания выбрали Scroll, а конкретно Scroll Sepolia Testnet.

Почему это важно и что это означает:

• Это означает: инженеры проекта реально развернули и использовали смарт‑контракты (FX, расчёт, токены) в сети Scroll (на тестнете) как часть официально описанного PoC.
• Это не означает: «центробанки запускают расчёты на Scroll mainnet» или «Scroll стал государственной платёжной рельсой». В отчёте прямо говорится о симуляции на тестнете публичного L2, чтобы имитировать нейтральную DLT‑сеть.

Причины выбора Scroll в отчёте описаны прагматично: публичный тестнет (не надо поднимать private chain), L2‑среда (короткие блок‑таймы), ZK‑rollup (валидити‑пруфы и детерминированная финальность), плюс очень конкретная инженерная деталь — поддержка PUSH0 (EIP‑3855), необходимая для redeploy‑скриптов Uniswap v3, на момент разработки доступная именно на Scroll Sepolia среди ZK‑rollup тестнетов.

Что именно сделали на Scroll: какие контракты и действия
В блоке 2 PoC использовал набор смарт‑контрактов и ончейн‑компонентов:

1. Токены tokenised CeBM
   Для каждой валюты «центробанковские деньги» представлены смарт‑контрактом в формате ERC‑20 (упрощённо: токен, который можно переводить по правилам контракта). В отчёте отдельно отмечено, что контракт определяет список потенциальных держателей и управляет жизненным циклом токена.
2. Settlement Orchestrator (SO)
   Это нейтральный смарт‑контракт‑«оркестратор», который задаёт общие правила расчёта и снижает контрагентский риск: шаги фиксированы и прозрачны, а события (events) можно отслеживать для синхронизации с «офчейн»‑частью.
3. FXP (Foreign Exchange Provider) как смарт‑контракт
   FX‑провайдер отвечает за котировки и покрытие проскальзывания (slippage). В PoC FXP реализован как один контракт: он может вернуть котировку и затем исполнить её. Для упрощения использовался фиксированный процентный спред — это сделано для быстрых итераций без построения «полного стека» ликвидности.
4. AMM‑механизм Uniswap v3
   Обмен валюты выполняется через AMM (автоматизированный маркет‑мейкер) — в PoC выбран Uniswap v3, потому что он даёт концентрированную ликвидность и удобен как зрелая опенсорсная конструкция.
5. Кошельки SAP и требования к ним
   В блокчейн‑слой «пишут» не конечные клиенты, а специализированные посредники:

• SAP (Settlement Access Provider) — участник, который умеет работать и с обычной платёжной инфраструктурой, и с DLT‑слоем. Он предоставляет PSP доступ к XDN‑слою, делает on‑/off‑ramp и действует как «мост».
• Для PoC SAP‑кошельки должны быть в allowlist (whitelist) и иметь тестовый ETH в сети Scroll, чтобы вызывать функции инициализации и валидации расчёта (чтение состояния не требует баланса).

6. Минимизация ончейн‑нагрузки
   Отдельно подчёркнуто: на один расчёт — всего две ончейн‑транзакции (по одной от каждого SAP). Это сделано, чтобы throughput не становился узким местом даже при умеренных задержках сети.

Как проходил тестовый платёж: четыре сегмента в правильной последовательности
В отчёте основной сценарий разложен на четыре сегмента (и в функциональном приложении приводится детальная 50‑шаговая последовательность). Ниже — то же самое, но в «читаемом» виде.

Сегмент 1: получение котировки (quote provision)

• Отправитель вводит параметры перевода (кому, сколько, валюта).
• PSP отправителя через свою IPS и IPS link запрашивает котировку у FX‑провайдера (FXP).
• FXP берёт ончейн‑цену из AMM, добавляет свой спред и возвращает binding‑котировку.
• IPS link добавляет сервисные комиссии и возвращает PSP итоговую «полную стоимость» (курс + комиссии), чтобы показать клиенту до подтверждения платежа.

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

Сегмент 2: подготовка кроссбордер‑расчёта (cross-border settlement preparation)

• Клиент подтверждает перевод. PSP блокирует средства у отправителя и формирует платёжную инструкцию pacs.008 (ISO 20022).
• IPS на стороне источника тоже блокирует средства на уровне расчётных счетов участников (в логике PoC).
• Источниковый SAP принимает условия и готовит ончейн‑часть: делает вызов в Settlement Orchestrator, создавая запись будущего расчёта с уникальной ссылкой (UETR).
• IPS link сверяет: котировка, которую видит в pacs.008, совпадает с ранее выданной котировкой, и что «он‑чейн запись» соответствует тем же суммам.
• На стороне получателя: destination‑SAP и destination‑PSP подтверждают готовность принять платёж (через статусы pacs.002).

Смысл сегмента 2: до того как двигать «токенизированные деньги» в DLT‑слое, все участники должны согласиться с условиями, а офчейн‑слой должен убедиться, что ончейн‑расчёт будет ровно по тем параметрам, которые подтверждены сообщениями ISO 20022.

Сегмент 3: ончейн‑расчёт (on-chain settlement) на Scroll

• После подтверждений destination‑SAP запускает в Settlement Orchestrator валидацию (validate settlement).
• Дальше смарт‑контракт оркестрирует атомарную последовательность: списание токенизированного CeBM у source‑SAP → перевод FXP → свап через AMM → зачисление токенизированного CeBM у destination‑SAP.
• Атомарность означает: либо проходит всё, либо откатывается всё (в терминах EVM — revert), чтобы не осталось «наполовину исполненных» частей.

Смысл сегмента 3: это «ядро» PvP‑логики и безопасного FX‑расчёта — именно здесь Scroll выступает как площадка исполнения смарт‑контрактов.

Сегмент 4: последующие расчёты и уведомления (subsequent settlements and notifications)

• Destination‑SAP подтверждает в свою IPS, что средства на DLT‑слое получены.
• IPS на стороне получателя проводит внутренний расчёт между участниками, PSP зачисляет деньги получателю и отправляет подтверждение.
• IPS link передаёт подтверждение обратно на сторону источника.
• Только после того как получатель реально зачислен, на стороне источника финализируется расчёт между PSP и SAP, а PSP окончательно списывает деньги у отправителя и уведомляет его.

Смысл сегмента 4: DLT‑слой решает FX‑и‑расчёт по «межбанковской» ноге, но «последняя миля» до клиента остаётся в привычной платёжной инфраструктуре — с её комплаенсом, счетами и мгновенной расчётной логикой.

Пояснение простыми словами: где тут блокчейн, а где “обычные платежи”
Rialto не пытается «посадить всех пользователей на блокчейн». Пользовательская часть (счета людей, комплаенс, подтверждения, уведомления) остаётся в блоке 1 — в мире PSP/IPS и ISO 20022. Блокчейн‑часть нужна как нейтральный механизм для атомарного FX и расчёта в токенизированном CeBM между специализированными участниками (SAP/FXP), причём так, чтобы:

• нельзя было получить ситуацию «одна сторона заплатила, другая — нет»;
• курс и комиссии были прозрачны до подтверждения;
• а изменения в существующей инфраструктуре были минимальными.

Какие сценарии протестировали

1. Прямой обмен и перевод между юрисдикциями в двух валютах
   В отчёте основной пример — перевод между отправителем в одной юрисдикции и получателем в другой с прямым FX (в функциональном приложении это расписано как EUR → SGD).
2. Сценарий с “vehicle currency”
   Для случаев, когда прямой валютный коридор неликвиден или слишком дорогой, добавили маршрут через третью, более ликвидную валюту: обмен делается в два шага через «промежуточную» валюту, но всё равно внутри одной атомарной логики расчёта.

Какие проверки “на прочность” прогоняли
В отчёте отдельно разбираются отклонения от идеального сценария, чтобы архитектура оставалась устойчивой.

• Отказ по комплаенсу на стороне получателя
  Если PSP получателя отклоняет платёж из‑за санкций/AML/фрода, то расчёт не должен «частично случиться». В Rialto это достигается сочетанием двух решений: earmarking (блокировка средств заранее) и двухфазный DLT‑расчёт (пока все не согласились — токены не двигаются). В результате заблокированные средства высвобождаются, а инициализированный расчёт отменяется.
• Серьёзный сбой (disruption event)
  Рассматриваются ситуации, когда сбой произошёл до ончейн‑расчёта, сразу после него или после достижения финальности на стороне получателя. В зависимости от момента сбоя предлагаются разные механики: отмена/таймаут, «реверс» через обратную ончейн‑транзакцию, а также инструменты уточнения статуса (например, запрос статуса платежа).

Что это значит для Scroll и что это не значит
Значение факта «Scroll использован в Project Rialto» — в том, что:

• Scroll выступил средой, где реально развернули и исполняли EVM‑смарт‑контракты PoC для атомарного FX и расчёта в токенизированных CeBM.
• Выбор Scroll Sepolia в отчёте объясняется инженерными критериями (включая совместимость с Uniswap v3 и конкретными EVM‑изменениями).
• Это подтверждённый кейс «институционального PoC», но именно PoC: тестнет, симуляция, проверка архитектуры.

То, чего из отчёта делать нельзя:

• Нельзя честно сказать «центробанки внедрили Scroll в расчёты» или «Scroll стал официальной финансовой инфраструктурой». Отчёт описывает эксперимент и подчёркивает симуляционный характер DLT‑слоя.

Итоги
Project Rialto показал, как может выглядеть гибридная схема кроссбордер‑платежей: «обычные» мгновенные платежи и комплаенс остаются в традиционной инфраструктуре, а FX и расчёт в безопасном расчётном активе (tokenised CeBM) выполняются через атомарную смарт‑контрактную логику.

Scroll в этой истории — конкретная выбранная среда для DLT‑части PoC (Scroll Sepolia Testnet), где исполнялись смарт‑контракты оркестрации расчёта, FX‑логики и AMM‑обмена. Это делает упоминание Scroll в отчёте не “слухом”, а зафиксированным инженерным фактом.

Оригинал отчета: BIS