Estándar del núcleo

Objetivo de diseño: la interfaz mínima que un tercero esté dispuesto a implementar

Un estándar se adopta cuando implementarlo cuesta menos que quedarse sin interoperabilidad. Cada campo, función y regla de A-REX Core tuvo que pasar una sola prueba: ¿aceptaría esta restricción, a cambio de interoperabilidad, un equipo independiente que desarrolla una plataforma de acopio de granos en Argentina o el sistema de un exportador de café en Colombia? No la pasaron las listas cerradas de cultivos, los nombres de grados de calidad de EE. UU., un registro obligatorio de fincas, una pila de identidad impuesta ni una fórmula de valoración. Sí la pasaron la identidad del lote, el linaje, los controles de cumplimiento y un punto de extensión.

El registro del lote, campo por campo

Lo que queda fuera a propósito: latitud y longitud, identificador de finca, enum de calidades, humedad y proteína, indicador de verificación y dirección del verificador, un campo quantity (la contabilidad de emisión de ERC-1155 es la fuente de verdad) y cualquier noción de valor.

El linaje como operación

Un error frecuente es definir un estado PROCESSED sin ninguna forma de producir el bien procesado. Los regímenes de trazabilidad dejan claro que la transformación es un evento que vincula entradas con salidas. Así la tratan el evento crítico de seguimiento de transformación de la FSMA 204 y el TransformationEvent de EPCIS 2.0, con inputQuantityList y outputQuantityList. Un mapeo de lotes de origen escrito por un administrador no conservaría ni las cantidades ni la atomicidad.

transform(from, to, inputIds, inputAmounts, outputs, outputAmounts, processRef) quema y acuña en una sola transacción. Registra los lotes de origen en cada salida, emite un único evento con todas las cantidades y una referencia de proceso, y aplica la cadena de reglas en cada tramo. Dividir (1→n), fusionar (n→1) y procesar (n→m) usan la misma función. La implementación de referencia permite que cualquier titular reagrupe lotes (mismo producto y unidad, cantidad conservada) en su propia cuenta. En cambio, exige TRANSFORMER_ROLE para cambiar la naturaleza o la cantidad de los bienes, o para entregar las salidas a otra cuenta: un molino puede convertir trigo en harina, pero un agricultor no puede convertir trigo en oro. Los dos tramos de un transform ejecutan los hooks como OP_TRANSFORM, así que un agricultor que vende parte de un lote primero lo reagrupa en su propia cuenta y después lo transfiere; la venta aplica todas las reglas de transferencia.

transform no puede cruzar de un token a otro. Cuando el token de un comprador recibe bienes del token de un proveedor, el nuevo lote nombra en sus metadatos el lote del proveedor: la lista upstream del esquema 1.2.0 indica el id de la cadena, el contrato, el id del token y si los bienes se recibieron de ese lote sin cambios (received_from) o se procesaron a partir de él (processed_from). Una referencia a un lote de otro token es una afirmación del emisor del lote posterior, no un hecho en la cadena. Por eso se pide a indexadores, auditores y herramientas de retiro del mercado que la contrasten con el token de origen y que muestren como no verificadas las referencias que no pudieron comprobar. Un retiro del mercado hacia adelante entre tokens lee esas listas, porque el token de origen no guarda ningún registro de ellas.

Controles de cumplimiento tomados de ERC-7943, sin reinventarlos

Es habitual que los lotes agrícolas estén sujetos a gravámenes, warrants, embargos, procesos de insolvencia y retiros del mercado. Si una parte autorizada no puede congelar ni mover un token contra la voluntad del titular, ese token no sirve para representar el lote ante un banco, un tribunal o un regulador. ERC-3643 resolvió este problema para los valores (securities) en 2021. ERC-7943 lo generalizó para cualquier activo del mundo real y alcanzó el estado Final en mayo de 2026, con una variante para ERC-1155. A-REX adopta esa interfaz tal cual, en lugar de definir una propia. Así, los motores de cumplimiento que ya soportan ERC-7943 (Chainlink ACE, herramientas de ERC-3643) reconocen un token A-REX sin adaptaciones.

La variante multitoken encaja de forma natural con ERC-1155: el congelamiento se aplica por cuenta y por id de lote, las transferencias forzosas indican el lote y la habilitación se define por cuenta.

Un solo hook, ordenado y con códigos

Un sistema de módulos basado en cinco interfaces de capacidad, cada una consultada con supportsInterface en cada transferencia, no escala. Con ocho módulos y cinco ids en una transferencia múltiple, eso sumaba ochenta llamadas estáticas antes de evaluar una sola regla. Además, los rechazos eran cadenas de texto libre: ningún indexador podía interpretarlas y ninguna prueba podía compararlas de forma fiable.

