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.

Les relevés de capteurs ne font pas partie du cœur. Un hook de livraison peut enregistrer une température sur la chaîne ; les autres mesures (humidité, CO₂ et O₂, chocs, inclinaison, porte, position) restent hors chaîne dans la même sensorElementList, avec leur type CBV et leur unité de la Rec. 20. La correspondance décrit un modèle d'engagement sur ces mesures : par fenêtre de temps, le pire relevé de température avec une référence qui est une racine sur chaque relevé de la fenêtre et sur le message d'origine dont il provient, afin qu'un auditeur puisse vérifier un relevé par rapport à la chaîne. L'engagement prouve ce que l'enregistreur détenait à ce bloc, pas que l'appareil a bien mesuré. Les points de lecture et les lieux d'activité sont des identifiants de site, jamais des coordonnées.

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.

Le lieu de production des marchandises est donné sous forme de codes : le pays (ISO 3166-1), la subdivision de premier niveau (ISO 3166-2, par exemple BR-MG) et l'UN/LOCODE d'une localité uniquement pour un site d'activité tel qu'un entrepôt ou un port, jamais pour une exploitation agricole. Les relevés de capteurs vont dans le sensorData du MoveEvent de la livraison ; un passeport en porte au plus un résumé. À partir du schéma de métadonnées 1.3.0 (ADR-024, Proposé), origin.region est toujours un tel code.

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. La révision 1.2 ajoute le type de lieu ref:site (l'originRef que portent ses lots, jamais une localisation) et précise que le gaz déclaré est mesuré avec les réglages remplis (gas.setup facultatif). La révision 1.3 documente les champs que son premier consommateur écrit déjà (actions, erreurs propres du contrat, mesures, donnée par livraison et forme complète des événements), tous facultatifs. La révision 1.4 ajoute ce dont une plateforme a besoin pour construire les formulaires des modules complémentaires : plus de types de valeur, ce qui atteint le registre (jamais de données personnelles), présentation et contrôles par champ, vues en lecture seule, et la correspondance d'un enregistrement avec EPCIS et un passeport UNTP (une caractéristique déclarée par son organisation, jamais une allégation). La révision 1.5 sale chaque empreinte : un descripteur qui déclare fingerprint: { "scheme": "salted-jcs/1" } enregistre le hachage de chaque valeur avec son propre sel de 32 octets, de sorte que des textes courts, des nombres ou des contours de parcelles ne peuvent pas être retrouvés en essayant des candidats. La révision 1.6 ajoute des mesures qui ne sont pas des totaux (avg, min, max d'un champ numérique, jamais additionnées entre groupes ni entre entreprises) et deux façons de les regrouper, par la partie qui a créé le lot (party) et par son site (site) ; le modèle de module complémentaire d'humidité de la version de référence 2.0.0-alpha.10 l'utilise pour l'humidité moyenne à la réception. La révision 1.7 permet au visibleWhen d'un champ de prendre l'arbre de conditions du descripteur de vocabulaire (all, any, not ; au plus 3 niveaux et 12 feuilles) sur les autres champs du formulaire ; la condition unique de la révision 1.4 reste valide, mais dépréciée.

Les organisations peuvent publier leurs propres types de travaux aux champs, types de procédé et listes d'étapes sous forme de définitions de vocabulaire arex.vocab/1. Chacune correspond à l'une des 26 classes d'étape de référence (par exemple drying ou fermenting) et à une étape métier GS1 CBV. Leurs événements EPCIS portent trois couches : le bizStep CBV que tout système EPCIS lit, la classe de référence (arex:stageClass) qui permet à deux organisations aux noms différents de comparer leurs enregistrements, et le type, les noms et les valeurs publiées de l'organisation elle-même. Dans un passeport UNTP, les valeurs sont des caractéristiques, jamais des allégations. Les métadonnées d'un lot transformé peuvent nommer le type de procédé et l'exécution à son origine dans un objet process, prévu pour le schéma de métadonnées 1.4.0. La révision 1.1 ajoute une mise en page facultative du formulaire (sections, largeurs, conditions) qui ne fait que restreindre ce que les champs acceptent. La révision 1.2 permet aux conditions d'utiliser not, d'aller jusqu'à 3 niveaux et 12 feuilles et de lire le contexte de l'enregistrement en codes (la culture en code OEPP, les jours depuis la plantation, le type de site, le pays, la position SH du produit, la dernière étape) ; un contexte inconnu se lit comme vide. La révision 1.3 ajoute l'ordre d'une liste d'étapes (order) : strict (par défaut ; une étape antérieure obligatoire doit être enregistrée d'abord) ou flexible (n'importe quel ordre, les manques laissés aux rapports). La révision 1.4 ajoute les méthodes de traitement du café (washed, natural, honey, pulped_natural, wet_hulled, anaerobic et d'autres) qu'un type de procédé donne à ses sorties et que portent les métadonnées process d'un lot : une déclaration de l'organisation, pas une certification. La révision 1.5 ajoute des sous-classes des classes larges (separating, conditioning, sorting_grading, heat_treating) tirées d'une liste fermée, si bien qu'un lecteur n'apparie l'étape d'une autre organisation d'une classe large que par sa sous-classe ou par une correspondance explicite par expéditeur. La révision 1.6 ajoute to_processor, une sous-classe de transporting : des marchandises envoyées à un transformateur qui les travaille pour leur propriétaire (travail à façon), si bien que la garde change mais pas la propriété. Les étiquettes du registre, les références d'étape et les sujets de site sont salés, si bien qu'aucun déroulé de procédé ni aucune chronologie d'exploitation ne se lit dans le registre, et l'argent n'y est jamais écrit en clair. Une étape d'emballage ou de chargement enregistrée avec une unité logistique (un SSCC, un numéro de conteneur) correspond à un AggregationEvent EPCIS. Dans la version de référence 2.0.0-alpha.9, CompanyFactsHook écrit ces enregistrements dans le registre et RequireStageHook refuse les livraisons de lots auxquels manquent les étapes exigées ; aucun des deux modules n'est obligatoire. Le tout est informatif et Proposé.

Déploiement inter-chaînes

A-REX Core est un standard EVM (ADR-026, Proposé) : un jeton conforme fonctionne sur tout réseau EVM de niveau paris ou ultérieur, et le standard ne tient aucune liste de réseaux ; ceux qu'une organisation peut utiliser sont fixés par son profil de politique. Les réseaux sont désignés par des identifiants CAIP-2, comme eip155:8453 ou hedera:mainnet. 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. À partir du schéma 1.4.0 (Proposé), une entrée peut aussi indiquer le réseau CAIP-2 (network), et un lot enregistré sur un réseau qui n'est pas EVM est désigné par son réseau et son actif CAIP-19.

Des enregistrements que chacun peut vérifier, sur n'importe quel réseau

Les preuves qui entourent un jeton ne dépendent pas du réseau du jeton. Une fois par période, un émetteur peut combiner les empreintes de ses enregistrements (son journal d'audit, ses rapports, ses documents) en une seule racine de Merkle et publier ces 32 octets sur plusieurs réseaux indépendants : son propre réseau EVM, Bitcoin via OpenTimestamps et le Hedera Consensus Service. Chaque enregistrement reçoit une courte preuve arex.anchor-proof/1. Quiconque détient l'enregistrement et sa preuve peut vérifier, sans aucun service A-REX, que l'enregistrement existait sans modification au plus tard au moment où chaque réseau a reçu la racine ; un contrat EVM peut vérifier la même preuve avec MerkleProof d'OpenZeppelin. Seules des empreintes sont publiées, jamais de données personnelles. Le format est informatif et Proposé (ADR-026). Les réseaux sur lesquels un émetteur ancre relèvent de sa politique, fixée par son profil de juridiction ou d'organisation, et une preuve est valide avec un nombre quelconque de reçus. Un reçu Hedera indique l'identifiant de sa transaction à l'envoi de la racine, puis reçoit le numéro de séquence et l'heure de consensus du message dès qu'un nœud miroir public le confirme.

D'où viennent les chiffres d'un rapport signé

Un rapport calculé à partir des enregistrements d'un émetteur, comme « 1 200 kg livrés à un acheteur en octobre » ou une liste d'enregistrements, peut porter ses sources : une ligne par enregistrement lu, avec l'endroit où le registre détient cet enregistrement et les valeurs que le rapport a utilisées. Chaque ligne est une source arex.report-sources/1 ; sa feuille est keccak256(0x03 ‖ JCS(source)), et les feuilles triées sont appariées jusqu'à une seule racine des sources. La racine et le SHA-256 du fichier des sources (<report>.sources.csv) sont scellés avec le rapport, dans son manifeste signé ou sous la signature d'un PDF, si bien qu'aucune ligne ne peut ensuite être ajoutée, retirée ou modifiée. Le rapport indique combien de ses enregistrements se vérifient sur le registre, combien par une empreinte sur le registre (une ancre quotidienne ou une fenêtre de relevés) et combien ne sont que des enregistrements de l'émetteur, couverts par son sceau. Une source ne contient jamais de valeur personnelle en clair. Un lecteur vérifie le tout sans aucun service A-REX : verify-sources.mjs, un vérificateur autonome (Node.js 20, rien à installer) que toute implémentation peut fournir, recalcule chaque feuille et la racine, les compare avec le rapport, puis lit chaque enregistrement du registre depuis n'importe quel nœud de son réseau. Un rapport à plusieurs cartes garde un seul fichier des sources et une seule racine ; chaque ligne nomme sa carte dans le membre facultatif section (révision 1.1), de sorte que les chiffres de chaque carte s'additionnent séparément.

node verify-sources.mjs report.csv.sources.csv --manifest report.csv.manifest.json --rpc https://<a node of the network>

Le format est informatif et Proposé (révision 1.1 des sources de rapport). Le document du standard, partagé en accès anticipé, donne les colonnes du fichier, chaque vérification et un vecteur d'exemple ; le schéma décrit une source.

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é