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.

Las lecturas de sensores no forman parte del núcleo. Un hook de entrega puede registrar una temperatura en la cadena; las demás mediciones (humedad, CO₂ y O₂, golpes, inclinación, puerta, posición) quedan fuera de la cadena en la misma sensorElementList, con su tipo CBV y su unidad de la Rec. 20. El mapeo describe un patrón para comprometerse con ellas: por ventana de tiempo, la peor lectura de temperatura con una referencia que es una raíz sobre cada lectura de la ventana y el mensaje original del que vino, de modo que un auditor pueda verificar una lectura contra la cadena. El compromiso prueba lo que tenía quien registró en ese bloque, no que el dispositivo midiera bien. Los puntos de lectura y las ubicaciones de negocio son identificadores de sitio, nunca coordenadas.

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.

El lugar donde se produjeron los bienes se indica con códigos: el país (ISO 3166-1), la subdivisión de primer nivel (ISO 3166-2, por ejemplo BR-MG) y el UN/LOCODE de una localidad solo para un sitio comercial, como un almacén o un puerto, nunca para una finca. Las lecturas de sensores van en el sensorData del MoveEvent de la entrega; un pasaporte lleva como mucho un resumen. Desde el esquema de metadatos 1.3.0 (ADR-024, Propuesto), origin.region es siempre un código así.

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. La revisión 1.2 agrega el tipo de lugar ref:site (el originRef que llevan sus lotes, nunca una ubicación) e indica que el gas declarado se mide con los ajustes cargados (gas.setup opcional). La revisión 1.3 documenta los campos que su primer consumidor ya escribe (acciones, errores propios del contrato, medidas, el dato por entrega y una forma completa de los eventos), todos opcionales. La revisión 1.4 agrega lo que una plataforma necesita para armar formularios de complementos: más tipos de valor, qué llega al registro (nunca datos personales), presentación y controles por campo, vistas de solo lectura y cómo un registro se lleva a EPCIS y a un pasaporte UNTP (una característica declarada por su organización, nunca una afirmación). La revisión 1.5 sala cada huella: un descriptor que declara fingerprint: { "scheme": "salted-jcs/1" } registra el hash de cada valor junto con su propia sal de 32 bytes, de modo que textos cortos, números o contornos de parcelas no pueden encontrarse probando candidatos. La revisión 1.6 añade medidas que no son totales (avg, min, max de un campo numérico, nunca sumadas entre grupos ni entre empresas) y dos formas de agruparlas, por la parte que creó el lote (party) y por su sitio (site); la plantilla del complemento de humedad de la versión de referencia 2.0.0-alpha.10 la usa para la humedad media a la recepción. La revisión 1.7 permite que el visibleWhen de un campo use el árbol de condiciones del descriptor de vocabulario (all, any, not; como máximo 3 niveles y 12 hojas) sobre los demás campos del formulario; la condición única de la revisión 1.4 sigue siendo válida, pero queda obsoleta.

Las organizaciones pueden publicar sus propios tipos de trabajo de campo, tipos de proceso y listas de etapas como definiciones de vocabulario arex.vocab/1. Cada una se asocia a una de 26 clases de etapa de referencia (por ejemplo drying o fermenting) y a un paso de negocio GS1 CBV. Sus eventos EPCIS llevan tres capas: el bizStep CBV que lee cualquier sistema EPCIS, la clase de referencia (arex:stageClass) que permite que dos organizaciones con nombres distintos comparen sus registros, y el tipo, los nombres y los valores publicados de la propia organización. En un pasaporte UNTP los valores son características, nunca afirmaciones. Los metadatos de un lote procesado pueden nombrar el tipo de proceso y la corrida que hay detrás en un objeto process, previsto para el esquema de metadatos 1.4.0. La revisión 1.1 agrega una disposición opcional del formulario (secciones, anchos, condiciones) que solo restringe lo que aceptan los campos. La revisión 1.2 permite que las condiciones usen not, lleguen a 3 niveles con hasta 12 hojas y lean el contexto del registro en códigos (el cultivo como código EPPO, días desde la siembra, tipo de sitio, país, partida SA del producto, última etapa); el contexto desconocido se lee como vacío. La revisión 1.3 agrega el orden de una lista de etapas (order): strict (por defecto; una etapa anterior obligatoria debe registrarse primero) o flexible (cualquier orden, los huecos quedan para los informes). La revisión 1.4 agrega métodos de beneficio del café (washed, natural, honey, pulped_natural, wet_hulled, anaerobic y otros) que un tipo de proceso da a sus salidas y que llevan los metadatos process de un lote: una declaración de la organización, no una certificación. La revisión 1.5 agrega subclases de las clases amplias (separating, conditioning, sorting_grading, heat_treating) de una lista cerrada, de modo que un lector empareja el paso de otra organización de una clase amplia solo por su subclase o por una correspondencia explícita por remitente. La revisión 1.6 agrega to_processor, una subclase de transporting: mercadería enviada a un procesador que la trabaja para su dueño (maquila), de modo que cambia la custodia y no la titularidad. Las etiquetas del libro mayor, las referencias de etapa y los sujetos de sitio llevan sal, de modo que no se puede leer en el libro mayor ningún flujo de proceso ni la cronología de una finca, y el dinero nunca se escribe en claro en el libro mayor. Una etapa de empaque o de carga registrada con una unidad logística (un SSCC, un número de contenedor) corresponde a un AggregationEvent de EPCIS. En la versión de referencia 2.0.0-alpha.9, CompanyFactsHook escribe estos registros en el libro mayor y RequireStageHook rechaza las entregas de lotes a los que les faltan las etapas exigidas; ninguno de los dos módulos es obligatorio. Todo es informativo y Propuesto.

