Diagramas · 03

Canalización de transferencia

Todo cambio de saldo en el token de referencia pasa por una única función. El orden siguiente es fijo; transferCheck y canTransfer lo reproducen como vistas.

Secuencia de una transferencia con dos hooks

sequenceDiagram
    autonumber
    participant U as Titular / operador
    participant T as ARexToken._update
    participant E as EligibilityHook (CHECK, ELIGIBILITY)
    participant X as ExpiryHook (CHECK)
    participant R as TraceabilityHook (EXECUTED)
    U->>T: safeTransferFrom(from, to, id, amount, data)
    T->>T: bloqueo (reentrada) · no en pausa
    T->>E: canSend(from) / canReceive(to)
    E-->>T: true / true
    T->>T: el lote existe · status != RETIRED · amount ≤ balance − frozen
    T->>E: check(OP_TRANSFER, operator, from, to, id, amount, data)
    E-->>T: OK
    T->>X: check(OP_TRANSFER, …)
    X-->>T: OK
    T->>T: super._update (saldos, suministro)
    T->>R: onExecuted(OP_TRANSFER, …)
    R-->>T: emite un evento con forma de EPCIS
    T->>T: desbloqueo
    T-->>U: TransferSingle

Qué ocurre en caso de rechazo

flowchart LR
    A["check devuelve un código ≠ 0"] --> B["revert ARexHookRejected(hook, code)"]
    B --> C["no cambia ningún saldo"]
    B --> D["no se emite TransferSingle"]
    B --> E["el front-end asigna código → mensaje<br/>p. ej. keccak256('AREX:BATCH_EXPIRED')"]

Orden de evaluación y quién puede omitir qué

Paso	Transferencia del titular	`forcedTransfer` (ENFORCER_ROLE)	`transform`
bloqueo	sí	sí	sí
pausa	bloquea	no bloquea	bloquea
`canSend` / `canReceive`	sí	omitido	sí (entradas desde `from`, salidas hacia `to`)
saldo congelado	se aplica	reducido a `balance − amount`	se aplica
`check` de los hooks	`OP_TRANSFER`	`OP_FORCED_TRANSFER`	`OP_TRANSFORM` para entradas y salidas
`onExecuted` de los hooks	sí	sí	sí