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

# Governance & Access Controls

No single individual or key can unilaterally move funds, modify vault parameters, or change system configuration. All sensitive operations are governed by a multisig quorum requirement: multiple independent parties must approve before any action is executed.

## Role separation

The system enforces a distinction between two types of access:

**Transaction signers** can initiate and co-sign transactions such as capital movements. Every transaction requires quorum approval from multiple signers before execution.

**Vault administrators** can propose changes to vault configuration, including user management, policy adjustments, and system parameters. These changes are also subject to admin quorum and cannot be made unilaterally. Admin privileges do not grant the ability to bypass quorum requirements.

Both roles operate under the governance policies enforced by the vault contract itself. The quorum threshold is set such that a supermajority of keyholders must agree on any action.

## Execution partner access

Execution partners operate within scoped permissions defined by the Elara Engine. They receive allocated capital and execute strategies within predefined risk parameters. They do not have admin access to the vault or the ability to modify system configuration.

## Key management

Signer and admin keys are distributed across independent parties. Specific details of the key distribution, signer identities, and quorum thresholds are maintained confidentially for operational security. The system is designed so that compromise of any single key is insufficient to take any privileged action.

## Timelocks

There is no protocol-wide timelock. Administrative actions execute immediately once quorum is met. The AccessManager delay mechanism is available but is currently set to zero and not enabled.

This is a deliberate position for a system at this stage, where the ability to respond quickly to a security event is worth more than the notice a delay provides. Enabling a delay is straightforward and we would expect to do so as the protocol grows, and we are open to discussing it as part of an integration.