Quorum policies

Require approvals before a Business Account wallet can sign a message or transaction.

Signing quorum currently covers message signing on all supported chains and transaction signing on EVM. Solana and Bitcoin transaction support is coming soon. For the quorum model itself, the approval lifecycle, and the requirement fields, see Quorum policies.

Before this: create and initialize a Dynamic client (see Creating a Dynamic Client, Initializing the Dynamic Client).

Governance requirements apply to account changes instead of signing. See Governance for actions such as adding a member or transferring ownership.

approvalRequirements is a PolicyRules field. It composes with other rules in the same policy layer and uses the Account-Layer, Wallet-Layer, and Signer-Layer scope of that layer.

The policy layer can further restrict the applicable chain and chain IDs.

Create a transaction quorum rule

The following rule requires one approval from a Business Account member with the admin role for native-token transfers of at least 1 ETH on Ethereum mainnet.

JavaScript

import { createPolicy } from '@dynamic-labs-sdk/client/waas';
import { WaasChainEnum } from '@dynamic-labs/sdk-api-core';

await createPolicy({
  scope: { businessAccountId: 'ba_123' },
  chain: WaasChainEnum.Evm,
  chainIds: [1],
  rules: {
    approvalRequirements: [
      {
        v: 1,
        id: 'large-native-transfer',
        eligibleApproverRole: 'admin',
        requiredApprovals: 1,
        when: {
          minValue: {
            amount: '1000000000000000000',
            asset: '',
          },
        },
      },
    ],
  },
});

Use a built-in role such as admin, or a custom Business Account role. A value such as anyAdmin works only when the Business Account defines a custom role with that exact name.

Set eligibleApproverRole explicitly. If you omit it, any verified approver role can satisfy the requirement. The initiator never counts toward requiredApprovals.

Requirement fields

Field	Type	Description
v	1	The requirement schema version.
id	string	A stable ID for the requirement within the policy layer.
eligibleApproverRole	string	The Business Account role whose members may approve. Specify this field to restrict approver eligibility.
mandatoryApproverRole	string	A Business Account role that must be represented among the approvals.
requiredApprovals	number	The number of approvals required. The initiator never counts.
completeWithinSeconds	number	The time for a collected-approval proposal to remain valid. The default and maximum are 30 days (2592000 seconds).
when	object	Conditions that limit when the requirement applies. Omit it for an unconditional requirement.

getPolicy returns approvalRequirements with the same authoring shape. Approval progress is reported during signing. It is not part of the policy definition.

Limit a rule by transaction value

Use when.minValue to apply the requirement at or above a transaction value. Conditions in the same when object are combined with AND logic.

• amount is an integer string in the asset’s smallest unit.
• asset: '' selects the chain’s native token.
• An asset address selects that token.

Do not use when.initiatorRole or when.actionTypes to narrow a production rule. These fields are accepted but are not resolved during evaluation. A requirement that sets either field applies more broadly instead of being limited by that field.

The signing intent

Every quorum-gated signing request produces a SigningIntent: a signed, complete description of the operation that approvers review and that the resume step executes. The SDK prepares and signs it automatically when you initiate signing, and it is stored on the proposal so approvers see the same object the initiator signed.

Intent properties

Field	Type	Description
actionType	'waasSigningQuorumApprove'	The governed action the intent belongs to. Always this literal for signing intents.
intentId	string	A unique ID for the intent.
businessAccountId	string	The Business Account whose quorum must approve the operation.
initiatorUserId	string	The member who initiated the signing request. The initiator can never approve their own intent.
accountAddress	string	The wallet address that will sign.
createdAt	string	The ISO timestamp at which the intent was prepared.
completeBy	string	Optional ISO timestamp after which the proposal can no longer complete.
operation	object	The exact operation being approved. Its shape depends on operation.kind.
limits	object	Gas and fee ceilings. Present only when operation.kind is 'transaction'.

Operation kinds

operation.kind discriminates the union and determines the remaining fields:

kind	Additional fields	Chain
'message'	message, payload	chainName is any supported chain
'typedData'	typedData (EIP-712 JSON string), payload	chainName is 'EVM'
'raw'	payload (digest), rawSign (payload preimage, hashFunction, optional prefix)	chainName is any supported chain
'transaction'	chainId, from, to, value, data, nonce	chainName is 'EVM'

For message, typedData, and raw intents, payload is the exact prepared payload the signature covers. For transaction intents, limits instead carries the maxGas, maxFeePerGas, maxPriorityFeePerGas, and maxTotalFee ceilings described in Transaction fields the intent binds.

