Skip to content
DocsConceptsNavigators

Navigators — Permissioned Extensions

A bare governance system can do exactly one thing: pass proposals. Navigators are the modules that give a ship extra crew roles — onboarding new members, accepting tribute, automating routine work — without bloating the core contract. If you've heard of Moloch-style "shamans," Navigators are the DAO Ships equivalent, renamed and hardened.

The one-sentence version

A Navigator is a trusted, immutable contract granted a specific bundle of permissions, letting it perform a narrow job — like minting Shares to new members — without a vote for every action.

The permission model — a three-bit bitmask

Every Navigator is granted permissions as an additive bitmask of three roles. Each role unlocks a specific set of actions:

BitRoleValueCan do
0ADMIN1Pause / unpause Share and Loot transfers
1MANAGER2Mint and burn Shares and Loot
2GOVERNOR4Change governance config, cancel proposals

Because the values are powers of two, they add up to describe combined roles:

  • 3 = ADMIN + MANAGER
  • 6 = MANAGER + GOVERNOR
  • 7 = full access (all three)

The maximum valid value is 7; anything higher is rejected. Granting or changing a Navigator's permissions is a governance-only action — it always requires a passed proposal, never a single party's say-so.

Not every navigator takes a permission

The bitmask above covers permissioned navigators — the ones that mint, pause, or change config. But two of the shipped navigators sit outside it entirely, and how a navigator is endorsed depends on which of three classes it belongs to:

ClassAuthority comes fromEndorsed by
PermissionedA DAOShip permission bit (above)A governance setNavigators proposal
Read-onlyNothing — it never mutates the DAOThe DAO posting that it endorses it
ModuleQuai Vault module status (Zodiac)Governance enabling it on the vault

A read-only navigator (the Signal poll engine) only reads voting power, so it needs no permission — instead a DAO vouches for it with a vault post. A module navigator (the Budget disburser) spends the treasury, so it's enabled on the vault like any other module, not granted a DAOShip role. Until a read-only or module navigator is endorsed, the app treats it as unverified and hides its data. The Navigators overview covers this in full.

The navigator catalog

Eight navigators ship today, all audited and supported end-to-end. Each has its own reference page:

NavigatorClass · PermissionWhat it does
OnboarderPermissioned · MANAGERNative QUAI tribute → Shares / Loot
ERC-20 TributePermissioned · MANAGERERC-20 tribute → Shares / Loot, with permit
NFT-GatePermissioned · MANAGERERC-721 holders claim membership (one claim per token)
SignalRead-only · noneNon-binding, share-weighted polls
TimelockPermissioned · GOVERNORA mandatory delay on governance-config changes
VestingPermissioned · MANAGERCliff + linear vesting of Shares or Loot
BudgetModule · vaultRecurring treasury disbursement, no per-payment votes
SubscriptionPermissioned · MANAGERRecurring dues with keeper collection

More are designed but not yet shipped (Delegate Registry, Circuit Breaker, Oracle, ERC-1155 Gate) — see the overview.

The trust model — read this carefully

Navigators are powerful by design, and that power rests on a clear assumption.

A MANAGER navigator can mint without limit

The MANAGER role grants unrestricted ability to mint Shares to any address. A malicious MANAGER could mint itself enough Shares to pass a proposal granting itself full control. The architecture assumes MANAGER navigators are immutable, audited contracts whose minting is bounded by a cap, an allowlist, or an expiry — never an EOA or an upgradeable proxy.

When evaluating any Navigator before granting it MANAGER, confirm it has at least one hard bound:

  • A mint cap that limits total issuance,
  • An allowlist restricting who can trigger minting,
  • An expiry after which minting stops, or
  • Bounded per-call minting (a fixed amount per unit of tribute).

Every shipped MANAGER navigator meets this bar when configured correctly. An EOA with MANAGER, or a proxy the deployer can rewrite, never does.

Locks — freezing the roster

Governance can permanently lock a role with lockAdmin, lockManager, or lockGovernor. A lock means no new Navigators can be granted that role. Locks are one-way — there is no unlock. Two important nuances:

  • Locking does not revoke existing Navigators; governance can still strip a compromised one.
  • Governance proposals can still call the locked functions directly, so the DAO never loses the ability to act through a vote.

Why "Navigators" and not "shamans"?

DAO Ships is inspired by Moloch v3, which called these modules "shamans." DAO Ships rewrote them from scratch with a standard INavigator interface (each carries an on-chain identity, type, and metadata event), richer safety features, and the nautical naming that runs through the whole framework. A Navigator charts a specific course; the crew still decides whether to grant it the helm.