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.
Versiones
El estándar y su implementación de referencia tienen números de versión distintos. Un nombre como "alpha.10", sin más, es una versión de la implementación de referencia, no del estándar.
| Qué | Versión | Qué es |
|---|---|---|
| Estándar (A-REX Core) | 2.1.0-alpha.2 | La especificación y sus interfaces. El texto propuesto después de esta versión se marca como Propuesto y no forma parte de ella. |
| Esquema de metadatos del lote | 1.2.0 publicado, 1.4.0 Propuesto | El documento del lote fuera de la cadena que el token compromete. |
| Implementación de referencia | 2.0.0-alpha.10 | Los contratos MIT que implementan el estándar 2.1.0-alpha.2. |
| Suite de conformidad | 1.1.0 | Las pruebas, cláusula por cláusula, que ejecuta cualquier implementación; se distribuye con la implementación de referencia. |
Los números cuentan cosas distintas: el estándar cuenta los cambios de la especificación y la implementación cuenta sus propias versiones. Ambos empezaron en 2.0.0; la versión 2.1 del estándar no cambió ninguna interfaz, evento ni requisito, así que una implementación 2.0 lo implementa.
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 89 cláusulas, 75 de nivel MUST y 14 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; según la misma regla, volver a atestar nunca reemplaza el registro de otro emisor ni reactiva uno revocado. |
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-024 (Propuesto): lugares como códigos ISO | Desde el esquema de metadatos 1.3.0, origin.region es un código de subdivisión ISO 3166-2 como BR-MG (el código ISO 3166-1 del país cuando no corresponde ninguna), verificado por patrón; un nombre para las personas va en el campo opcional origin.regionName. Los documentos de versiones anteriores siguen siendo válidos. |
| ADR-025 (Propuesto): hooks vinculados a un solo token | Un hook puede quedar vinculado a un solo token al desplegarse, si hace público ese token y rechaza con un error con nombre toda llamada de otra dirección; los hooks no vinculados siguen sirviendo al token que los llame. El hook de trazabilidad de referencia está vinculado. |
| 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. |
| ADR-023 (Propuesto): varios valores en los datos de una transferencia | Los data de una transferencia pueden ser un sobre etiquetado de hasta 8 entradas, cada una con una clave y un valor, para que cada regla lea solo su propia clave; los datos de 32 bytes conservan su significado anterior. No agrega ningún requisito. |
| ADR-026 (Propuesto): redes | A-REX Core sigue siendo un estándar EVM: cualquier red EVM de nivel paris o posterior puede alojar un token conforme, las redes se nombran con ids CAIP-2 y el estándar no mantiene ninguna lista de ellas; la evidencia que rodea a un token puede anclarse en cualquier red. |
| Esquema de metadatos 1.4.0 (Propuesto) | Una entrada de upstream puede indicar la network CAIP-2 del lote que nombra; un lote en una red que no es EVM se nombra por su activo CAIP-19. |
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. |
Formatos arex.vocab/1, arex.anchor-proof/1 y arex.report-sources/1 (informativos, Propuestos) | El vocabulario propio de una organización para el trabajo de campo, los procesos y las etapas; pruebas de que un registro existía sin cambios, ancladas en cualquier red; las fuentes de las cifras de un informe, una línea por registro. |
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). Los esquemas de metadatos 1.3.0 y 1.4.0 están Propuestos y no publicados. 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.