Diagrammes · 03

Pipeline de transfert

Toute modification de solde dans le jeton de référence passe par une seule fonction. L'ordre ci-dessous est fixe ; transferCheck et canTransfer le rejouent sous forme de vues.

Séquence d'un transfert avec deux hooks

sequenceDiagram
    autonumber
    participant U as Détenteur / opérateur
    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: verrou (réentrance) · non en pause
    T->>E: canSend(from) / canReceive(to)
    E-->>T: true / true
    T->>T: le lot 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 (soldes, offre)
    T->>R: onExecuted(OP_TRANSFER, …)
    R-->>T: émet un événement calqué sur EPCIS
    T->>T: déverrouillage
    T-->>U: TransferSingle

Ce qui se passe en cas de rejet

flowchart LR
    A["check renvoie un code ≠ 0"] --> B["revert ARexHookRejected(hook, code)"]
    B --> C["aucun solde modifié"]
    B --> D["aucun TransferSingle émis"]
    B --> E["le front-end associe le code à un message<br/>par ex. keccak256('AREX:BATCH_EXPIRED')"]

Ordre d'évaluation et qui peut contourner quoi

Étape	Transfert par un détenteur	`forcedTransfer` (ENFORCER_ROLE)	`transform`
verrou	oui	oui	oui
pause	bloque	ne bloque pas	bloque
`canSend` / `canReceive`	oui	ignoré	oui (entrées depuis `from`, sorties vers `to`)
solde gelé	appliqué	abaissé à `balance − amount`	appliqué
hooks `check`	`OP_TRANSFER`	`OP_FORCED_TRANSFER`	`OP_TRANSFORM` pour les entrées et les sorties
hooks `onExecuted`	oui	oui	oui