Interopérabilité

Avec l'écosystème Ethereum

Un jeton A-REX Core est un jeton ERC-1155. Les portefeuilles, les explorateurs, les places de marché et les indexeurs qui comprennent ERC-1155 fonctionnent sans changement : soldes, transferts groupés, uri(id), approbations, vérifications de réception des transferts sécurisés. A-REX ajoute des événements et des vues ; il ne retire rien.

Un jeton A-REX Core est un multi-jeton ERC-7943. Les moteurs de conformité et les plateformes de garde qui ciblent ERC-7943 (l'Automated Compliance Engine de Chainlink a démontré sa compatibilité ; les plateformes d'émission de la coalition ERC-7943 l'adoptent) reconnaissent canTransfer, forcedTransfer, setFrozenTokens, canSend et canReceive sans adaptation.

Avec les standards de données de traçabilité

GS1 EPCIS 2.0 / CBV

Le standard publie une correspondance informative, événement par événement :

Le schéma de métadonnées utilise délibérément les noms d'EPCIS/CBV afin qu'un outil d'export fasse correspondre des champs, et non des concepts.

UN Transparency Protocol (UNTP 0.7.0)

Une correspondance informative traduit un lot, ses événements et ses attestations en justificatifs UNTP 0.7.0, avec les mêmes identifiants que la correspondance EPCIS afin que les deux puissent être reliées :

Les justificatifs suivent le W3C Verifiable Credentials Data Model 2.0 et sont signés avec VC-JOSE-COSE sous le did:web de l'émetteur ; la révocation utilise une Bitstring Status List. Un justificatif signé peut aussi être ancré à son lot sous forme d'attestation dont la référence est le hash du justificatif ; l'ancrage prouve l'engagement, la signature prouve le contenu. Un justificatif ne porte que ce que contiennent le jeton ou ses métadonnées, et les valeurs qui exigent une méthode (une empreinte, un score de risque) n'apparaissent que lorsqu'une partie nommée les a déclarées. La correspondance indique ce qu'elle ne couvre pas, à commencer par le passeport numérique de produit de l'UE : l'ESPR ne s'applique ni aux denrées alimentaires, ni aux aliments pour animaux, ni aux plantes et animaux vivants, et A-REX n'avance aucune affirmation de passeport pour ceux-ci.

Empreintes carbone déclarées (PACT 3.0.3)

L'ADR-018 (Proposé) permet à un lot de porter une empreinte carbone de produit calculée par un tiers, sous extensions.pact_pcf du document de métadonnées. Le fragment suit champ par champ les WBCSD PACT Technical Specifications 3.0.3 : qui l'a déclarée, l'unité déclarée et la période de référence, l'empreinte avec et sans absorption biogénique, et un statut de vérification obligatoire qui nomme le vérificateur lorsque l'empreinte est vérifiée. Elle est recopiée, jamais calculée, additionnée ni transmise aux lots issus du lot, et ce n'est pas un crédit carbone (ADR-014). La correspondance est une œuvre dérivée distincte de PACT et ne recopie aucun fichier PACT.

Codes de denrée et d'unité

Un code de denrée est keccak256("<SCHEME>:<CODE>") pour n'importe quelle nomenclature : le Système harmonisé (HS), les nomenclatures tarifaires nationales (NCM dans le Mercosur, CN et TARIC dans l'UE, HTS aux États-Unis, entre autres), FAO, CPC, GTIN, ou celle de l'émetteur. Depuis le schéma de métadonnées 1.1.0, la nomenclature est également ouverte dans le document, de sorte que les métadonnées peuvent refléter le code on-chain. Les unités sont des codes de la Recommandation 20 de l'UN/CEFACT (KGM, TNE, LTR), la liste que l'EDI, EPCIS et les douanes utilisent déjà.

FSMA 204

Les éléments de données clés sont des champs de métadonnées (traceabilityLotCode, GLN, dates, quantités) et des événements ; le CTE de transformation est BatchTransformed ; la demande de registres sous 24 heures est une requête d'indexeur. Voir le chapitre réglementaire pour la correspondance complète.

Codex, ISO 22000, GLOBALG.A.P., schémas biologiques

