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 [e-mail] (also listed in security.txt). Reports receive coordinated-disclosure handling. A public bug bounty program is planned.