Whitepaper · 06
Estándar del núcleo
Por qué A-REX Core es como es: por qué el registro del lote tiene justo estos campos, por qué el linaje es una operación y no un mapeo, por qué los controles de cumplimiento vienen de ERC-7943, por qué se usan códigos en lugar de enums y qué lecciones guiaron el diseño.
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
| Campo | Por qué está en la cadena | Por qué tiene esta forma |
|---|---|---|
commodity: bytes32 | las reglas externas (hooks), los marketplaces y los reguladores tienen que poder filtrar por producto sin interpretar los metadatos | keccak256("HS:100199") acepta cualquier esquema (HS, FAO/CPC, GTIN, códigos nacionales) sin que el estándar mantenga una tabla; un enum congelaría la lista mundial de cultivos en el momento del despliegue |
unit: bytes32 | una cantidad no significa nada sin su unidad: una transferencia de 1000 puede ser de 1000 kg o de 1000 cajas | la Recomendación 20 de UN/CEFACT es la lista de códigos que usan EDI, EPCIS y las aduanas |
producedAt: uint64 | la perecibilidad, la estacionalidad y los contratos a término dependen de la fecha de producción | 0 significa «todavía no producido»: los derechos de cobro sobre la cosecha, los contratos a término y los warrants sobre cosechas futuras son los principales instrumentos de financiación agrícola en América Latina, y el token tiene que poder representarlos |
expiresAt: uint64 | la regla de transferencia más común en el agro es «no después de esta fecha» | 0 significa sin vencimiento; los hooks deciden qué implica el vencimiento |
originRef: bytes32 | el origen tiene que ser demostrable (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 cumplir con el derecho de supresión |
metadataHash: bytes32 + uri | todo lo demás está fuera de la cadena, pero el token tiene que anclar ese contenido | hash de un documento JSON canónico que sigue un esquema publicado; uri puede ser IPFS, HTTPS o un GS1 Digital Link |
status: uint8 | un lote recorre un ciclo de vida y algunos estados tienen que impedir que se mueva | valores abiertos con dos puntos fijos (0 activo, 255 retirado); el enum anterior de nueve estados reflejaba el vocabulario de una sola cadena de suministro y cualquier titular podía cambiarlo |
issuer, createdAt | rendición de cuentas y auditoría | los fija el contrato, nunca quien hace la llamada |
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 cambio, exige TRANSFORMER_ROLE para cambiar la naturaleza o la cantidad de los bienes: un molino puede convertir trigo en harina, pero un agricultor no puede convertir trigo en oro.
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».
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.
Lecciones que guiaron el diseño
| Lección | Consecuencia en A-REX Core |
|---|---|
| Un estándar que declara OBLIGATORIOS un registro de fincas y un sistema de identidad no es un estándar de token: es un producto | no se exige nada fuera del token |
| Un enum cerrado en la firma de una función convierte en código muerto cualquier «registro dinámico» de productos | productos, unidades, estados y temas son códigos abiertos |
| En un token con varios titulares, derivar la autoridad del saldo es una vulnerabilidad | los cambios de estado requieren un rol; RETIRED es terminal |
| Poner lógica de negocio en el núcleo contradice la idea de un «núcleo sin lógica de negocio» | la valoración, el deterioro y las ventanas viven en hooks |
| Si el código no compila desde un clon limpio, no es una implementación de referencia | dependencias con versión fija, lockfile en el repositorio, CI en cada push |
| Las fechas regulatorias de un whitepaper envejecen; el código que depende de ellas no puede envejecer con ellas | el token guarda referencias y hashes, nunca lógica regulatoria |
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.