Interoperabilidad

Con el ecosistema de Ethereum

Un token A-REX Core es un token ERC-1155. Las wallets, los exploradores, los mercados y los indexadores que entienden ERC-1155 funcionan sin cambios: saldos, transferencias múltiples, uri(id), aprobaciones, comprobaciones del receptor en las transferencias seguras. A-REX añade eventos y vistas; no elimina nada.

Un token A-REX Core es un multitoken ERC-7943. Los motores de cumplimiento y las plataformas de custodia que se basan en ERC-7943 (el Automated Compliance Engine de Chainlink ha demostrado compatibilidad; las plataformas de emisión de la coalición de ERC-7943 lo están adoptando) reconocen canTransfer, forcedTransfer, setFrozenTokens, canSend y canReceive sin adaptación.

Con los estándares de datos de trazabilidad

GS1 EPCIS 2.0 / CBV

El esquema de metadatos utiliza deliberadamente los nombres de EPCIS/CBV para que un exportador haga corresponder campos, no conceptos.

FSMA 204

Los elementos de datos clave son campos de metadatos (traceabilityLotCode, GLN, fechas, cantidades) y eventos; el CTE de transformación es BatchTransformed; la solicitud de registros en 24 horas es una consulta a un indexador. Consúltese el capítulo regulatorio para la correspondencia completa.

Codex, ISO 22000, GLOBALG.A.P. y esquemas orgánicos

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

Con los registros de documentos jurídicos

Los tokens A-REX referencian instrumentos jurídicos; no los sustituyen hasta que una jurisdicción reconozca el propio token:

Con los sistemas de identidad

El token solo plantea canSend(account) / canReceive(account). Detrás de esa pregunta pueden situarse:

• una lista de permitidos/bloqueados mantenida por el emisor (EligibilityHook);
• un registro de identidad ONCHAINID con temas de declaración (el modelo de ERC-3643);
• atestaciones de Ethereum Attestation Service sobre la cuenta;
• credenciales verificables comprobadas fuera de la cadena y reflejadas en la cadena por un relayer;
• un esquema nacional de e-ID (wallet de eIDAS 2.0 en la UE) mediante un verificador de credenciales.

Ninguno forma parte del estándar, por lo que un emisor en Brasil y otro en Alemania pueden usar proveedores distintos y seguir siendo interoperables.

Despliegue entre cadenas

El estándar es agnóstico respecto de la cadena. Patrones prácticos:

• Una única cadena de origen por emisor (recomendado): el linaje y la ejecución forzosa se mantienen coherentes; las demás cadenas contienen representaciones envueltas mediante adaptadores de estilo 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 favorece expresamente los diseños con permisos. El mismo bytecode.
• Espejos para la liquidez: un id de lote en la cadena de origen, un envoltorio ERC-20 en otra; el envoltorio debe respetar canTransfer del token de origen o limitarse a titulares elegibles.

El linaje nunca cruza cadenas; las referencias, sí.

Con los sistemas de gestión agrícola y de ERP

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

• Ruta de escritura: un servicio de originación posee ISSUER_ROLE y llama a createBatch a partir de eventos del ERP (ticket de báscula, emisión de recibos); setBatchStatus/setBatchMetadata a partir de eventos de almacén; transform a partir de órdenes de procesamiento.
• Ruta de lectura: un indexador materializa lotes, linaje, atestaciones y eventos de ejecución forzosa en las tablas de trazabilidad del ERP; exportación EPCIS para socios comerciales y reguladores.
• Comprobación previa: transferCheck permite que un ERP explique un rechazo a un operador antes de enviar una transacción.
• Identificadores: las claves GS1 en los metadatos tienden un puente hacia los repositorios EDI y EPCIS existentes; las unidades de UN/CEFACT ya están en los ERP.

Matriz de compatibilidad