Skip to main content
Business Accounts are in early access. See the overview for the model.
Governance defines approval requirements for Business Account actions: adding or removing a member, transferring ownership, changing signers, and linking or removing a wallet. A matching requirement prevents the action from applying until the initiator has signed the exact change and every matching requirement is satisfied. Governance does not cover wallet signing. A separate quorum policy governs whether a Business Account wallet can sign a transaction or message. See Quorum policies.

​
How approvals work

  1. A member initiates a governed action, such as adding a member or transferring ownership.
  2. The initiator signs an intent for the exact change. When the change cannot be constructed locally, such as adding a member by email before the server has resolved that identifier to a user, the server returns an intent for the initiator to sign instead.
  3. The signed change becomes a proposal once it still needs approvals.
  4. Each eligible approver signs one approval. The initiator cannot approve their own proposal, and each member can approve once.
  5. Once every requirement is satisfied, the proposal executes automatically when the account allows it, or an authorized member executes it explicitly.
An approver can also veto a proposal, which rejects it permanently, or withdraw an approval they already gave, which can drop a proposal back below its requirements. For the events fired at each stage, see Business account webhooks.

​
Requirements and roles

A governance requirement names how many approvals an action needs, who may give them, and how long the proposal has to complete. Omitting a role list falls back to the account’s default approvers, owner and admin. An empty role list does not mean anyone can approve: a requirement with no eligible approver is rejected as unsatisfiable. A requirement can also name which roles may initiate the action, replacing the action’s default capability. When several requirements on the same action each name initiator roles, the initiator must satisfy every one of them. One approver capability narrows eligibility further: it can require that an approver already be a signer on the wallet the change affects, rather than any member holding an eligible role. A requirement can also name a role that must be represented among the approvers, independent of which roles are otherwise eligible. This lets an account require, for example, that at least one approval come from a specific role even when other roles can also approve. Every requirement has a completion window: the time from the initiator’s signature until the proposal must be approved and, where applicable, executed. The default and maximum is 30 days. Approver and initiator roles can be a built-in role (owner, admin, viewer) or a custom role the account has defined.

​
Scoping a requirement

A requirement can apply to every instance of an action, or be scoped to matching changes only, for example a requirement that only applies to a specific wallet, a specific target member, or a specific role being granted or held. An account can combine several requirements on the same action, each scoped differently, to express different approval rules for different situations.

​
Governed actions

Set governance is itself governed. By default, only the owner can change governance, and a requirement on Set governance can widen or narrow who else may initiate that change.

​
Next steps

Governance

Implement governed mutations, proposals, and approvals with the JavaScript SDK.

Quorum policies

Require approvals before a wallet signs, instead of before an account action applies.
Last modified on September 29, 2026