A-REX Core define una sola interfaz de hook, con un mapa de bits constante de indicadores que el token guarda en caché al registrar el hook. El token evalúa los hooks en un orden fijo y se detiene en el primer código bytes32 distinto de cero; en ese caso revierte con ARexHookRejected(hook, code). El orden se puede auditar (getHooks) y se mantiene al quitar un hook. Cada hook identifica el token que lo llama mediante msg.sender, así que un solo despliegue sirve a muchos tokens. La habilitación de cuentas (canSend/canReceive) forma parte de la misma interfaz, de modo que las vistas ERC-7943 del token son la conjunción de sus hooks.

¿Por qué códigos y no errores personalizados que lance el hook? Porque check es una vista que tiene que poder combinarse: el token necesita consultar a cada hook, comparar las respuestas y exponer la primera mediante transferCheck sin revertir. Los códigos son baratos, indexables, traducibles y tienen espacio de nombres (keccak256("AREX:BATCH_EXPIRED"), keccak256("MYHOOK:QUOTA")).

Atestaciones por lote, emisores por tema

Certificar a un productor es un problema de identidad que ya tiene soluciones maduras (ONCHAINID, Ethereum Attestation Service, credenciales verificables, identificaciones electrónicas nacionales). Certificar un lote es lo que verifican compradores, aduanas y reguladores, y no existía una forma estándar de hacerlo. IARexAttest registra atestaciones (certificados o constancias verificables) con la forma (batch, topic) → (issuer, reference, validity). Además, permite que un administrador decida qué emisor puede atestar cada tema. Sigue el modelo del registro de emisores de confianza de ERC-3643, sin imponer un proveedor de identidad. Los temas son bytes32 abiertos, así que conviven los temas de claims de ERC-735, los ids de esquema de EAS y los hashes de nombres de certificaciones.

isAttested es la única pregunta que hace un hook. Devuelve falso si la atestación no existe, fue revocada o venció, o si su emisor perdió la confianza. Con esto, un hook puede aplicar en seis líneas la regla «los lotes de café necesitan una referencia de debida diligencia EUDR antes de poder venderse».

El emisor de una atestación siempre puede revocarla, y también puede hacerlo un revocador en quien el emisor delegó, igual que ocurre con las listas de estado de credenciales del W3C y con los emisores de claims de ERC-3643. En el borrador propuesto con ADR-019 (Propuesto), un administrador del token o del contrato de atestaciones no debería poder revocar en 2.x una atestación que no emitió, y no debe poder hacerlo a partir de la versión 3.0; una implementación 2.x que conserve esa facultad lo documenta ante los emisores y ante quienes confían en sus atestaciones. Un operador que considera erróneo un certificado no lo revoca: lo marca como disputado fuera de la cadena y avisa al emisor. Un token que deja de confiar en un emisor lo quita del tema, y así sus atestaciones pasan a ser falsas para ese token.

Lo que el estándar no define

• No define quién puede crear lotes, cambiar su estado o aplicar medidas de cumplimiento; solo establece que son roles y nunca saldos.
• No define qué significan los estados 1..254: el emisor publica una tabla en los metadatos.
• No define cómo valorar un lote, cómo se deteriora, en qué temporada se puede comercializar ni cómo se entrega o se asegura. Todo eso corresponde a hooks o a contratos complementarios.
• No define qué cadena, qué proveedor de identidad, qué oráculo ni qué registro usar.
• No define si el token es un valor (security) o una commodity.
• No define quién puede usar una capacidad, si está activada ni qué listas y autoridades se aplican: quién tiene el rol de cumplimiento, quién puede pausar, qué listas de sanciones cuentan. ADR-019 (Propuesto) lleva eso a un perfil de políticas versionado por jurisdicción y por organización, de modo que un cambio de ley sea una actualización del perfil y no un contrato nuevo ni una versión nueva del estándar.

Lecciones que guiaron el diseño

Retrocompatibilidad

Los tokens de A-REX Core son tokens ERC-1155 y ERC-7943 completos. Las billeteras, los marketplaces y los indexadores que conocen ERC-1155 funcionan sin cambios. Las herramientas de cumplimiento compatibles con ERC-7943 reconocen sus controles de cumplimiento. Los motores de reglas escritos para otros tokens se conectan mediante un adaptador IARexHook, siempre que sus decisiones dependan solo de los parámetros de la llamada y del registro del lote.