> For the complete documentation index, see [llms.txt](https://docs.btcd.fi/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.btcd.fi/how-the-engine-works/controls-and-governance.md).

# Controls and Governance

Engine policy, deployed admin powers and the specific scope of the oracle timelock.

## Engine policy

The documented engine design makes at most one move per part per cycle, waits for pending transactions/transfers, simulates DeFi transactions, applies slippage limits and strategy caps, and prioritizes LTV repairs. Operators have engine-wide pause, per-strategy freeze and cross-chain stop switches.

Its signed-proposal process and stored proposal references are off-chain mechanisms. They must be distinguished from the deployed contract permissions below.

## On-chain controls

Configuration observations below are from 2 November 2026, blocks 26,327,909 and 26,328,057.

| Contract or component                         | Admin powers                                                                                            | Contract execution delay observed              |
| --------------------------------------------- | ------------------------------------------------------------------------------------------------------- | ---------------------------------------------- |
| BTCD token and MintingProxy                   | Set minting addresses and authorized minting backends                                                   | No delay                                       |
| VaultMinting                                  | Fees, per-block limits, pause, recipients and selected price feeds                                      | No delay                                       |
| RFQ minting                                   | Asset and role configuration, limits and pause controls                                                 | No delay                                       |
| sBTCD and YieldDistributor                    | Cooldown, vesting, role grants, staking addresses and distribution rates, as permitted by each contract | No delay                                       |
| wsBTCD                                        | Mint whitelist configuration and surplus recovery                                                       | No delay                                       |
| Root BTCD oracle                              | Bind or unbind the reserve reporter                                                                     | 48-hour minimum timelock                       |
| bdUSD and BTCdc role-controlled configuration | Strategy fuses, market settings, supply caps, price sources and fees under the respective IPOR roles    | Checked role/member execution delays were zero |
| Current FISC token                            | Fixed-supply token; no on-chain voting or admin role in the token itself                                | Not applicable                                 |

The reporter was unbound at the observation. The timelock governs that root-oracle link; its own delay changes must also pass through the timelock. Other contracts can have separately changeable oracle settings, so the reporter delay is not an end-to-end delay for every price-source change.

## Fixed code and configurable dependencies

The November 2 review identified no implementation upgrade path in the checked BTCD token, staking, wrapper, minting, distributor, root-oracle and timelock contracts. The two IPOR vaults use fixed EIP-1167 minimal-proxy implementations. A fixed implementation does not freeze configurable strategy fuses, market permissions or price sources.

External IPOR middleware and third-party wrappers have separate deployment and upgrade controls. Their controls cannot be inferred from the two vaults' fixed implementation addresses.

## Signing and custody

The checked admin addresses are externally owned accounts, rather than Safe contracts. That identifies how transactions appear on-chain; it does not identify the number of human approvers or an off-chain MPC/custody quorum. Those policies require separate operational evidence.

## FISC governance design

FISC is intended to govern protocol parameters and the fee switch. No on-chain FISC holder vote was identified in the reviewed deployments; existing contract settings are changed by their assigned admins. The governance mechanism and activation plan remain separate from current token functionality. See [FISC](/tokens/fisc.md).

The documented engine strategy policy permits the Risk Committee to tighten limits and uses signed proposals for loosening. See [Choosing DeFi strategies](/how-the-engine-works/choosing-defi-strategies.md).