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

С экосистемой 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, чтобы экспортёру приходилось сопоставлять поля, а не понятия.

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 в ЕС) через верификатор учётных данных.

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

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

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

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

Родословная никогда не пересекает границы сетей; ссылки — пересекают.

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

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

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

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