> For the complete documentation index, see [llms.txt](https://docs.nara.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.nara.io/nara-protocol/roles-multisig-and-timelocks.md). # Roles, Multisig and Timelocks **There are no singly-controlled privileged keys in the Nara protocol.** Every function that can move value or change behaviour is owned by a multisignature wallet with an on-chain 3-of-5 threshold: five hardware-backed signers, any three of whom must sign for a transaction to exist. The one deliberate exception is the pauser role, which can only ever stop the protocol. This page sets out what each privileged surface can do, how the keys are held, what the timelock gates, and what happens when something fails. ### What is privileged | Surface | What the keys control | Contract-enforced check on top of the 3-of-5 | | ---------------------------------------- | ---------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Token administration (NaraUSD, NaraUSD+) | Issuance gating, pause configuration and un-pause, parameter changes, upgrade admin | KYC gating: only screened, authorized addresses can mint or redeem at the primary market. Per-block mint and redeem limits | | Vault management (NaraUSD+ vault) | Configuration, allocation mandates, asset-manager permissions for capital deployment | Allowlist verification: the manager module proves every operation against pre-approved targets and function calls. Out-of-mandate deployments do not get flagged; they revert | | Reward issuance | The admin flow that writes verified NAV into the exchange rate and mints rewards | Unbacked-mint cap: an oversized reward mint reverts regardless of signatures | | Mint-cap update | Raising or lowering the cap | Hard-coded 2-day timelock. The delay itself is immutable on-chain; a pending change is public and can be vetoed at any time before execution | | Treasury | Protocol funds, reserve movements, operating capital, the Insurance Fund wallet | Whitelisted destinations; segregated wallets | | Cross-chain configuration | LayerZero endpoints, peers and security parameters governing burn-and-mint across chains | 3-of-5 threshold | | Signer-set changes | Adding, removing or replacing signers | 3-of-5 threshold, deliberately with no delay, so a compromised key can be removed immediately | | Pause | Halting state-changing activity | Single trigger, held outside the multisig. It can stop the protocol; it cannot move funds, change parameters or bypass a threshold. Resuming requires the full 3-of-5 process | Because the threshold lives in the contract, a transaction below threshold is invalid and the chain rejects it. This is not a policy that can be bypassed under pressure. ### How the keys are held * **Hardware only.** Every signing key is generated on, and never leaves, a dedicated hardware device. No software keys, no exports, no internet-connected keystore. * **Physical confirmation.** Each signature requires on-device confirmation of the transaction contents. A compromised laptop cannot sign silently. * **Geographic distribution.** Signers and devices are distributed; no location holds enough keys to reach threshold. * **No hot admin keys.** Automated systems observe and alert. Only hardware-held keys act. * **Screened signers.** Signing authority is vetted before onboarding. Onboarding and removal are themselves 3-of-5 actions. ### One process for everything Every action behind the multisig, from a parameter change to a contract upgrade, follows the same three stages on a live signing call: 1. **Maker** prepares the transaction. 2. **Reviewer** independently verifies it. 3. **Executor** performs a second independent review and submits the executing signature. The three stages are three of the five signers, satisfying the threshold. Before signing, participants verify one another with personal challenge questions that no external party could answer, a countermeasure against AI-generated voice and video. A request that arrives outside a live ceremony is not signed. There is no fast lane for routine actions and no special ceremony for large ones; the discipline is identical everywhere, which means it is practiced everywhere. Holding five signers against a three-signature threshold is also an availability control: with one or two signers unavailable, the protocol can still act without lowering the bar. ### What the 2-day timelock gates Reward issuance is bounded by an on-chain unbacked-mint cap. The cap can be changed, but every change sits in a 2-day timelock that is hard-coded on-chain: no signer set, including all five, can shorten it. Throughout the window the pending change is publicly visible and carries veto rights. A compromised signer set could therefore neither over-mint today nor quietly raise the ceiling for tomorrow. Expanding what the protocol can do is slow and public; defending it, through the pause and the removal of a compromised signer, is immediate. ### Failure and recovery | Scenario | Outcome | | --------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------- | | A single signer is compromised | Nothing is reachable with one key, and a stolen key cannot join a live signing ceremony. The signer is removed immediately by a 3-of-5 action | | A signer's device is lost or destroyed | The threshold tolerates up to two unavailable signers with no loss of capability; the set is restored through the governed replacement process | | An oversized reward mint is attempted | The unbacked-mint cap reverts it regardless of signatures. Error and compromise fail identically | | A malicious mint-cap increase is queued | It cannot take effect for 2 days, is publicly visible for the whole window, and is vetoed before execution | | Active incident in a core contract | Pause halts state changes immediately. Assessment and remediation proceed under the standard three-stage process, and disclosure follows | ### Check it yourself Every administrative transaction executes from the known 3-of-5 multisig addresses and is permanently attributable on-chain. The multisig threshold and signer set, the unbacked-mint cap, and any pending cap change are readable from the contracts. ### Responsible disclosure Security researchers can report vulnerabilities to (also listed in security.txt). Reports receive coordinated-disclosure handling. A public bug bounty program is planned. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.nara.io/nara-protocol/roles-multisig-and-timelocks.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.