Diagramas · 05

Roles y límites de confianza

Quién puede hacer qué con el token de referencia, dónde está el límite de confianza con las reglas externas (hooks) y cómo se recomienda custodiar cada clave. La autoridad nunca proviene 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 controles de cumplimiento (cumplimiento + legal)"]
        ENFR[ENFORCER_ROLE]
    end
    subgraph OPS["Servicios operativos con privilegio 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: 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	cambiar ningún saldo
observar una operación ejecutada	reentrar en el token (bloqueo)
responder a `canSend` / `canReceive`	cambiar sus propios indicadores en caché sin volver a registrarse
leer el lote a través de `IARexBatch(msg.sender)`	registrarse si es una EOA o si no implementa ERC-165

Si un hook es malicioso o falla: HOOK_ADMIN_ROLE lo quita (el orden de los demás se mantiene); PAUSER_ROLE detiene todo, salvo las transferencias forzosas; y un timelock sobre los cambios de hooks los hace visibles antes de que entren en vigor.