Tous sont des thèmes d'attestation. Le standard ne les énumère pas : keccak256("GLOBALGAP:IFA"), keccak256("AREX:CERT:ORGANIC_EU"), keccak256("CODEX:MRL") sont des conventions que l'émetteur publie avec son schéma de métadonnées.

Avec les registres de documents juridiques

Les jetons A-REX référencent les instruments juridiques ; ils ne les remplacent pas tant qu'une juridiction ne reconnaît pas le jeton lui-même :

Avec les systèmes d'identité

Le jeton ne pose que canSend(account) / canReceive(account). Derrière cette question peuvent se trouver :

• une liste d'autorisation/de blocage tenue par l'émetteur (EligibilityHook) ;
• un registre d'identité ONCHAINID avec des thèmes d'attestation (le modèle ERC-3643) ;
• des attestations Ethereum Attestation Service portant sur le compte ;
• des justificatifs vérifiables vérifiés off-chain et reflétés on-chain par un relayeur ;
• un dispositif national d'e-ID (portefeuille eIDAS 2.0 dans l'UE) via un vérificateur de justificatifs.

Aucun d'entre eux ne fait partie du standard, c'est pourquoi un émetteur au Brésil et un émetteur en Allemagne peuvent utiliser des fournisseurs différents et rester interopérables.

Avec les moteurs de règles et les plateformes

Une règle ou un module complémentaire peut publier un descripteur arex.module/1 : un document JSON qui contient ses paramètres, ses réglages, les champs de lot requis, les types de certificats, ses événements, ses codes de rejet et la manière dont son état est repris par une nouvelle version. Une plateforme, un portefeuille, un indexeur ou un auditeur qui lit les descripteurs intègre une nouvelle règle sans code sur mesure. Le format est informatif et au statut Proposé ; il devient un format recommandé dès qu'un second implémenteur indépendant le consomme. La révision 1.1 ajoute une liste facultative et informative ops des opérations qu'une règle gouverne ; absente, elles sont inconnues, et elle ne sert jamais à appliquer un contrôle.

Déploiement inter-chaînes

Le standard est indépendant de la chaîne. Modèles pratiques :

• Une seule chaîne d'origine par émetteur (recommandé) : la filiation et la mise en application restent cohérentes ; les autres chaînes détiennent des représentations encapsulées via des adaptateurs de type ERC-7802 ou CCIP.
• Chaîne EVM à accès restreint pour les émetteurs dont l'autorité de protection des données ou l'institution d'ancrage l'exige ; l'EDPB privilégie expressément les conceptions à accès restreint. Même bytecode.
• Miroirs pour la liquidité : un identifiant de lot sur la chaîne d'origine, un wrapper ERC-20 ailleurs ; le wrapper doit honorer canTransfer du jeton d'origine ou se restreindre aux détenteurs éligibles.

La filiation ne traverse jamais les chaînes ; les références, si. Entre jetons d'une même chaîne ou de chaînes différentes, un lot fabriqué à partir du lot d'un autre jeton le désigne dans la liste upstream de ses métadonnées (schéma 1.2.0) par identifiant de chaîne, contrat et identifiant de jeton. Ces références sont des affirmations de l'émetteur, à vérifier auprès du jeton en amont.

Avec les systèmes de gestion agricole et les ERP

Les points d'intégration sont les mêmes que pour tout jeton ERC-1155, auxquels s'ajoutent les vues de lot :

• Chemin d'écriture : un service d'origination détient ISSUER_ROLE et appelle createBatch à partir d'événements de l'ERP (ticket de pont-bascule, émission de récépissé) ; setBatchStatus/setBatchMetadata à partir d'événements d'entrepôt ; transform à partir d'ordres de traitement.
• Chemin de lecture : un indexeur matérialise les lots, la filiation, les attestations et les événements de mise en application dans les tables de traçabilité de l'ERP ; export EPCIS pour les partenaires et les régulateurs.
• Vérification préalable : transferCheck permet à un ERP d'expliquer un refus à un opérateur avant de soumettre une transaction.
• Identifiants : les clés GS1 dans les métadonnées font le pont avec les référentiels EDI et EPCIS existants ; les unités UN/CEFACT sont déjà présentes dans les ERP.

Matrice de compatibilité