Estándar
A-REX Core — el estándar
Qué define el estándar, qué hace un token conforme, cómo evoluciona y cómo llegará a ser un ERC. El texto normativo se comparte por acceso anticipado.
Estado
Borrador 2.1.0-alpha.2, todavía sin enviar, con el esquema de metadatos del lote 1.2.0. El texto sigue el formato de un Ethereum Request for Comments. Así podrá enviarse a ethereum/ERCs cuando implementadores independientes hayan usado las interfaces en producción. Se publicará bajo CC0; la implementación de referencia tiene licencia MIT. Mientras no existan dos implementadores independientes, los cambios aceptados se marcan como provisionales.
Qué define
A-REX Core es una extensión pequeña de ERC-1155 y ERC-7943. Cada lote es un id de token ERC-1155, ya sea un lote de un producto físico o el derecho a un lote futuro. El estándar le agrega cuatro capas:
| Capa | Interfaz | Qué cubre | Obligatoria |
|---|---|---|---|
| 0 | ERC-1155, ERC-165, IERC7943MultiToken | saldos y transferencias múltiples; congelar, transferencia forzosa, habilitación de cuentas | sí |
| 1 | IARexBatch | el registro del lote: códigos abiertos de producto y unidad, fechas de producción y vencimiento, una referencia de origen, un compromiso con un documento fuera de la cadena, un estado del ciclo de vida y el linaje cuando un lote se divide, se fusiona o se procesa | sí |
| 2 | IARexHook, IARexHookManager | una sola cadena ordenada de contratos de reglas externos (hooks); cada regla responde con un motivo legible por máquina | sí |
| 3 | IARexAttest | certificaciones, inspecciones y declaraciones por lote y por tema, hechas por emisores de confianza para ese tema | recomendada, en el token o en un contrato complementario |
Qué hace un token conforme
- Se comporta como un token ERC-1155 común, así que billeteras, marketplaces e indexadores funcionan sin cambios.
- Ofrece los controles de cumplimiento de ERC-7943. Un lote puede congelarse o moverse por una orden judicial, un gravamen o un retiro del mercado, y cada medida de cumplimiento queda visible en la cadena.
- Mantiene un registro de cada lote y anota cada división, fusión o paso de procesamiento. Así siempre puedes rastrear los lotes de origen.
- Hace pasar cada transferencia por su cadena de reglas y puede explicar por qué rechaza una transferencia.
- Declara las interfaces que implementa, para que las herramientas puedan detectarlo.
Un contrato de reglas (un hook) es conforme cuando implementa IARexHook. Un mismo contrato de reglas puede servir a muchos tokens.
Cómo se verifica la conformidad
La implementación de referencia incluye una suite de conformidad que no depende de ella: la implementación bajo prueba se alcanza solo a través de las interfaces del estándar y de un pequeño adaptador que escriben sus autores. Cada prueba indica la cláusula que verifica; hay 85 cláusulas, 74 de nivel MUST y 11 de nivel SHOULD. Cada ejecución termina con un veredicto, y una declaración de conformidad tiene que explicar cada cláusula que omitió. Las cláusulas que no se pueden observar en la cadena, como la regla de que la referencia de origen no contiene datos personales, quedan para la revisión.
Propuesto y no publicado
Estos cambios están redactados y abiertos a revisión. Ninguno está aceptado: cada uno espera la confirmación de dos implementadores independientes, y los de nivel MUST siguen la regla de los cambios mayores.
| Propuesta | Qué cambiaría |
|---|---|
| ADR-019 (Propuesto): capacidades en el estándar, políticas en perfiles | El estándar fija los roles, los eventos, las estructuras de datos, la semántica de la pausa y de la revocación, y las reglas de privacidad. Quién puede usar una capacidad, si está activada y qué listas o autoridades se aplican pasa a perfiles de políticas versionados por jurisdicción y por organización. Trae dos aclaraciones: la referencia de origen NO DEBE derivarse de la ubicación (ni hash ni codificación de coordenadas o de la geometría de la parcela); y el emisor de una atestación, o un revocador en quien delegó, la revoca, mientras que un rol administrativo NO DEBERÍA revocar en 2.x una atestación que no emitió y NO DEBE hacerlo a partir de 3.0, de modo que los tokens ya desplegados sigan siendo conformes. |
ADR-017 (Propuesto): extensions en los metadatos | El esquema de metadatos 1.3.0 agregaría un objeto opcional extensions, con una entrada por regla, validada con el fragmento de esquema del descriptor de la regla. |
| ADR-018 (Propuesto): huella de carbono declarada | Un lote puede llevar una huella de carbono de producto declarada por un tercero identificado, copiada de PACT 3.0.3 a extensions.pact_pcf con un estado de verificación; nunca se calcula, se suma ni se traslada a otros lotes. |
| ADR-020, ADR-021, ADR-022 (Propuesto): adaptadores de referencia | Las herramientas de ERC-3643 leen cada lote mediante una vista que no puede permitir ni rechazar nada; claims de ONCHAINID válidos mientras A-REX confía en su firmante; un espejo en EAS de los certificados y los registros de lotes vigentes. Informativos: no agregan ningún requisito. |
Descriptor de reglas arex.module/1 (informativo, Propuesto) | Un documento JSON que publica una regla o un complemento para que quienes lo consumen lo integren sin código a medida. |
Los mapeos informativos a GS1 EPCIS 2.0, el UN Transparency Protocol 0.7.0, PACT 3.0.3, ERC-3643 y el Ethereum Attestation Service no agregan ningún requisito; Interoperabilidad los resume.
Qué deja fuera
No hay una lista de cultivos, calidades ni certificaciones: los códigos son abiertos. No hay datos personales en la cadena: ni coordenadas de parcelas, ni nombres, ni identificadores de personas físicas, ni valores calculados a partir de la ubicación de una parcela. No se impone ningún proveedor de identidad, oráculo ni registro, ni ninguna política: quién puede aplicar medidas de cumplimiento, pausar o controlar sanciones, y contra qué listas, lo decide el emisor según su jurisdicción. Las curvas de deterioro, los flujos de entrega, la contabilidad de carbono y los seguros se construyen como reglas o contratos complementarios. La implementación de referencia muestra algunos, pero la conformidad no depende de ellos.
Versiones
Las interfaces tienen la misma versión que el estándar. Cualquier cambio en una función, un evento o un requisito implica una versión mayor e incluye una nota de migración. Los agregados opcionales, como nuevos códigos recomendados o campos de metadatos, implican una versión menor: el esquema de metadatos 1.1.0 abrió el esquema de códigos de producto, y el esquema 1.2.0 agregó referencias a lotes de otros tokens (upstream). Todo documento válido según un esquema anterior sigue siendo válido. Hasta el envío, las interfaces todavía pueden cambiar, pero siempre en una versión mayor.
Camino a un ERC
El texto se enviará a ethereum/ERCs cuando se cumplan cuatro condiciones: un despliegue en producción con lotes reales que lleve seis meses en funcionamiento; al menos tres contratos de reglas independientes; una auditoría externa publicada de la implementación de referencia; y un ciclo de versiones completo sin cambios en las interfaces. La hoja de ruta está en Desarrollos futuros.
Qué no publica este sitio
Mientras el repositorio del estándar sea privado, ahí quedan las cláusulas normativas, el código fuente de las interfaces y sus identificadores, los códigos de rechazo y el esquema de metadatos del lote. Si tu empresa quiere implementar A-REX, emitir lotes con él o auditarlo, solicita acceso de lectura en Solicitar acceso anticipado. Revisamos cada solicitud a mano. Si te aprueban, recibes acceso de solo lectura al estándar y a la implementación de referencia. El material es confidencial hasta su publicación bajo CC0, y el acceso anticipado no otorga exclusividad.