Complete a quorum-gated signing operation

The signing-quorum flow has three stages:

1. The initiator attempts to sign. The SDK prepares and signs an operation-bound intent automatically.
2. Other eligible Business Account members review and approve the resulting proposal.
3. After every requirement is satisfied, the initiator resumes the proposal to produce the signature.

1. Start signing

Use a Business Account wallet with its standard signing methods, such as signMessage, signRawMessage, signTypedData, or signSerializedTransaction. When a matching quorum rule requires approval, the call rejects with SigningConsentRequiredError. Save its proposalId so you can find the proposal later.

JavaScript

import { signMessage } from '@dynamic-labs-sdk/client';
import { isSigningConsentRequiredError } from '@dynamic-labs-sdk/client/waas';

try {
  const { signature } = await signMessage({
    message: 'Hello from signing quorum',
    walletAccount,
  });
} catch (error) {
  if (!isSigningConsentRequiredError(error)) {
    throw error;
  }

  console.log('Proposal awaiting approval:', error.proposalId);
}

The error’s reason tells you what consent is still missing:

• APPROVALS_REQUIRED: a proposal opened and needs other members’ approvals. The error carries proposalId and approvalRequirements.
• INTENT_REQUIRED: the operation’s intent still needs your session-key signature. This is rare because the SDK signs the intent automatically, but it can occur when the local client cannot produce the signature.

For INTENT_REQUIRED, sign the returned intent and retry the same call with the signed approvalQuorum. Pass the operation’s stored payload as preparedPayload for message, typed data, and raw signing so the intent is checked against your request before it is signed.

JavaScript

import { getDefaultClient } from '@dynamic-labs-sdk/client';
import {
  isSigningConsentRequiredError,
  signSigningQuorumIntent,
} from '@dynamic-labs-sdk/client/waas';
import { getWaasWalletProviderFromWalletAccount } from '@dynamic-labs-sdk/client/waas/core';

const message = 'Hello from signing quorum';
const waasProvider = getWaasWalletProviderFromWalletAccount(
  { walletAccount },
  getDefaultClient()
);
if (!waasProvider.signMessage) {
  throw new Error('The wallet provider cannot sign messages.');
}

try {
  await waasProvider.signMessage({ message, walletAccount });
} catch (error) {
  if (
    !isSigningConsentRequiredError(error) ||
    error.reason !== 'INTENT_REQUIRED'
  ) {
    throw error;
  }

  const { intent } = error;
  if (!intent || intent.operation.kind !== 'message') {
    throw error;
  }

  const approvalQuorum = await signSigningQuorumIntent({
    intent,
    preparedPayload: intent.operation.payload,
    request: {
      accountAddress: walletAccount.address,
      businessAccountId,
      chainName: 'EVM',
      initiatorUserId: intent.initiatorUserId,
      kind: 'message',
      message,
    },
  });

  await waasProvider.signMessage({
    approvalQuorum,
    message,
    walletAccount,
  });
}

Every chain’s WaaS signing methods accept approvalQuorum for this retry, including signPsbt on Bitcoin and signSerializedTransaction on EVM. Omit it on the first call: populate it only in response to an INTENT_REQUIRED outcome, with the exact intent that was signed.

Transaction fields the intent binds

For an EVM transaction, approvers consent to the stable fields of the operation: from, to, value, data, chainId, and nonce. Those fields cannot change between the approved intent and the signed transaction.

Only the gas and fee values may move, because a proposal can sit pending for as long as its completion window while gas prices drift. The intent carries four ceilings that bound how much the signed transaction may spend on gas:

Field	Description
maxGas	Upper bound on the transaction’s gas limit.
maxFeePerGas	Upper bound on the EIP-1559 max fee per gas.
maxPriorityFeePerGas	Upper bound on the EIP-1559 priority fee per gas.
maxTotalFee	Upper bound on gas * maxFeePerGas, independent of the others.

When you initiate signing, signSerializedTransaction defaults these limits to the values your unsigned transaction carries. Pass refreshLimits to approve wider ceilings up front, for example padded estimates, so the resumed signature still fits current network conditions after the proposal is approved:

import { signSerializedTransaction } from '@dynamic-labs-sdk/client/waas';

await signSerializedTransaction({
  chainId: '1',
  refreshLimits: {
    maxFeePerGas: (fees.maxFeePerGas * 2n).toString(),
    maxGas: (gas * 120n / 100n).toString(),
    maxPriorityFeePerGas: (fees.maxPriorityFeePerGas * 2n).toString(),
    maxTotalFee: (gas * 120n / 100n * fees.maxFeePerGas).toString(),
  },
  serializedTransaction,
  walletAccount,
});

