> ## 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.

# Quorum policies

> Require approvals before a Business Account wallet can sign an EVM transaction.

<Note>
  Business Accounts are in **early access**. See the [overview](/docs/business-accounts/overview) for the model. Transaction quorum is currently available for EVM transactions. Solana and Bitcoin support is coming soon.
</Note>

A quorum policy requires approvals before a Business Account wallet can sign a transaction. This is separate from [governance](/docs/business-accounts/governance), which requires approvals for account changes such as adding a member or transferring ownership.

A quorum policy is a rule inside Dynamic's policy composition model, described in [Policies & Rules](/docs/embedded-wallets/mpc/policies/overview). 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.

## Requirements and roles

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 also name a role that must be represented among the approvers, independent of the eligible role, and a completion window for how long a collected-approval proposal remains valid. The default and maximum is 30 days.

## Limiting a rule by transaction value

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.

<Warning>
  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.
</Warning>

## Completing a quorum-gated transaction

An EVM transaction that matches a quorum rule moves through three stages instead of completing in one step:

1. The initiator attempts to sign. The transaction'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 signed transaction. Resuming does not broadcast it: broadcasting the signed transaction 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.

## Next steps

<CardGroup cols={2}>
  <Card title="Quorum policies" icon="code" href="/docs/javascript/reference/business-accounts/policies/quorum-policies">
    Implement transaction quorum rules and the approve-and-resume flow with the JavaScript SDK.
  </Card>

  <Card title="Governance" icon="shield-check" href="/docs/business-accounts/governance">
    Require approvals for account changes instead of transaction signing.
  </Card>
</CardGroup>