Skip to main content
Business Accounts are in early access. See Business 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.
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. A requirement sets how many approvals an action needs, who may give them, and how long the proposal has to complete, as described in Requirements and roles. Covered actions are listed in Approvals for account changes and Approvals for signing.
  2. The initiator signs an intent for the exact action. An intent is a signed description of that action. The SDK builds and signs the intent locally when it can. If it cannot, such as when a member is added by email before the server has resolved that identifier to a user, the SDK throws BusinessAccountIntentRequiredError with the intent attached. The initiator signs that intent without changing it, using signBusinessAccountIntent, and retries the same call with the signed result.
  3. The signed action becomes a proposal once it still needs approvals. If the action needs no approval, the call returns the completed account change instead of a proposal.
  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 by default. How the step finishes depends on the action:
    • Held proposals. To hold an action, pass autoExecute: false to the SDK call that starts it, for example addBusinessAccountMember({ autoExecute: false, businessAccountId, targetIdentity, role: 'viewer' }). The calls come from @dynamic-labs-sdk/client/waas. Once the approvals are complete, any member of the account can run the held proposal with executeBusinessAccountProposal.
    • Key-ceremony actions. These change a wallet’s key shares through a reshare, so they always wait for a separate step to finish, whatever autoExecute is set to. Adding a signer to a wallet is the only one today, and it is a different action from adding a member to the account.
    • Signing. The initiator resumes the proposal to produce the signature, described in 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. An approval counts only while the approver’s standing on the account holds. Changing a member’s role, demoting the previous owner through an ownership transfer, or removing a member revokes every approval that member had given on still-open proposals, so a proposal that had met its requirements can fall below them again. Any of these changes also vetoes every open proposal that member initiated, since a signed intent must not outlive the standing it was given under. Proposals that already executed keep their approval records as the audit trail for what was authorized. For the events fired at each stage, see Proposal webhooks.

​
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. After the window closes, approving or executing the proposal fails, and its status changes to expired at the next background check. See Set completion windows and execution. 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: 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 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 and Solana. Bitcoin transactions are not covered. Rules and approvals act as two gates in order. The wallet’s other policy rules are checked first, so a transaction that breaks a rule, such as a transfer to a denied address or one above a value limit, is rejected and never becomes a proposal. A transaction that passes the rules then waits for the approvals its quorum rules require before the wallet signs. 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. A quorum rule names how many approvals a signing request needs and which Business Account roles, built-in or custom, may give them: the eligible approver roles accept a list, and a member holding any listed role can approve. A rule can also name mandatory approver roles that must each be represented among the approvals, independent of the eligible roles. Set eligible approver roles explicitly: leaving them 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.
Some transaction values are not fixed when the proposal opens. A Solana transaction carries a recent blockhash that expires within minutes, and an EVM transaction can carry a nonce that goes stale if the account sends another transaction while approvals are pending. The signed intent marks these values as refreshable, so the wallet replaces them with current values at resume time while every other part of the approved operation stays fixed. Approvers consent to the operation, not to the refreshed value.

​
Example: a payment end to end

Setup: an ops wallet’s rules allow USDC only to allowlisted vendors, and a quorum rule requires 2 approvals from finance approvers for any payment over $5,000.
  1. A signer requests a $6,000 USDC payment to an allowlisted vendor.
  2. The wallet’s policy rules run first: USDC to an allowlisted address passes. A payment to a non-allowlisted address would be rejected here and never reach approval.
  3. The amount is over $5,000, so the request opens a proposal and waits for approvals.
  4. Two finance approvers approve from their own sessions, satisfying the quorum.
  5. The signer resumes the proposal, which produces the signature, and the payment is broadcast as the final step.
  6. Proposal webhooks report each stage, so the app can show live status the whole way.
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 in the JavaScript SDK reference.

​
Next steps

Governance

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

Quorum policies

Implement transaction quorum rules and the approve-and-resume flow with the JavaScript SDK.
Last modified on October 23, 2026