Diagramme · 03

Transfer-Pipeline

Jede Saldenänderung im Referenz-Token läuft durch eine einzige Funktion. Die folgende Reihenfolge ist fest; transferCheck und canTransfer bilden sie als Views nach.

Ablauf eines Transfers mit zwei Hooks

sequenceDiagram
    autonumber
    participant U as Inhaber / Operator
    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: Sperre (Reentrancy) · nicht pausiert
    T->>E: canSend(from) / canReceive(to)
    E-->>T: true / true
    T->>T: Charge existiert · 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 (Salden, Gesamtmenge)
    T->>R: onExecuted(OP_TRANSFER, …)
    R-->>T: emittiert EPCIS-förmiges Ereignis
    T->>T: Sperre aufheben
    T-->>U: TransferSingle

Was bei einer Ablehnung geschieht

flowchart LR
    A["check liefert Code ≠ 0"] --> B["revert ARexHookRejected(hook, code)"]
    B --> C["kein Saldo geändert"]
    B --> D["kein TransferSingle emittiert"]
    B --> E["Frontend ordnet Code → Meldung zu<br/>z. B. keccak256('AREX:BATCH_EXPIRED')"]

Auswertungsreihenfolge und wer was überspringen kann

Schritt	Transfer durch Inhaber	`forcedTransfer` (ENFORCER_ROLE)	`transform`
Sperre	ja	ja	ja
Pause	blockiert	blockiert nicht	blockiert
`canSend` / `canReceive`	ja	übersprungen	ja (Eingaben von `from`, Ausgaben an `to`)
eingefrorener Saldo	durchgesetzt	gesenkt auf `balance − amount`	durchgesetzt
Hooks `check`	`OP_TRANSFER`	`OP_FORCED_TRANSFER`	`OP_TRANSFORM` für Eingaben und Ausgaben
Hooks `onExecuted`	ja	ja	ja