Интероперабельность

С экосистемой Ethereum

Токен A-REX Core является токеном ERC-1155. Кошельки, обозреватели блоков, торговые площадки и индексаторы, понимающие ERC-1155, работают без изменений: балансы, пакетные переводы, uri(id), одобрения, проверки получателя при безопасных переводах. A-REX добавляет события и view-функции; ничего не удаляя.

Токен A-REX Core является мультитокеном ERC-7943. Движки комплаенса и платформы хранения активов, ориентированные на ERC-7943 (Chainlink Automated Compliance Engine продемонстрировал совместимость; платформы выпуска из коалиции ERC-7943 внедряют его), распознают canTransfer, forcedTransfer, setFrozenTokens, canSend и canReceive без адаптации.

Со стандартами данных прослеживаемости

GS1 EPCIS 2.0 / CBV

Стандарт публикует информативное сопоставление, событие за событием:

Схема метаданных намеренно использует имена EPCIS/CBV, чтобы экспортёру приходилось сопоставлять поля, а не понятия.

UN Transparency Protocol (UNTP 0.7.0)

Информативное сопоставление превращает партию, её события и аттестации в учётные данные UNTP 0.7.0 с теми же идентификаторами, что и в сопоставлении с EPCIS, чтобы их можно было связать:

Учётные данные соответствуют модели данных W3C Verifiable Credentials 2.0 и подписываются по VC-JOSE-COSE под did:web эмитента; отзыв использует Bitstring Status List. Подписанные учётные данные можно также привязать к партии как аттестацию, ссылкой в которой служит хеш учётных данных: привязка доказывает коммитмент, подпись доказывает содержимое. Учётные данные содержат только то, что хранят токен или его метаданные, а значения, для которых нужна методика (углеродный след, оценка риска), появляются лишь тогда, когда их задекларировала названная сторона. Сопоставление прямо указывает, чего оно не охватывает, и прежде всего это цифровой паспорт продукта ЕС: ESPR не применяется к продуктам питания, кормам, живым растениям и животным, и A-REX не делает в отношении них заявлений о паспорте.

Задекларированный углеродный след (PACT 3.0.3)

ADR-018 (Предложено) позволяет партии нести углеродный след продукта, рассчитанный третьей стороной, в extensions.pact_pcf документа метаданных. Фрагмент поле за полем следует WBCSD PACT Technical Specifications 3.0.3: кто задекларировал след, задекларированная единица и отчётный период, след с учётом и без учёта биогенного поглощения, а также обязательный статус верификации, в котором указан верификатор, если след верифицирован. След копируется, но никогда не рассчитывается, не суммируется и не передаётся партиям, изготовленным из лота, и он не является углеродным кредитом (ADR-014). Сопоставление — это отдельная производная работа на основе PACT, и оно не копирует ни одного файла PACT.

Коды товаров и единиц измерения

Код товара — это keccak256("<SCHEME>:<CODE>") для любой схемы: Гармонизированной системы (HS), национальных тарифных номенклатур (NCM в Меркосуре, CN и TARIC в ЕС, HTS в США и других), FAO, CPC, GTIN или собственной схемы эмитента. Начиная со схемы метаданных 1.1.0 схема в документе тоже открыта, поэтому метаданные могут повторять ончейн-код. Единицы измерения — это коды Рекомендации UN/CEFACT 20 (KGM, TNE, LTR), то есть перечень, который уже используют EDI, EPCIS и таможня.

FSMA 204

Ключевые элементы данных — это поля метаданных (traceabilityLotCode, GLN, даты, количества) и события; CTE «преобразование» — это BatchTransformed; запрос записей в течение 24 часов — это запрос к индексатору. Полное соответствие приведено в регуляторной главе.

Codex, ISO 22000, GLOBALG.A.P., схемы органической продукции

Все они — темы аттестаций. Стандарт их не перечисляет: keccak256("GLOBALGAP:IFA"), keccak256("AREX:CERT:ORGANIC_EU"), keccak256("CODEX:MRL") — соглашения, которые эмитент публикует вместе со своей схемой метаданных.

С реестрами юридических документов

Токены A-REX ссылаются на правовые инструменты; они не заменяют их, пока юрисдикция не признает сам токен:

С системами идентичности

Токен задаёт только вопросы canSend(account) / canReceive(account). За этим вопросом может стоять:

• список разрешённых и заблокированных адресов, который ведёт эмитент (EligibilityHook);
• реестр идентичности ONCHAINID с темами утверждений (модель ERC-3643);
• аттестации Ethereum Attestation Service в отношении аккаунта;
• верифицируемые учётные данные, проверяемые офчейн и отражаемые ончейн ретранслятором;
• национальная схема e-ID (кошелёк eIDAS 2.0 в ЕС) через верификатор учётных данных.

Ничто из этого не входит в стандарт, поэтому эмитент в Бразилии и эмитент в Германии могут использовать разных поставщиков и оставаться интероперабельными.

С движками правил и платформами

Правило или дополнение может опубликовать дескриптор arex.module/1: JSON-документ с его параметрами, настройками, обязательными полями партии, типами сертификатов, событиями, кодами отказа и описанием того, как его состояние переносится в новую версию. Платформа, кошелёк, индексатор или аудитор, читающие дескрипторы, интегрируют новое правило без специального кода. Формат информативен и имеет статус «Предложено»; он станет рекомендуемым, когда его начнёт использовать второй независимый разработчик реализации. Редакция 1.1 добавляет необязательный информационный список ops с операциями, которыми управляет правило; его отсутствие означает, что они неизвестны, и он никогда не используется для принуждения к правилам.

Кроссчейн-развёртывание

Стандарт не привязан к конкретной сети. Практические шаблоны:

• Одна домашняя сеть на эмитента (рекомендуется): родословная и принудительное исполнение остаются согласованными; другие сети держат обёрнутые представления через адаптеры в стиле ERC-7802 или CCIP.
• Сеть EVM с разрешительным доступом для эмитентов, которым это требуется по указанию органа по защите данных или якорного учреждения; EDPB прямо отдаёт предпочтение архитектурам с разрешительным доступом. Тот же байткод.
• Зеркала для ликвидности: идентификатор партии в домашней сети, обёртка ERC-20 в другой; обёртка должна соблюдать canTransfer домашнего токена либо ограничиваться допущенными держателями.

Родословная никогда не пересекает границы сетей; ссылки — пересекают. Между токенами в одной сети или в разных сетях партия, изготовленная из партии другого токена, указывает её в списке upstream своих метаданных (схема 1.2.0) по идентификатору сети, контракту и идентификатору токена. Эти ссылки — утверждения эмитента, которые следует сверять с исходным токеном.

С системами управления фермами и ERP

Точки интеграции те же, что и для любого токена ERC-1155, плюс view-функции партий:

• Путь записи: сервис первичного оформления держит ISSUER_ROLE и вызывает createBatch по событиям ERP (весовая квитанция, выдача расписки); setBatchStatus/setBatchMetadata — по складским событиям; transform — по заказам на переработку.
• Путь чтения: индексатор материализует партии, родословную, аттестации и события принудительного исполнения в таблицах прослеживаемости ERP; экспорт EPCIS для партнёров и регуляторов.
• Предварительная проверка: transferCheck позволяет ERP объяснить оператору отказ до отправки транзакции.
• Идентификаторы: ключи GS1 в метаданных связывают с существующими репозиториями EDI и EPCIS; единицы UN/CEFACT уже есть в ERP.

Матрица совместимости