Skip to main contentA-REX Core

Whitepaper · 06

Estándar del núcleo

La justificación de cada elemento de A-REX Core: por qué el registro del lote tiene exactamente estos campos, por qué el linaje es una operación y no un mapeo, por qué la ejecución forzosa procede de ERC-7943, por qué los códigos sustituyen a las enumeraciones y qué lecciones moldearon el diseño.

Objetivo de diseño: la interfaz más pequeña que un tercero implementará

Un estándar se adopta cuando implementarlo cuesta menos que no ser interoperable. Cada campo, función y regla de A-REX Core tuvo que superar una única prueba: ¿aceptaría un equipo independiente, que construye una plataforma de elevadores de granos en Argentina o el sistema de un exportador de café en Colombia, esta restricción a cambio de interoperabilidad? Las enumeraciones de cultivos, los nombres de calidades de EE. UU., un registro de fincas obligatorio, una pila de identidad prescrita y una fórmula de valoración fracasaron en esa prueba. La identidad del lote, el linaje, la ejecución forzosa y un punto de extensión la superaron.

El registro del lote, campo por campo

CampoPor qué está en la cadenaPor qué tiene esta forma
commodity: bytes32los hooks, los mercados y los reguladores deben poder filtrar por producto sin analizar los metadatoskeccak256("HS:100199") admite cualquier esquema (HS, FAO/CPC, GTIN, códigos nacionales) sin una tabla en el estándar; una enumeración congelaría la lista mundial de cultivos en el momento del despliegue
unit: bytes32las cantidades carecen de sentido sin una unidad; una transferencia de 1000 son 1000 kg o 1000 cajasla Recomendación 20 de UN/CEFACT es la lista de códigos utilizada por EDI, EPCIS y las aduanas
producedAt: uint64la perecibilidad, la estacionalidad y los contratos a plazo dependen todos del momento de producción0 significa «aún no producido»: los derechos de cobro sobre cosechas, los contratos a plazo y los warrants sobre cosechas futuras son los instrumentos de financiación agrícola dominantes en América Latina y deben poder representarse
expiresAt: uint64la regla de transferencia más común en la agricultura es «no después de esta fecha»0 significa ninguna; los hooks deciden qué implica la caducidad
originRef: bytes32el origen debe poder demostrarse (EUDR, orgánico, indicaciones geográficas)un hash o una referencia, nunca coordenadas: la geolocalización de la parcela de un productor es un dato personal (Directrices 02/2025 v2.0 del EDPB, julio de 2026) y una cadena pública inmutable no puede atender el derecho de supresión
metadataHash: bytes32 + uritodo lo demás está fuera de la cadena, pero el token debe comprometerse con ellohash de un documento JSON canónico que sigue un esquema publicado; uri puede ser IPFS, HTTPS o un GS1 Digital Link
status: uint8un lote atraviesa un ciclo de vida y algunos estados deben bloquear el movimientovalores abiertos con dos puntos fijos (0 activo, 255 retirado); la enumeración anterior de nueve estados codificaba el vocabulario de una única cadena de suministro y podía ser modificada por cualquier titular
issuer, createdAtrendición de cuentas y auditoríaestablecidos por el contrato, nunca por quien llama

Lo que falta deliberadamente: latitud y longitud, identificador de finca, enumeración de calidades, humedad y proteína, indicador de verificación y dirección del verificador, un campo quantity (el seguimiento del suministro de ERC-1155 es la referencia vinculante) y cualquier noción de valor.

El linaje como operación

Un ciclo de vida con un estado PROCESSED pero sin forma de producir el bien procesado es un error frecuente. Los regímenes de trazabilidad son explícitos en que la transformación es un evento que vincula entradas con salidas: el evento crítico de seguimiento de transformación de la FSMA 204, el TransformationEvent de EPCIS 2.0 con inputQuantityList y outputQuantityList. Un mapeo de progenitores escrito por un administrador no portaría las cantidades ni la atomicidad.

transform(from, to, inputIds, inputAmounts, outputs, outputAmounts, processRef) quema y acuña en una sola transacción, registra los progenitores en cada salida, emite un evento con todas las cantidades y una referencia de proceso, y ejecuta la canalización de hooks en cada tramo. La división (1→n), la fusión (n→1) y el procesamiento (n→m) son la misma función. La implementación de referencia permite que cualquier titular reagrupe (mismo producto básico y misma unidad, cantidad conservada), pero exige TRANSFORMER_ROLE para cambiar la naturaleza o la cantidad de los bienes: un molino puede convertir trigo en harina; un agricultor no puede convertir trigo en oro.

Ejecución forzosa a partir de ERC-7943, sin reinventarla

