ERPC

Инфраструктура для стейблкоинов

Создавайте сервисы со стейблкоинами в Solana.

Заранее определите уровень подключения, зоны ответственности и источники, которые команда сможет проверить.

Проектируйте сервисы со стейблкоинами в Solana с чёткой границей RPC и проверяемыми эксплуатационными данными.

Обсудить архитектуруПрочитать статью о x402

Регуляторный контекст

Учитывайте правила каждого обслуживаемого рынка.

Требования к выпуску, распространению, хранению и переводу стейблкоинов зависят от продукта и юрисдикции; проверяйте их для своей модели.

Проверенные исходные материалы:

Соединённые Штаты

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

The White HouseОфициальный источник США

Примеры рынка

JPYC

JPYC — публичный пример инициативы с привязкой к иене в Японии; самостоятельно проверьте эмитента, текущую структуру продукта и применимость к своей задаче.

JPYC Inc.Официальные материалы JPYC

JPYSC

JPYSC показывает ещё один публичный подход на японском рынке; отдельно подтвердите его актуальное устройство и соответствие вашей модели.

SBI GroupОфициальные материалы JPYSC

Эта страница даёт технический контекст, а не юридическую, налоговую или регуляторную консультацию.

Роль RPC

Уровень подключения, а не сторона, создающая подпись.

Приложение может через ERPC получать данные Solana, передавать уже подписанную транзакцию и запрашивать её результат. Ключи и подпись остаются под контролем клиента; ERPC пересылает запрос в инфраструктуру Solana RPC и возвращает ответ сети.

01Получение состояния Solana
Приложение запрашивает через RPC необходимые счета, блоки и иное состояние сети.
02Отправка уже подписанной транзакции
В RPC передаётся транзакция, которую до этого подписал кошелёк или подписант клиента.
03Проверка результата транзакции
Клиент запрашивает результат сети и применяет собственную политику подтверждения.

ERPC обеспечивает транспорт запроса и ответа RPC, но не получает закрытые ключи, не создаёт подпись и не принимает за клиента решение о сверке.

Путь транзакции

Пять ролей с явными границами.

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

  1. 01

    Приложение

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

  2. 02

    Подписант со стороны клиента

    Кошелёк или подписант клиента проверяет сформированную транзакцию и создаёт подпись под контролем клиента.

  3. 03

    Уровень подключения ERPC

    ERPC принимает уже подписанный запрос, передаёт его в Solana RPC и возвращает полученный сетевой ответ.

  4. 04

    Обработка в Solana

    Сеть Solana обрабатывает транзакцию в соответствии со своими текущими условиями и правилами протокола.

  5. 05

    Подтверждение и сверка на стороне клиента

    Система клиента сама определяет, как отслеживать подтверждение и сверять собственное бизнес-состояние.

Такое разделение позволяет команде сопоставить технический поток со своей моделью безопасности, учёта и контроля.

Границы ответственности

Юридическая роль каждой стороны зависит от конкретной схемы взаимодействия и применимой юрисдикции.

Подписант со стороны клиента
Клиент отвечает за логику приложения, управление подписантом и создание подписи.
Уровень подключения ERPC
Зона ERPC ограничена передачей RPC-запроса и возвратом ответа инфраструктуры.
Обработка в Solana
Результат исполнения формируется сетью Solana по её правилам.
Подтверждение и сверка на стороне клиента
Итоговое отражение операции в учёте и рабочих процессах выполняет система клиента.

Рабочие сценарии

Один уровень подключения для разных платёжных потоков.

Архитектуру RPC можно встроить в пользовательские платежи, расчёты между компаниями, машинные API-платежи и внутренний учёт, сохраняя ответственность каждого контура.

01

Оплата заказа

В кассовом сценарии приложение готовит платёж, клиент подписывает транзакцию, а система продавца отдельно отслеживает результат и состояние заказа.

02

B2B-расчёты, выплаты и казначейство

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

03

API-платежи x402

Клиенты и серверы могут обмениваться требованиями к оплате x402 и PaymentPayload, соответствующим выбранной схеме и сети. Этот платёжный поток HTTP отделён от общего потока приложения; в схеме exact для Solana нагрузка может содержать сериализованную, частично подписанную платёжную транзакцию для проверки и расчёта.

04

Сверка и системная интеграция

Интеграционный контур связывает сетевые ответы с заказами, бухгалтерскими записями и журналами операций по правилам системы клиента.

x402 и платежи через API

От HTTP-требования к проверяемому платёжному ответу.

x402 описывает обмен требованиями и доказательством оплаты на уровне API; конкретный способ расчёта и обработка ресурса зависят от реализации.

Содержимое x402 PaymentPayload зависит от выбранных схемы и сети. В схеме exact для Solana оно может включать сериализованную, частично подписанную платёжную транзакцию Solana для проверки и расчёта.

  1. 01

    Запрос ресурса

    Клиент или агент отправляет HTTP-запрос к ресурсу с платным доступом.

  2. 02

    Платёжные требования 402

    Сервер отвечает кодом 402 и сообщает поддерживаемый способ, сумму и иные условия платежа.

  3. 03

    Подписанная платёжная нагрузка API

    Клиент формирует и подписывает платёжную нагрузку API в соответствии с полученными требованиями x402.

  4. 04

    Проверка и расчёт

    Сторона проверки валидирует нагрузку и выполняет либо наблюдает предусмотренный реализацией расчёт.

  5. 05

    Ответ с ресурсом и результатом расчёта

    После принятия платежа сервер возвращает HTTP-ресурс вместе с данными, по которым клиент может связать ответ с расчётом.

Официальная документация x402 · Датированное подтверждение реализации ERPC

Корпоративная модель ответственности

Разделите клиентский контур, выбранный объём ERPC и сеть.

До запуска зафиксируйте, кто управляет ключами и бизнес-логикой, какие сервисы предоставляет ERPC и какие операции выполняет Solana.

Клиент или партнёр

Система клиента сама определяет, как отслеживать подтверждение и сверять собственное бизнес-состояние.

  • Оплата заказа
  • Сверка и системная интеграция

Выбранная область ответственности ERPC

ERPC не хранит закрытые ключи клиента и не подписывает транзакции клиентского приложения.

  • Подключение к Solana RPC
  • Эксплуатация выделенного VPS
  • Инфраструктура на физических серверах

Сеть Solana

Solana принимает и обрабатывает сетевые транзакции по действующим правилам протокола и состоянию сети.

  • Обработка в Solana

Юридическая роль каждой стороны зависит от конкретной схемы взаимодействия и применимой юрисдикции.

Материалы для проверки реализации

Проверяйте каждый слой по собственному источнику.

Команда может отдельно изучить RPC-сервис, технические руководства и варианты выделенной вычислительной инфраструктуры.

01

Подключение к Solana RPC

Описание сервиса RPC показывает доступную границу подключения и способы обращения приложения к Solana.

Открыть сведения об RPC
02

Техническая документация

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

Перейти к документации
03

Эксплуатация выделенного VPS

Выделенный VPS даёт команде отдельную среду для собственных приложений, наблюдения и интеграционных процессов.

Изучить варианты VPS
04

Инфраструктура на физических серверах

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

Изучить физические серверы

Читать руководство по транзакциям Solana

Читать о структурах данных Solana RPC

Спланируйте границы до запуска

Сопоставьте платёжный поток с ответственностью каждого слоя.

Обсудите с ERPC соединение RPC и инфраструктурный объём, который подходит вашей архитектуре.

Обсудить архитектуруИзучить x402