Нативный актив — основной актив сети, использующий канонический реестр балансов EVM. Это важно для эксплуатации: банковское представление не является отдельной копией балансов токенов, а баланс для учёта актива отличается от технического газа, необходимого для выполнения операций в сети.
Учреждение выбирает назначение актива и собственные политики выпуска, резервов и обслуживания клиентов. Платформа предоставляет конфигурацию и управляемые средства контроля, но не резервы и не обещание обеспечения, погашения, хранения или определённого финансового режима. Прежде чем проектировать процессы вокруг актива, явно определите эти границы.
Единый канонический реестр балансов
Балансы нативного актива представлены в каноническом реестре EVM, который является источником сетевого состояния балансов. Банковский интерфейс отображает административные и ориентированные на политику представления этого состояния; он не ведёт второй независимый балансный реестр, который мог бы незаметно разойтись с авторитетной записью сети.
Этот реестр следует отличать от банковских записей и основных банковских систем, работающих вне блокчейна. В них могут храниться идентификация клиентов, связи со счетами, условия продуктов и специфичный для учреждения бухгалтерский учёт, тогда как сеть фиксирует применимые адреса, балансы активов и транзакции. Сопоставление и сверка записей относятся к интеграции и должны быть спроектированы и проверены.
Изменение баланса отражается в каноническом состоянии сети
- Уполномоченное действиеРазрешённый выпуск, сжигание или перевод выполняется в соответствии с настроенными полномочиями.
- Исполнение EVMСеть обрабатывает транзакцию по действующим правилам.
- Канонический балансРеестр сети фиксирует результирующее состояние нативного актива.
- Проверка учреждениемОдобренные интерфейсы и записи помогают выполнять сверку и надзор.
Выпуск, сжигание и полномочия
Уполномоченные операторы могут выполнять поддерживаемые операции выпуска и сжигания в пределах настроенных ролей и процесса управления. До запуска определите назначение каждой операции, роль, которая может её предложить, необходимые одобрения, порядок фиксации исполнения и ответственного за проверку итогового предложения и балансов. Техническая возможность не заменяет политику казначейства или продукта.
Проверьте процедуры выпуска и сжигания на одобренных непроизводственных сценариях, включая отклонённые или не завершившие одобрение случаи и последующую сверку. Документируйте порядок информирования команд приложений и эксплуатации об изменениях. Фактические разрешения и пороги одобрения зависят от развёрнутой конфигурации; нельзя предполагать наличие универсального администратора или неограниченных полномочий одного сотрудника.
Резервы, газ и учёт комиссий
Учреждение владеет любыми резервами своей программы и управляет ими. FusionPointAI предоставляет технологии и согласованные услуги, а не резервные активы. Выпуск нативного актива сам по себе не устанавливает обеспечение, права на погашение, хранение, требования к внешним средствам или конкретную правовую квалификацию: эти условия определяет учреждение в рамках собственных процессов.
Учёт нативного актива и газ транзакций относятся к сети, но представляют разные операционные задачи. Газ обеспечивает исполнение на уровне протокола, тогда как политика комиссий для клиента может отдельно предусматривать оплату или спонсирование подходящей операции. Финансовым и операционным командам следует вести раздельную сверку перемещений активов, финансирования газа, клиентских комиссий и стоимости услуг.
Разделяйте программу актива и технический газ
- Программа нативного активаОпределённые учреждением выпуск, политика предложения и ответственность за резервы.
- Канонический баланс EVMСостояние сети фиксирует балансы и применимые перемещения актива.
- Технический газИсполнение в сети требует расчёта газа на уровне протокола.
- Политика комиссии для клиентаОтдельная политика может предусматривать оплату или спонсирование подходящей операции.
Решения по конфигурации и запуску
При настройке определите название и символ актива, предполагаемое использование, административные роли, средства контроля предложения, модель управления, допущения по комиссиям и интерфейсы. Подтвердите, какие данные должны находиться в сети, а какие остаются в системах учреждения. При необходимости внешних интеграций оцените сопоставление данных, аутентификацию, ответственность и тестовый доступ, а не полагайтесь на предполагаемый готовый коннектор.
Идентификатор сети требует особого внимания: Chain ID нельзя изменить после создания. Другие поддерживаемые параметры подчиняются управлению, а некоторые изменения могут потребовать согласованного обновления программного обеспечения. До промышленного запуска проверьте предположения приложений, разрешения, пути выпуска и сжигания, отображение баланса и сверку в выбранной среде. Смежные решения по политикам рассмотрены в главах об ограничениях и Paymaster.