Appearance
Governance & security: who can do what
HAM is a strongly owner-centric system. Most of the risk is not in permissionless attack surface — it's in what the privileged keys can do. Being honest about that is the point of this page. For the exact role-by-role function list, see the contracts reference.
The roles
| Role | Held by (at launch) | Can do | Cannot do |
|---|---|---|---|
| HAM owner | governance multisig | UUPS-upgrade the token; set the rebaser and incentivizer | — (an upgrade can do anything, see below) |
| Rebaser owner | governance multisig | set every policy parameter, the treasury address, the keeper allowlist; call forceRebase | move the immutable $1 peg or peg mode; null the USD oracles |
| Keeper | a bot key (allowlisted) | drive commitRebase / revealAndRebase within the window | steal funds; choose a favorable price (commit/reveal + drift bound prevent it) |
| Treasury | governance multisig | hold/recycle protocol WHYPE + HAM | mint, rebase, or upgrade |
The capability that matters most: UUPS upgrade
The HAM owner can replace the entire token implementation with no timelock. An upgrade can rewrite balances or brick the token. This is the most powerful capability in the system, so the only acceptable owner for it is a properly-configured governance multisig — not an EOA. Before launch, confirm the multisig's signer set and threshold; after launch, treat any upgrade as a governance event.
Keepers can't cheat
Keepers are operational, not trusted with value. A rebase is a two-step commit/reveal 25 blocks apart: the commit binds the slippage floor (so the keeper can't choose minReserveOut after seeing reserves) and, in USD mode, snapshots the oracle price (so the keeper can't wait for a favorable print — the reveal reverts on >2% drift (default; owner-tunable 0.5%–10%)). forceRebase skips commit/reveal and is therefore owner-only, not keeper-callable — a keeper-callable force path could be sandwiched.
Oracle rotation is timelocked
In USD mode the owner can rotate the reserve/USD feeds but cannot unset them, and any rotation takes effect only 24h after it's proposed (ORACLE_ROTATION_DELAY). That window lets observers react to a hostile or fat-fingered rotation. The trade-off is the liveness risk: a dead feed can't be fixed faster than the timelock.
Two-step ownership, and the launch hand-off
HAM and the rebaser use two-step ownership (Ownable2Step): a transfer only proposes the new owner; the multisig must then call acceptOwnership(). Until it does, the previous owner still has full power — this is the most common hand-off mistake.
At launch the protocol is deployed from a hot EOA, then de-privileged: operational roles (keeper, reward-notifier) are moved off the EOA, ownership of all contracts is transferred to the multisig and accepted, and a verification step asserts the EOA retains zero residual power (it can no longer rug, upgrade, retune, mint, rebase, or notify). The full procedure is covered by the operator runbooks in the protocol repository.
Risks to hold in view
- Upgrade power, no timelock — mitigated only by the multisig being trustworthy.
- Parameter latitude — the owner can retune rebase policy within hard caps (it cannot move the $1 peg, the peg mode, or break the oracle requirements).
- Oracle liveness — a dead primary feed halts all rebases until a timelocked rotation completes.
- Treasury-held liquidity — flexible, but the multisig can move it; this is a trust assumption, not a trustless guarantee.