# AN01-F01 — contratos, implementación y límites

Fecha 2026-10-19. N1–N6 adoptadas; revisión de desarrollo, sin cierre G06-M/O.
La [propuesta original](https://xcim.org/standardization/anchor-adapter/CONTRACT-PROPOSAL.md) conserva la
comparación de alternativas. Esta revisión concreta formatos y ejecución local.

## 1. Contrato compilado

`ASCheckpointAnchor.sol` implementa exactamente las funciones, eventos y errores
del ABI N1. Constructor: G/T/I no cero, publisher/guardian distintos y no cero.
Una instancia para un issuer/log; sin proxy/setters/llamadas externas/delegatecall.
La EOA publisher escribe; guardian sólo detiene. No hay pagos ni tokens.

Head comienza en `(0,0)`. Exigir secuencia `head+1`, hasta `2^53-1`, C no cero y
previous_C igual al head. Guardar cada secuencia, actualizar head y emitir un
evento atómicamente. Un retry histórico exacto devuelve el mismo ID sin evento;
otra variante revierte. `halt` es irreversible e idempotente; bloquea incluso
retries de anchor y conserva getters. `checkpointAt` desconocido devuelve ceros.
La precedencia de errores es: publisher, halted, rango, C cero, conflicto/orden.
ABI inválido, value no cero y selector desconocido revierten sin error XCIM.
Solidity admite calldata extra conforme a sus reglas; el decoder de eventos
del receiver exige topics/data de longitudes exactas.

El contrato publica bytes32; no verifica JWS ni consentimiento. Un publisher
comprometido puede bloquear el log publicando hashes no válidos; la firma AS
sigue siendo un requisito separado. Rotar publisher/guardian exige nueva
instancia/log/genesis y bootstrap aceptado, sin reset unilateral de floors.

Compilación: solc-js `0.8.30+commit.73712a01.Emscripten.clang`, optimizer 200,
sin viaIR, target `paris`, metadata hash none/CBOR deshabilitado. Es una elección
de build local reproducible, **no certificación de soporte Amoy**. La
[interfaz Standard JSON oficial](https://docs.soliditylang.org/en/latest/using-the-compiler.html)
documenta estos parámetros. `compile.mjs` rechaza versión, diagnósticos o ABI
divergentes. SPDX UNLICENSED es un marcador de desarrollo: derechos/licencia de
distribución e IETF siguen pendientes. No usar este build sin revisión externa.

## 2. Compromisos y representaciones

Se mantienen G/C y las fórmulas D/I/T/anchor_id de N1. G/C/I/T y el compromiso
del binding se transportan como base64url canónico de 32 bytes sin padding.
Hashes de red/código/ABI/transacción son hex lowercase `0x`+64; direcciones son
hex lowercase `0x`+40. Hex y base64url no se vuelven a hashear como strings para
ABI: se decodifican a bytes32. C usa el payload JCS de C4, no su envelope JWS.

```text
B = SHA-256(UTF8("XCIM-AS-EVM-01-DEPLOYMENT-BINDING\0") || JCS(binding_payload))
ABIhash = SHA-256(JCS(ABI_array_N1))
creation_input = creation_code_template || abi.encode(G,T,I,publisher,guardian)
```

ABIhash usa el array N1 publicado, cuyos nombres/orden se preservan; el ABI del
compilador se contrasta por semántica (tipo/nombre de función/indexed/argumentos),
sin exigir nombres de outputs ni `internalType`. Source hash usa bytes UTF-8;
compiler_input_sha256 usa `JSON.stringify` compacto de la entrada Standard JSON
con su orden declarado. No es JCS. Ambos bytes están publicados para reproducir.

El hash del template de creación excluye argumentos de constructor; por tanto
no incluye T. El runtime final sí contiene inmutables: se reconstruye con las
referencias del compilador y se contrasta con ejecución EVM. ABI/template/receta
→ genesis e intent → T/args → creación → runtime/address/receipt → binding B.
G/T/I nunca incluyen B; C4 nunca contiene su propio receipt/bloque/anchor_id.

## 3. Schemas y firma raíz

Todos son JSON Schema 2020-12, cerrados salvo `$defs`/refs declarados, con IDs
offline `https://xcim.invalid/ietf/an01/schemas/`. Cadenas/arrays/bytes/enteros
están acotados; schema válido no prueba relaciones ni autoridad.

| Schema | Contrato |
|---|---|
| `intent` | Scope issuer/log/G/I, red/genesis, ABI/template/receta, publisher/guardian y finality policy. Sin dirección/tx/binding futuros. |
| `deployment-binding` | Intent T, scope/red, ubicación/creación/runtime, constructor, bootstrap, root-policy epoch y vigencia. |
| `signed-deployment-binding` | Envelope de quórum AS. Payload decodificado debe cumplir deployment-binding; no es JSON payload arbitrario aceptado. |
| `finality-policy` | Nodo Bor/Heimdall/pins, finalidad/ancestry/estado por hash exigidos; fallback latest/dos RPC prohibido; cotas 120/30/10. |
| `anchor-evidence` | T/B/C, secuencia/ubicación/índices, topics/data exactos, policy y referencia de vista finalizada. No acepta `confirmed`/flags de autoridad. |
| `receiver-policy` | Nueva envoltura C1: política AS01 explícita + intent/B/address y política de finalidad aceptados localmente. |
| `evidence-set` | Nueva envoltura C7: evidencia AS01 intacta con null + intent, binding firmado y evidencia de anchor aparte. |
| `common` | Hashes/hex/address/enteros acotados y envelope de quórum reutilizado. |

Binding JWS: `alg=Ed25519`, `typ=application/xcim-as-anchor-binding+jcs`, kid
exacto bajo el quórum root de la política local y su epoch. Payload/protected
JCS canónico, base64url sin padding, firmantes de thumbprints distintos y claves
vigentes al emitir y usar; siguen las reglas AS de quórum. Typ provisional sin
registro IANA. Discovery/email no provisiona roots ni pins. No aceptar el primer
binding firmado por claves incluidas en ese mismo mensaje como bootstrap.

El checker de fixture valida también C2/C3/C4 y permiso con AS01, luego relaciones
intent/B/constructor/código/evento/estado. La envoltura nueva es explícita y no
se pasa como C7 F01 ni habilita el Proof P1. Runtime de receiver/SMTP, lifecycle
de bindings/root-policy y persistencia todavía requieren implementación.

## 4. Vista de nodo y frescura

`anchor-evidence.finalized_view_reference` sólo identifica un bloque. El esquema
no contiene una proof portable de consenso. En operación el receiver debe
autenticar su nodo, bootstrap, sync, finalized header, ancestry y receipt/estado
bajo ese hash; [EIP-1898](https://eips.ethereum.org/EIPS/eip-1898) describe consultas
por hash/canonicalidad. El JSON del issuer no es esa fuente de autoridad.

`an01.verify_fixture` acepta sólo contexto TEST ONLY y vistas sintéticas con
`consensus_verified=false`. Su resultado siempre es
`AN01_LOCAL_ARTIFACT_FIXTURE_OK`, también con consenso/PASS false. Los campos
synced/canonical/receipt del fixture son oráculos del test, **no verificaciones
de red ni flags utilizables como autoridad en un receiver**. No existe ruta
productiva que los convierta en PASS.

La batería compara B canónico bajo F, código/getters en el mismo F, provenance de
deploy, head actual, halt, floors y deadlines. El deadline de artefacto es mínimo
de AS, binding, claves raíz usadas y timestamp F+120; el presupuesto local de
caché se devuelve separado en segundos, jamás como timestamp del issuer. Reuso
o SMTP deben comprobar ambas cotas con relojes adecuados. No instalar floors ni
dejar que una descarga tardía extienda los 300s. Contradicciones finalizadas
exigen cuarentena; floors durables, ancestry real y el nodo están pendientes.

## 5. Resultados y cobertura

34 casos/46 pasos EVM ejecutan bytecode local y verifican eventos, return values,
head/historia, getters, inmutables y no mutación observable al revertir/reintentar.
Dos checks adicionales prueban separación por dirección y chain ID local.
Se contrasta la reconstrucción de runtime con el código desplegado en PyEVM.
El checker de artefactos prueba firmas/relaciones contra vistas sintéticas;
sus casos positivos no acreditan una transacción Amoy ni un receipt auténtico.

Los casos AN-T01–AN-T20 originales mezclan contrato, receiver, red y operación.
Se [mapean explícitamente](https://xcim.org/standardization/an01/DEPENDENCIES.md): cubrir una parte local no los vuelve
escenarios end-to-end ejecutados. G06-M/O, revisión externa e interop siguen abiertos.