> For the complete documentation index, see [llms.txt](https://docs.brila.finance/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.brila.finance/brila-dat/explanation/governance-and-security.md).

# Governance and security

DAT 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](/brila-dat/reference/contracts.md).

> **Current ownership status.** The token, rebaser, and incentivizer are owned by the **deployer EOA** (`0x2f8771…`), not a governance multisig. The token and rebaser have no pending owner. See [networks & addresses](/brila-dat/reference/addresses.md). The intended hand-off has not completed.

## The roles

| Role                        | Current holder         | Capabilities                                                                                                       |
| --------------------------- | ---------------------- | ------------------------------------------------------------------------------------------------------------------ |
| **DAT owner**               | deployer EOA           | UUPS-upgrade the token; set `rebaser` and `incentivizer`; initiate two-step ownership transfer.                    |
| **Rebaser owner**           | deployer EOA           | Set keepers, treasury, timing and policy parameters; rotate USD feeds after 24h; call `forceRebase`.               |
| **Incentivizer owner**      | deployer EOA           | Set `rewardDistribution`; recover unrelated tokens; transfer ownership in one step.                                |
| **Reward distributor**      | deployer EOA           | Call `notifyRewardAmount`; it cannot directly withdraw staked LP or DAT rewards.                                   |
| **Keeper**                  | allowlisted bot key(s) | Commit and reveal rebases inside the configured window.                                                            |
| **Rebase treasury**         | 2-of-3 Safe            | Receive and move treasury DAT/WHYPE; approve DAT spending by the rebaser. It has no admin power unless made owner. |
| **Zap and oracle adapters** | no owner               | Immutable contracts; no admin or recovery functions.                                                               |

In USD mode, the rebaser owner cannot change the peg mode, change the `$1.00` target, or unset the two reserve/USD feeds. A UUPS token upgrade remains capable of changing token behavior without those rebaser-level restrictions.

## The capability that matters most: UUPS upgrade

The DAT owner can replace the token implementation **with no timelock**. An upgrade can change balances, minting, transfers, or authorization. This is the most powerful capability in the system. The current owner is an EOA; moving it to a properly configured multisig is an outstanding trust reduction.

## What commit/reveal does—and does not—protect

A rebase is a two-step **commit/reveal** flow. Reveal is allowed 25–50 blocks after commit. The commit binds the keeper, salt, and `minReserveOut`, so that floor cannot be changed after observing later reserves. In USD mode, commit also snapshots the primary reserve/USD price; reveal reverts when drift exceeds 2% by default.

This limits keeper discretion but does not make a keeper trustless. A compromised keeper can commit an intentionally weak `minReserveOut`, exposing the treasury swap to poor execution or a sandwich. It cannot redirect proceeds: reserve output always goes to `treasuryAddress`. `forceRebase` bypasses commit/reveal and is owner-only, but still enforces activation, window, interval, TWAP, and oracle checks.

## 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](/brila-dat/explanation/the-peg.md#the-liveness-trade-off-read-this): a dead feed can't be fixed faster than the timelock.

## Two-step ownership, and the launch hand-off

DAT and the rebaser use **two-step ownership** (`Ownable2Step`): transfer sets `pendingOwner`, and the recipient must call `acceptOwnership()`. Until acceptance, the old owner remains fully privileged. The incentivizer uses single-step `Ownable`; its transfer takes effect immediately.

The intended hand-off must also separate operational roles: owner, keeper, and reward distributor are independent permissions. The operator runbooks in the repository cover the transfer and verification procedure; the current deployment has not completed it.

## Risks to hold in view

* **Upgrade power, no timelock** — mitigated only by the multisig being trustworthy.
* **Current EOA ownership** — compromise controls upgrades and all owner-set policy.
* **Parameter latitude** — the rebaser owner can retune policy within hard caps, change the treasury, and change keepers.
* **Oracle liveness** — failure of either mandatory USD feed halts rebases until a timelocked rotation completes.
* **Keeper execution quality** — commit/reveal binds a floor but does not enforce that the chosen floor is economically safe.
* **Treasury custody** — the Safe controls received DAT and WHYPE; token holders have no direct claim on those assets.