Livre blanc · 12

Interopérabilité

Comment un jeton A-REX s'insère dans l'existant : standards de jetons Ethereum, moteurs de conformité, standards de données de traçabilité, registres de documents juridiques, systèmes d'identité, infrastructure inter-chaînes et systèmes agricoles existants.

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.

Standard	Relation
ERC-1155	base ; A-REX Core en est une extension
ERC-165	découverte d'interfaces ; cinq identifiants publiés
ERC-7943	requis ; surface de mise en application adoptée telle quelle
ERC-3643	compatible par adaptation : un module de conformité ERC-3643 peut être encapsulé en `IARexHook` (un appel à `moduleCheck`) ; un hook A-REX peut être exposé à un jeton ERC-3643. Les registres d'identité utilisés avec ERC-3643 (ONCHAINID) se branchent comme hook d'éligibilité.
Attestations ERC-735 / ONCHAINID	les thèmes d'attestation correspondent directement aux thèmes d'`IARexAttest` (`bytes32(uint256 topic)`)
Ethereum Attestation Service	les UID de schéma sont des thèmes `IARexAttest` valides ; un registre d'attestations adossé à EAS peut implémenter `IARexAttest` en déléguant `isAttested`
ERC-7201	disposition du stockage de l'implémentation de référence
ERC-7573, modèles de blocage/séquestre	la livraison contre paiement et le séquestre sont des hooks ou des contrats compagnons ; le standard ne prescrit pas le règlement
ERC-7802 / Chainlink CCIP	des adaptateurs inter-chaînes d'émission/destruction peuvent encapsuler le jeton ; la filiation reste sur la chaîne d'origine, les références voyagent

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

GS1 EPCIS 2.0 / CBV

On-chain	EPCIS 2.0
`BatchCreated`	`ObjectEvent` ADD, `bizStep = commissioning`/`harvesting`, `quantityList` (unité issue de la Rec. 20)
`TransferSingle` / `TransferBatch`	`ObjectEvent` OBSERVE avec `bizStep = shipping`/`receiving` ; source/destination issues de `from`/`to`
`BatchTransformed`	`TransformationEvent` (`inputQuantityList`, `outputQuantityList`, `transformationID`)
`BatchStatusChanged`	`ObjectEvent` avec `disposition`
`Attested`	élément de certification / capteur ou `ObjectEvent` dédié
métadonnées `gs1.*`	GTIN, LGTIN, SSCC, GLN, Digital Link

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.

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 :

Instrument	Où il se trouve	Comment le jeton le référence
Récépissé d'entrepôt électronique américain (7 CFR 869)	fournisseur d'EWR autorisé par l'USDA	`documents[].registry`, `originRef`
CPR-e, CDA/WA brésiliens	teneurs de registre autorisés par la Banque centrale	`documents[].registryId` ; lot d'avant-récolte avec `producedAt == 0`
Certificado de depósito / warrant argentin (loi 9.643)	entrepôt	hash de `originRef`
Connaissement électronique (juridictions MLETR)	plateforme d'eBL	hash du document ; dans les juridictions MLETR, le jeton peut lui-même satisfaire le contrôle exclusif
Déclaration de diligence raisonnée EUDR	système d'information de l'UE	`origin.eudr.ddsReference`, attestation `EUDR:DDS`

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.

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.

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é

Capacité	Statut
Portefeuilles / places de marché ERC-1155	natif
Outillage de conformité ERC-7943	natif
Modules de conformité ERC-3643	via un adaptateur de hook
Attestations ERC-735 / EAS	correspondance des thèmes
Export EPCIS 2.0	correspondance des champs dans le schéma ; côté indexeur
EVM à accès restreint	même bytecode
Inter-chaînes	wrappers ; la filiation reste sur la chaîne d'origine