Los lotes agrícolas están sujetos habitualmente a gravámenes, warrants, embargos, procedimientos de insolvencia y retiradas de producto. Un token que no puede ser congelado ni movido por una parte autorizada contra la voluntad del titular no puede representar un lote así ante un banco, un tribunal o un regulador. ERC-3643 resolvió esto para los valores en 2021; ERC-7943 lo generalizó para cualquier activo del mundo real y alcanzó el estado Final en mayo de 2026 con una variante de ERC-1155. A-REX adopta esa interfaz de forma literal en lugar de definir la suya, de modo que los motores de cumplimiento compatibles con ERC-7943 (Chainlink ACE, herramientas de ERC-3643) reconozcan un token A-REX sin adaptación.

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

Un único hook, ordenado y con códigos

Un sistema de módulos construido sobre cinco interfaces de capacidades, cada una sondeada con supportsInterface en cada transferencia, no escala; con ocho módulos y cinco ids en una transferencia múltiple eso suponía ochenta llamadas estáticas antes de que se ejecutara regla alguna. Los rechazos eran cadenas de texto libres que ningún indexador podía interpretar y que ninguna prueba podía comparar de forma fiable.

A-REX Core define una única interfaz de hook con un mapa de bits de indicadores constante almacenado en caché en el registro. El token evalúa los hooks en un orden fijo y se detiene en el primer código bytes32 distinto de cero, revirtiendo con ARexHookRejected(hook, code). El orden es auditable (getHooks), la eliminación lo conserva y un hook averigua el token que lo llama a partir de msg.sender, de modo que un mismo despliegue sirve a muchos tokens. La elegibilidad (canSend/canReceive) se integra en la misma interfaz para que las vistas ERC-7943 del token sean la conjunción de sus hooks.

¿Por qué códigos y no errores personalizados del hook? Porque check es una vista que debe componerse: el token necesita preguntar a cada hook, comparar las respuestas y exponer la primera a través de transferCheck sin una reversión. Los códigos son baratos, indexables, traducibles y están organizados en espacios de nombres (keccak256("AREX:BATCH_EXPIRED"), keccak256("MYHOOK:QUOTA")).

Atestaciones por lote, emisores por tema

Certificar a un productor es un problema de identidad con soluciones maduras (ONCHAINID, Ethereum Attestation Service, credenciales verificables, e-ID nacionales). Certificar un lote es lo que verifican compradores, aduanas y reguladores, y no tenía una forma estándar. IARexAttest registra (batch, topic) → (issuer, reference, validity) y permite que un administrador decida qué emisor puede atestar sobre qué tema, reflejando el registro de emisores de confianza de ERC-3643 sin prescribir un proveedor de identidad. Los temas son bytes32 abiertos, de modo que coexisten los temas de declaración de ERC-735, los ids de esquema de EAS y los hashes de nombres de certificación.

isAttested es la única pregunta que formula un hook: es falso si la atestación está ausente, revocada o caducada, o si su emisor ha perdido la confianza. Esto permite que un hook haga cumplir «los lotes de café necesitan una referencia de diligencia debida del EUDR antes de poder venderse» en seis líneas.

Lo que el estándar no dice

  • No dice quién puede crear lotes, cambiar el estado o hacer cumplir medidas, solo que son roles, nunca saldos.
  • No dice qué significan los estados 1..254; el emisor publica una tabla en los metadatos.
  • No dice cómo valorar un lote, cómo decae, cuándo puede comercializarse según la estacionalidad, cómo se entrega o se asegura: todo ello corresponde a hooks o contratos complementarios.
  • No dice qué cadena, qué proveedor de identidad, qué oráculo ni qué registro.
  • No dice si el token es un valor o un producto básico.

Lecciones que moldearon el diseño

LecciónConsecuencia en A-REX Core
Un estándar que incluye un registro de fincas y un sistema de identidad como OBLIGATORIOS no es un estándar de token, es un productonada fuera del token es obligatorio
Una enumeración cerrada en la firma de una función convierte cualquier «registro dinámico» de productos básicos en código muertolos productos básicos, las unidades, los estados y los temas son códigos abiertos
La autoridad derivada del saldo es una vulnerabilidad en un token con varios titulareslos cambios de estado están restringidos por rol; RETIRED es terminal
La lógica de negocio en el núcleo contradice un «núcleo sin lógica de negocio»la valoración, el decaimiento y las ventanas residen en hooks
Una compilación que falla a partir de un clon limpio no es una implementación de referenciadependencias fijadas, lockfile incluido en el repositorio, CI en cada push
Las fechas regulatorias de un whitepaper envejecen; el código que depende de ellas no debe hacerloel token almacena referencias y hashes, nunca lógica regulatoria

Retrocompatibilidad

Los tokens de A-REX Core son tokens ERC-1155 y ERC-7943 completos. Las wallets, los mercados y los indexadores que conocen ERC-1155 funcionan sin cambios; las herramientas de cumplimiento compatibles con ERC-7943 reconocen la superficie de ejecución forzosa. Los motores de reglas escritos para otros tokens se conectan mediante un adaptador IARexHook siempre que sus decisiones dependan únicamente de los parámetros de la llamada y del registro del lote.