Diagrams · 05

Roles and trust boundaries

Who can do what to the reference token, where the trust boundary with hooks lies, and the recommended custody of each key. Authority never derives from balances.

Actors and their capabilities

flowchart LR
    subgraph GOV["Governance multisig + timelock"]
        ADMIN[DEFAULT_ADMIN_ROLE]
        UPG[UPGRADER_ROLE]
        HADM[HOOK_ADMIN_ROLE]
    end
    subgraph ENF["Enforcement multisig (compliance + legal)"]
        ENFR[ENFORCER_ROLE]
    end
    subgraph OPS["Operational services, least privilege"]
        ISS[ISSUER_ROLE]
        STA[STATUS_ROLE]
        TRA[TRANSFORMER_ROLE]
        PAU[PAUSER_ROLE]
    end
    T[(ARexToken)]
    UPG -->|upgradeTo| T
    HADM -->|registerHook / removeHook| T
    ENFR -->|setFrozenTokens / forcedTransfer| T
    ISS -->|createBatch| T
    STA -->|setBatchStatus / setBatchMetadata| T
    TRA -->|transform: processing| T
    PAU -->|pause / unpause| T
    HOLD[Holder / approved operator] -->|transfer · burn · re-batch| T
    T -->|check · onExecuted · canSend · canReceive| HOOKS[Hooks]
    HOOKS -.->|cannot re-enter, cannot move balances| T

The hook trust boundary

A hook can	A hook cannot
reject an operation with a code	change any balance
observe an executed operation	re-enter the token (lock)
answer `canSend` / `canReceive`	change its own cached flags without re-registration
read the batch through `IARexBatch(msg.sender)`	be registered as an EOA or without ERC-165 support

Mitigations for a malicious or broken hook: HOOK_ADMIN_ROLE removes it (order preserved); PAUSER_ROLE halts everything except forced transfers; a timelock on hook changes makes them visible before they take effect.