> ## Documentation Index
> Fetch the complete documentation index at: https://www.dynamic.xyz/docs/llms.txt
> Use this file to discover all available pages before exploring further.
# Approvals
> Require multiple members to approve account changes or wallet signing before they take effect.
Business Accounts are in **early access**. See [Business Accounts](/docs/business-accounts/accounts) for the model.
Approvals let you require multiple parties to approve an action before it takes effect. One approval mechanism covers both kinds of action a business account has:
* **Account changes**, such as adding or removing a member, transferring ownership, changing signers, and linking or removing a wallet. An approval requirement on an account change is called a governance requirement.
* **Wallet signing**, such as messages and transactions. An approval requirement on signing is called a quorum policy, a rule inside Dynamic's policy composition model described in [Policies & Rules](/docs/embedded-wallets/mpc/policies/overview).
Both use the same machinery: the initiator signs an intent for the exact action, the action becomes a proposal, eligible approvers sign it, and the action completes once every requirement is satisfied.
## How approvals work
1. A member initiates an action that a requirement covers, such as adding a member, transferring ownership, or signing a transaction.
2. The initiator signs an intent for the exact action. When the action 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 action 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. For a signing operation, the initiator resumes the proposal to produce the signature, described in [Approvals for signing](#approvals-for-signing).
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 [Proposal webhooks](/docs/business-accounts/webhooks/proposals).
## Requirements and roles
A 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.
On an account change, 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.
## Approvals for account changes
A governance 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.
The actions a governance requirement can cover:
| Action | What it governs |
| - | - |
| Add member | Adding a member |
| Remove member | Removing a member |
| Update member role | Changing a member's role |
| Transfer ownership | Transferring ownership |
| Add wallet | Creating a wallet under the account |
| Link wallet | Linking an existing wallet to the account |
| Remove wallet | Unlinking a wallet |
| Add signer to wallet | Adding a signer to a wallet |
| Remove signer from wallet | Removing a signer from a wallet |
| Define role | Defining a custom role |
| Delete role | Deleting a custom role |
| Set governance | Changing the account's governance requirements |
`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.
For implementation, see [Governance](/docs/javascript/reference/business-accounts/governance) in the JavaScript SDK reference.
## Approvals for signing
A quorum policy requires approvals before a Business Account wallet can sign. It applies to signing operations such as messages and transactions, not just transfers. Signing quorum currently covers message signing on all supported chains and transaction signing on EVM. Solana and Bitcoin transaction support is coming soon.
A quorum policy is a rule inside the policy composition model, so it composes with an account's other policy rules and lives at the same Account-Layer, Wallet-Layer, or Signer-Layer scope as those rules, described in [Policies](/docs/business-accounts/policies).
A quorum rule names how many approvals a signing request needs and which Business Account role may give them. Set the eligible approver role explicitly: leaving it unset lets any verified approver role satisfy the requirement, which is rarely what you want. The initiator never counts toward the required approvals.
A rule can be scoped to apply only at or above a given transaction value, on a given asset or the chain's native token. A rule with no such condition applies to every transaction that otherwise matches its scope.
Conditions that would narrow a rule by the initiator's role or by the type of action are accepted today but are not evaluated. A rule that sets either one applies more broadly than its condition suggests, rather than being limited by it. Do not rely on either condition to narrow a production rule.
A signing operation that matches a quorum rule moves through three stages instead of completing in one step:
1. The initiator attempts to sign. The operation's intent is prepared and signed automatically, and a proposal opens instead of a completed signature.
2. Other eligible Business Account members review and approve the proposal from their own sessions.
3. Once every requirement is satisfied, the initiator resumes the proposal, which produces the signature. For an EVM transaction, resuming returns a signed transaction that is not broadcast: broadcasting it is a separate, final step.
Changes to a quorum rule, such as its approver role, threshold, or completion window, apply to signing requests evaluated after the change. A request already in flight when the rule changes is not retroactively re-evaluated; start a new signing request to have it evaluated against the current rule.
For implementation, see [Quorum policies](/docs/javascript/reference/business-accounts/policies/quorum-policies) in the JavaScript SDK reference.
## Next steps
Implement governed mutations, proposals, and approvals with the JavaScript SDK.
Implement transaction quorum rules and the approve-and-resume flow with the JavaScript SDK.