Diagramas · 05

Roles y límites de confianza

Quién puede hacer qué con el token de referencia, dónde se sitúa el límite de confianza con los hooks y la custodia recomendada de cada clave. La autoridad nunca se deriva de los saldos.

Actores y sus capacidades

flowchart LR
    subgraph GOV["Multifirma de gobernanza + timelock"]
        ADMIN[DEFAULT_ADMIN_ROLE]
        UPG[UPGRADER_ROLE]
        HADM[HOOK_ADMIN_ROLE]
    end
    subgraph ENF["Multifirma de ejecución forzosa (cumplimiento + jurídico)"]
        ENFR[ENFORCER_ROLE]
    end
    subgraph OPS["Servicios operativos, privilegios mínimos"]
        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: procesamiento| T
    PAU -->|pause / unpause| T
    HOLD["Titular / operador aprobado"] -->|transfer · burn · reagrupación| T
    T -->|check · onExecuted · canSend · canReceive| HOOKS[Hooks]
    HOOKS -.->|no pueden reentrar ni mover saldos| T

El límite de confianza de los hooks

Un hook puede	Un hook no puede
rechazar una operación con un código	modificar ningún saldo
observar una operación ejecutada	reentrar en el token (bloqueo)
responder a `canSend` / `canReceive`	cambiar sus propios indicadores almacenados en caché sin volver a registrarse
leer el lote a través de `IARexBatch(msg.sender)`	registrarse como una EOA o sin soporte de ERC-165

Mitigaciones para un hook malicioso o defectuoso: HOOK_ADMIN_ROLE lo elimina (se conserva el orden); PAUSER_ROLE detiene todo salvo las transferencias forzosas; un timelock sobre los cambios de hooks los hace visibles antes de que surtan efecto.