Whitepaper · 12
Interoperabilidad
Cómo encaja un token A-REX en lo que ya existe: estándares de tokens de Ethereum, motores de cumplimiento, estándares de datos de trazabilidad, registros de documentos legales, sistemas de identidad, infraestructura entre cadenas y sistemas agrícolas actuales.
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.
| Estándar | Relación |
|---|---|
| ERC-1155 | base; A-REX Core es una extensión |
| ERC-165 | detección de interfaces; se publican cinco ids |
| ERC-7943 | obligatorio; sus controles de cumplimiento se adoptan tal cual |
| ERC-3643 | compatible mediante un adaptador: un módulo de cumplimiento de ERC-3643 puede envolverse como IARexHook (una llamada a moduleCheck), y una regla externa (hook) de A-REX puede exponerse a un token ERC-3643. Los registros de identidad que usa ERC-3643 (ONCHAINID) se conectan como un hook de habilitación. |
| Claims de ERC-735 / ONCHAINID | los temas de claim equivalen directamente a temas de IARexAttest (bytes32(uint256 topic)) |
| Ethereum Attestation Service | los UID de esquema son temas válidos de IARexAttest; un registro de atestaciones (constancias verificables) basado en EAS puede implementar IARexAttest delegando isAttested |
| ERC-7201 | estructura de almacenamiento de la implementación de referencia |
| ERC-7573, patrones de retención y depósito en garantía | la entrega contra pago y el depósito en garantía se resuelven con hooks o contratos complementarios; el estándar no define cómo se liquida |
| ERC-7802 / Chainlink CCIP | los adaptadores de acuñación y quema entre cadenas pueden envolver el token; el linaje queda en la cadena de origen y lo que viaja son las referencias |
Con estándares de datos de trazabilidad
GS1 EPCIS 2.0 / CBV
| En la cadena | EPCIS 2.0 |
|---|---|
BatchCreated | ObjectEvent ADD, bizStep = commissioning/harvesting, quantityList (unidad según la Rec. 20) |
TransferSingle / TransferBatch | ObjectEvent OBSERVE con bizStep = shipping/receiving; origen y destino tomados de from/to |
BatchTransformed | TransformationEvent (inputQuantityList, outputQuantityList, transformationID) |
BatchStatusChanged | ObjectEvent con disposition |
Attested | elemento de certificación o de sensor, o un ObjectEvent propio |
metadatos gs1.* | GTIN, LGTIN, SSCC, GLN, Digital Link |
El esquema de metadatos usa a propósito los nombres de EPCIS/CBV. Así, un exportador solo tiene que mapear 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, 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í:
| Instrumento | Dónde está | Cómo lo referencia el token |
|---|---|---|
| Recibo de almacén electrónico de EE. UU. (7 CFR 869) | proveedor de EWR autorizado por el USDA | documents[].registry, originRef |
| CPR-e, CDA/WA de Brasil | registradoras autorizadas por el Banco Central | documents[].registryId; lote previo a la cosecha con producedAt == 0 |
| Certificado de depósito / warrant de Argentina (Ley 9.643) | almacén | hash en originRef |
| Conocimiento de embarque electrónico (jurisdicciones con MLETR) | plataforma de eBL | hash del documento; en las jurisdicciones con MLETR, el token mismo puede cumplir el requisito de control exclusivo |
| Declaración de debida diligencia del EUDR | Sistema de Información de la UE | origin.eudr.ddsReference, atestación EUDR:DDS |
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.
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
canTransferdel token original o limitarse a titulares habilitados.
El linaje nunca sale de su cadena; las referencias, sí.
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_ROLEy llama acreateBatcha partir de eventos del ERP (boleta de báscula, emisión de certificados), asetBatchStatus/setBatchMetadataa partir de eventos del almacén y atransforma 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
| Capacidad | Estado |
|---|---|
| Billeteras / marketplaces ERC-1155 | nativo |
| Herramientas de cumplimiento ERC-7943 | nativo |
| Módulos de cumplimiento ERC-3643 | mediante un adaptador de hook |
| Atestaciones ERC-735 / EAS | equivalencia de temas |
| Exportación EPCIS 2.0 | mapeo de campos en el esquema; lo resuelve el indexador |
| EVM con permisos | mismo bytecode |
| Entre cadenas | wrappers; el linaje queda en la cadena principal |