Interoperabilidad

Con el ecosistema de Ethereum

Un token A-REX Core es un token ERC-1155. Las billeteras, exploradores, marketplaces e indexadores compatibles con ERC-1155 funcionan sin cambios: saldos, transferencias múltiples, uri(id), aprobaciones y verificación del receptor en las transferencias seguras. A-REX agrega eventos y vistas; no quita nada.

Un token A-REX Core es un multitoken ERC-7943. Los motores de cumplimiento y las plataformas de custodia diseñados para ERC-7943 reconocen canTransfer, forcedTransfer, setFrozenTokens, canSend y canReceive sin adaptaciones. El Automated Compliance Engine de Chainlink ya demostró su compatibilidad, y las plataformas de emisión de la coalición ERC-7943 lo están adoptando.

Con estándares de datos de trazabilidad

GS1 EPCIS 2.0 / CBV

El estándar publica un mapeo informativo, evento por evento:

El esquema de metadatos usa a propósito los nombres de EPCIS/CBV. Así, un exportador solo tiene que mapear campos, no conceptos.

UN Transparency Protocol (UNTP 0.7.0)

Un mapeo informativo convierte un lote, sus eventos y sus atestaciones en credenciales de UNTP 0.7.0, con los mismos identificadores que el mapeo de EPCIS para que ambos se puedan unir:

Las credenciales siguen el W3C Verifiable Credentials Data Model 2.0 y se firman con VC-JOSE-COSE bajo el did:web del emisor; la revocación usa una Bitstring Status List. Una credencial firmada también se puede anclar a su lote como una atestación cuya referencia es el hash de la credencial: el ancla prueba el compromiso y la firma prueba el contenido. Una credencial lleva solo lo que contienen el token o sus metadatos, y los valores que requieren un método (una huella, una puntuación de riesgo) solo aparecen cuando una parte identificada los declaró. El mapeo indica lo que no cubre, empezando por el Digital Product Passport de la UE: el ESPR no se aplica a los alimentos, los piensos ni las plantas y animales vivos, y A-REX no hace ninguna afirmación de pasaporte para ellos.

Huellas de carbono declaradas (PACT 3.0.3)

ADR-018 (Propuesto) permite que un lote lleve una huella de carbono de producto calculada por un tercero, en extensions.pact_pcf del documento de metadatos. El fragmento sigue campo por campo las WBCSD PACT Technical Specifications 3.0.3: quién la declaró, la unidad declarada y el período de referencia, la huella con y sin absorción biogénica, y un estado de verificación obligatorio que nombra al verificador cuando la huella está verificada. Se copia; nunca se calcula, se suma ni se traslada a los lotes hechos a partir del lote, y no es un crédito de carbono (ADR-014). El mapeo es un derivado independiente de PACT y no copia ningún archivo de PACT.

Códigos de producto y de unidad

Un código de producto es keccak256("<SCHEME>:<CODE>") para cualquier esquema: el Sistema Armonizado (HS), las nomenclaturas arancelarias nacionales (NCM en el Mercosur, CN y TARIC en la UE, HTS en Estados Unidos, entre otras), FAO, CPC, GTIN o uno propio del emisor. Desde el esquema de metadatos 1.1.0, el esquema en el documento también es abierto, así que los metadatos pueden reflejar el código en la cadena. Las unidades son códigos de la Recomendación 20 de UN/CEFACT (KGM, TNE, LTR), la lista que ya usan EDI, EPCIS y las aduanas.

FSMA 204

Los elementos de datos clave son campos de metadatos (traceabilityLotCode, GLN, fechas, cantidades) y eventos. El CTE de transformación es BatchTransformed, y la solicitud de registros en 24 horas se responde con una consulta al indexador. El mapeo completo está en el capítulo regulatorio.

Codex, ISO 22000, GLOBALG.A.P. y certificaciones orgánicas

Todos son temas de atestación. El estándar no los enumera: keccak256("GLOBALGAP:IFA"), keccak256("AREX:CERT:ORGANIC_EU") y keccak256("CODEX:MRL") son convenciones que el emisor publica junto con su esquema de metadatos.

Con registros de documentos legales

Los tokens A-REX hacen referencia a los instrumentos legales. No los reemplazan mientras una jurisdicción no reconozca al token en sí:

Con sistemas de identidad

El token solo pregunta canSend(account) / canReceive(account). Detrás de esa pregunta puede haber:

• una lista de cuentas habilitadas o bloqueadas que administra el emisor (EligibilityHook);
• un registro de identidad ONCHAINID con temas de claim (el modelo de ERC-3643);
• atestaciones de Ethereum Attestation Service sobre la cuenta;
• credenciales verificables que se validan fuera de la cadena y que un relayer refleja en la cadena;
• un esquema nacional de identidad digital (billetera eIDAS 2.0 en la UE) a través de un verificador de credenciales.

Ninguna de estas opciones forma parte del estándar. Por eso, un emisor en Brasil y otro en Alemania pueden usar proveedores distintos y seguir siendo interoperables.

Con motores de reglas y plataformas

Una regla o un complemento puede publicar un descriptor arex.module/1: un documento JSON con sus parámetros, ajustes, campos del lote requeridos, tipos de certificado, eventos, códigos de rechazo y cómo pasa su estado a una versión nueva. Una plataforma, una billetera, un indexador o un auditor que lee descriptores integra una regla nueva sin código a medida. El formato es informativo y Propuesto; pasa a ser un formato recomendado cuando lo consume un segundo implementador independiente. La revisión 1.1 agrega una lista opcional e informativa ops con las operaciones que gobierna una regla; si falta, se desconocen, y nunca se usa para aplicar controles.

Despliegue en varias cadenas

El estándar no depende de ninguna cadena en particular. Estos son los patrones prácticos:

• Una sola cadena principal por emisor (recomendado): el linaje y los controles de cumplimiento se mantienen coherentes. Las demás cadenas tienen versiones envueltas del token mediante adaptadores al estilo de ERC-7802 o CCIP.
• Cadena EVM con permisos, para emisores cuya autoridad de protección de datos o institución ancla lo exija; el EDPB prefiere expresamente los diseños con permisos. El bytecode es el mismo.
• Réplicas para dar liquidez: un id de lote en la cadena principal y un wrapper ERC-20 en otra. El wrapper debe respetar canTransfer del token original o limitarse a titulares habilitados.

El linaje nunca sale de su cadena; las referencias, sí. Entre tokens de la misma cadena o de cadenas distintas, un lote hecho a partir del lote de otro token lo nombra en la lista upstream de sus metadatos (esquema 1.2.0) por id de cadena, contrato e id de token. Esas referencias son afirmaciones del emisor, que hay que contrastar con el token de origen.

Con sistemas de gestión agrícola y ERP

Los puntos de integración son los mismos que para cualquier token ERC-1155, más las vistas de lote:

• Escritura: un servicio de originación tiene ISSUER_ROLE y llama a createBatch a partir de eventos del ERP (boleta de báscula, emisión de certificados), a setBatchStatus/setBatchMetadata a partir de eventos del almacén y a transform a partir de órdenes de procesamiento.
• Lectura: un indexador vuelca los lotes, el linaje, las atestaciones y los eventos de cumplimiento en las tablas de trazabilidad del ERP, y genera exportaciones EPCIS para socios comerciales y reguladores.
• Verificación previa: con transferCheck, el ERP puede explicarle un rechazo al operador antes de enviar la transacción.
• Identificadores: las claves GS1 de los metadatos conectan con los repositorios EDI y EPCIS existentes; las unidades UN/CEFACT ya están en los ERP.

Matriz de compatibilidad