Despliegue en varias cadenas

A-REX Core es un estándar EVM (ADR-026, Propuesto): un token conforme funciona en cualquier red EVM de nivel paris o posterior, y el estándar no mantiene ninguna lista de redes; las que una organización puede usar las fija su perfil de políticas. Las redes se nombran con identificadores CAIP-2, como eip155:8453 o hedera:mainnet. 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. Desde el esquema 1.4.0 (Propuesto), una entrada también puede indicar la red CAIP-2 (network), y un lote registrado en una red que no es EVM se nombra por su red y su activo CAIP-19.

Registros que cualquiera puede comprobar, en cualquier red

La evidencia en torno a un token no depende de la red del token. Una vez por periodo, un emisor puede combinar las huellas de sus registros (su registro de auditoría, informes, documentos) en una sola raíz de Merkle y publicar esos 32 bytes en varias redes independientes: su propia red EVM, Bitcoin a través de OpenTimestamps y el Hedera Consensus Service. Cada registro recibe una prueba arex.anchor-proof/1 breve. Quien tenga el registro y su prueba puede comprobar, sin ningún servicio de A-REX, que el registro existía sin cambios a más tardar en el momento en que cada red recibió la raíz; un contrato EVM puede comprobar la misma prueba con MerkleProof de OpenZeppelin. Solo se publican hashes, nunca datos personales. El formato es informativo y está Propuesto (ADR-026). En qué redes ancla un emisor es una cuestión de política, fijada por su perfil de jurisdicción u organización, y una prueba es válida con cualquier número de recibos. Un recibo de Hedera indica el id de su transacción cuando se envía la raíz, y obtiene el número de secuencia y la hora de consenso del mensaje en cuanto un nodo espejo público lo confirma.

De dónde salen los números de un informe firmado

Un informe calculado a partir de los registros de un emisor, como «1 200 kg entregados a un comprador en octubre» o una lista de registros, puede llevar sus fuentes: una línea por cada registro que leyó, con el lugar donde el libro mayor guarda ese registro y los valores que usó el informe. Cada línea es una fuente arex.report-sources/1; su hoja es keccak256(0x03 ‖ JCS(source)), y las hojas ordenadas se emparejan hasta una sola raíz de fuentes. La raíz y el SHA-256 del archivo de fuentes (<report>.sources.csv) se sellan con el informe, en su manifiesto firmado o bajo la firma de un PDF, de modo que después no se puede añadir, quitar ni cambiar ninguna línea. El informe dice cuántos de sus registros se comprueban contra el libro mayor, cuántos a través de una huella en el libro mayor (un ancla diaria o una ventana de lecturas) y cuántos son solo registros del emisor, cubiertos por su sello. Una fuente nunca contiene un valor personal en claro. Un lector lo comprueba todo sin ningún servicio de A-REX: verify-sources.mjs, un verificador autónomo (Node.js 20, nada que instalar) que cualquier implementación puede incluir, recalcula cada hoja y la raíz, las compara con el informe y luego lee cada registro del libro mayor desde cualquier nodo de su red. Un informe con varias tarjetas conserva un solo archivo de fuentes y una sola raíz; cada línea nombra su tarjeta en el miembro opcional section (revisión 1.1), de modo que los números de cada tarjeta se suman por separado.

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

El formato es informativo y está Propuesto (revisión 1.1 de las fuentes de informes). El documento del estándar, compartido con acceso anticipado, da las columnas del archivo, cada comprobación y un vector de ejemplo; el esquema describe una fuente.

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