At resume time the transaction is rebuilt from the approved operation with gas and fee values set at the approved limits, and wallet-service checks the transaction against those limits again. The approvers’ consent covers the operation’s identity and its spending ceiling, never a different destination, value, or calldata.

2. Approve the proposal

An eligible Business Account member other than the initiator approves the proposal from their own authenticated session.

JavaScript

import {
  approveBusinessAccountProposal,
  listBusinessAccountProposalsAwaitingMyApproval,
} from '@dynamic-labs-sdk/client/waas';

const proposals =
  await listBusinessAccountProposalsAwaitingMyApproval();
const proposal = proposals.find(({ id }) => id === proposalId);

if (!proposal) {
  throw new Error('Proposal is not awaiting this member\'s approval.');
}

const updated = await approveBusinessAccountProposal({
  businessAccountId: proposal.businessAccountId,
  proposal,
});

const ready = updated.approvalRequirements?.every(
  ({ satisfied }) => satisfied,
);

React

import {
  useApproveBusinessAccountProposal,
  useListBusinessAccountProposalsAwaitingMyApproval,
} from '@dynamic-labs-sdk/react-hooks';

const { data: proposals } =
  useListBusinessAccountProposalsAwaitingMyApproval();
const { mutate: approve, isPending } =
  useApproveBusinessAccountProposal();

return proposals?.map((proposal) => (
  <button
    disabled={isPending}
    key={proposal.id}
    onClick={() =>
      approve({
        businessAccountId: proposal.businessAccountId,
        proposal,
      })
    }
  >
    Approve {proposal.actionType}
  </button>
));

The satisfied value is authoritative. Do not infer readiness from approved >= required because a requirement can also require specific roles.

An approver can inspect the operation before approving it. getBusinessAccountSigningIntent reads the signed intent stored on a signing proposal, so your UI can show the message, typed data, or transaction the quorum is consenting to.

JavaScript

import { getBusinessAccountSigningIntent } from '@dynamic-labs-sdk/client/waas';

const stored = getBusinessAccountSigningIntent({ proposal });

if (stored.status === 'available') {
  const { operation } = stored.intent;
  console.log(operation.kind, operation.chainName);
}

The helper returns status: 'unsupported' for proposals that are not signing operations and status: 'mismatch' when the stored intent does not match its proposal.

3. Resume the approved operation

Read the pending proposal again, verify that every requirement is satisfied, and resume it with the same Business Account wallet. resumeSigningProposal consumes the proposal and returns the signature. For an EVM transaction intent the signature is the serialized signed transaction, which you then broadcast yourself.

JavaScript

import {
  getBusinessAccountSigningIntent,
  listBusinessAccountProposals,
  resumeSigningProposal,
} from '@dynamic-labs-sdk/client/waas';
const proposals = await listBusinessAccountProposals({
  businessAccountId: 'ba_123',
  status: 'pending',
});
const proposal = proposals.find(({ id }) => id === proposalId);

if (
  !proposal ||
  !proposal.approvalRequirements?.every(({ satisfied }) => satisfied)
) {
  throw new Error('The signing proposal is not ready.');
}

const { signature } = await resumeSigningProposal({
  proposal,
  walletAccount,
});

// For a transaction intent the signature is the signed transaction.
const transactionHash = await publicClient.sendRawTransaction({
  serializedTransaction: signature,
});

React

import {
  useListBusinessAccountProposals,
  useResumeSigningProposal,
} from '@dynamic-labs-sdk/react-hooks';

const { data: pending } = useListBusinessAccountProposals({
  businessAccountId,
  status: 'pending',
});
const { mutate: resume, isPending } = useResumeSigningProposal();

const ready = pending?.filter((proposal) =>
  proposal.approvalRequirements?.every(({ satisfied }) => satisfied)
);

return ready?.map((proposal) => (
  <button
    disabled={isPending}
    key={proposal.id}
    onClick={() => resume({ proposal, walletAccount })}
  >
    Finish signing {proposal.actionType}
  </button>
));

resumeSigningProposal verifies that the proposal is pending and fully approved and that the selected wallet belongs to the proposal’s Business Account and matches the intent address.

Review the proposal’s stored operation before approving it, and test the complete initiation, approval, resume, and broadcast flow in a non-production environment before enabling a quorum rule in production.

Changes to approver roles, thresholds, or deadlines apply to subsequent evaluations. Start a new signing request after changing a quorum rule so the request is evaluated against the current policy.