Diagramas · 03

Cadena de reglas de una transferencia

En el token de referencia, todo cambio de saldo pasa por una sola función. El orden de abajo es fijo; transferCheck y canTransfer lo repiten como vistas.

Secuencia de una transferencia con dos reglas externas (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 antirreentrada · no está 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 formato EPCIS
    T->>T: desbloqueo
    T-->>U: TransferSingle

Qué pasa ante un rechazo

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

Orden de evaluación y qué controles omite cada operación

Paso	Transferencia del titular	`forcedTransfer` (ENFORCER_ROLE)	`transform`
bloqueo	sí	sí	sí
pausa	bloquea	no bloquea	bloquea
`canSend` / `canReceive`	sí	se omite	sí (entradas desde `from`, salidas hacia `to`)
saldo congelado	se aplica	se reduce 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í