Diagramas · 05

Papéis e limites de confiança

Quem pode fazer o quê no token de referência, onde fica o limite de confiança com os hooks e a custódia recomendada de cada chave. A autoridade nunca deriva de saldos.

Atores e suas capacidades

flowchart LR
    subgraph GOV["Multisig de governança + timelock"]
        ADMIN[DEFAULT_ADMIN_ROLE]
        UPG[UPGRADER_ROLE]
        HADM[HOOK_ADMIN_ROLE]
    end
    subgraph ENF["Multisig de enforcement (conformidade + jurídico)"]
        ENFR[ENFORCER_ROLE]
    end
    subgraph OPS["Serviços operacionais, privilégio mínimo"]
        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: processamento| T
    PAU -->|pause / unpause| T
    HOLD["Titular / operador aprovado"] -->|transferência · queima · reagrupamento| T
    T -->|check · onExecuted · canSend · canReceive| HOOKS[Hooks]
    HOOKS -.->|não podem reentrar, não podem mover saldos| T

O limite de confiança dos hooks

Um hook pode	Um hook não pode
rejeitar uma operação com um código	alterar qualquer saldo
observar uma operação executada	reentrar no token (trava)
responder a `canSend` / `canReceive`	alterar suas próprias flags em cache sem novo registro
ler o lote por meio de `IARexBatch(msg.sender)`	ser registrado como EOA ou sem suporte a ERC-165

Mitigações para um hook malicioso ou defeituoso: HOOK_ADMIN_ROLE o remove (ordem preservada); PAUSER_ROLE interrompe tudo, exceto as transferências forçadas; um timelock nas mudanças de hooks as torna visíveis antes de entrarem em vigor.