Best practices for policies and approvals

A business account gives you several independent controls: roles decide who can manage the account, signers decide who can sign with each wallet, approvals decide who must agree before a change or signature goes through, and policies decide what a wallet may sign at all. The protection comes from how you combine them. This page describes the combinations that hold up well and the gaps to plan around. A new account has no approval requirements, so every change applies as soon as a member with the right role makes it. Put the practices below in place before an account holds meaningful funds.

​

Keep managing, signing, and approving apart

A business account separates 3 powers, and you get the most protection when different people hold them. An approver does not need to be a signer or an admin. A custom role that inherits viewer and is named as the eligible approver gives someone approval power with no way to move funds or change the account. A finance reviewer who approves payments, for example, then cannot initiate a payment or change who approves it. Grant signing per wallet and only where a person needs it. A signer on the operations wallet does not need to sign on the treasury wallet, and an admin who manages the account does not need to sign at all.

​

Govern the actions that change the controls

Some account changes alter who holds power, so an unchecked change undoes every other control. Put an approval requirement on each of these actions before you rely on the rest of your configuration. Governance requirements cannot cover a change to a wallet’s policy rules. Protect policy changes through the management roles you grant, and let signing quorum carry the approval weight. A requirement does not have to cover every instance of an action. You can scope it to the risky cases, for example a requirement on Add member and Update member role that applies only when the role being granted is admin, so routine changes such as adding a viewer skip the wait. For Add signer to wallet, require the approvals to come from people who are already signers on that wallet: the existing signers agree to share the wallet rather than any admin deciding alone. This approver capability narrows the approver roles rather than replacing them, so include the roles your signers hold, such as viewer, in the requirement’s approver roles. Scope the requirement to your highest-value wallets if you don’t want it on every wallet. Setting governance replaces the full requirements object. Read the current requirements first, change the one action you mean to change, and send the rest back unchanged. A write that leaves out an action is refused, so a partial write fails rather than silently clearing requirements.

​

Size every requirement so it stays satisfiable

The initiator of a proposal never counts toward its approvals, and each member can approve once. A requirement for 2 approvals needs at least 2 eligible approvers other than whoever starts the action, and if the people who usually initiate also hold the approver role you need at least 3. Leave headroom beyond that minimum. A 2 of 2 requirement stops the account whenever 1 approver is away, so prefer a pool that is larger than the threshold, such as 2 of 3. Check your requirements before you remove a member or change their role. Removing a member also removes them as a signer on every wallet, and it can leave a requirement short of approvers. The platform blocks removing the last owner and the last signer on a wallet, but do not rely on it to catch a change that leaves an approval requirement unsatisfiable. Approver roles behave differently depending on how you set them:

• An approval requirement on an account change that names no approver roles falls back to owner and admin. Name the roles you intend instead of relying on the default.
• An empty approver role list is rejected, because no one could satisfy it.
• A quorum rule on signing that names no approver role lets any verified approver role satisfy it. Always set the approver role on a quorum rule.
• A quorum rule matches its approver role exactly. A member whose custom role inherits admin does not count as an admin approver, so name the custom role itself when its holders should approve.
• Use a mandatory approver role when one function must always take part, such as requiring that at least 1 approval comes from a compliance role even when other roles can also approve.

​

Plan for owner continuity

Every account has exactly 1 owner. Only the owner can transfer ownership, the last owner cannot be removed, and Set governance can only be initiated by the owner unless a requirement widens it. There is no documented way to move ownership without the current owner, so if the owner’s access is lost or they leave before transferring, contact Dynamic support. Protect the owner’s sign-in with more than one verification method so that losing one device does not lock them out; see End-user MFA. Transfer ownership before an owner leaves or changes responsibilities. The previous owner becomes an admin as part of the transfer, so plan whether they should then be demoted or removed.

​

Layer signing controls

A signing request must pass every policy layer that applies, from the environment down to the signer, and a narrower layer can add restrictions but cannot loosen a broader one. Use each layer for the scope it matches:

• Environment. Set baseline rules that every account in your app should have, such as blocking private key export and denying known bad addresses.
• Account. Set rules that apply to every wallet a business owns, such as the account’s approved counterparties.
• Wallet. Set rules for one wallet’s purpose, such as a tighter allowlist and a lower per-transaction cap on an operations wallet.
• Signer. Set limits for one person on one wallet, such as a smaller cap for a junior signer.

Combine an address allowlist, a per-transaction value cap, and a quorum rule that applies at or above a value threshold. The allowlist limits where funds can go, the cap limits the size of a single transaction, and the quorum rule asks for review on the larger transactions that remain. Value caps and value-based quorum rules apply to each transaction separately, so they do not limit the total sent across many transactions. A signer could split a large transfer into smaller ones that each stay under the threshold. Keep allowlists narrow so split transfers can still only reach approved destinations, and monitor signing activity for repeated transactions just under a threshold. Keep these protections on:

• Leave Blockaid transaction screening enabled. Don’t set disableBlockaidSecurityChecks on an account, wallet, or signer rule unless you have a specific reason and another control that covers the same risk.
• Use modifiableBySigner only for rules you are happy for the signer to own, such as a personal allowlist. A signer can change a modifiable rule’s addresses and value limits, but rules that carry operation restrictions or disable Blockaid cannot be made modifiable.
• Avoid updating the same policy scope from 2 places at once. Concurrent updates can create duplicate rules.

​

Account for current quorum limits

Signing quorum covers message signing on all supported chains and transaction signing on EVM chains. On Solana and Bitcoin wallets, rely on allowlists, value caps, and signer assignment until quorum covers their transactions. Quorum rules accept conditions that narrow a rule by the initiator’s role or by the type of action, but those conditions are not evaluated today. A rule that sets either one applies more broadly than its condition suggests, so don’t use them to narrow a production rule. Use transaction value conditions, which are evaluated, or put the rule on a narrower layer.

​

Set completion windows and execution

Every requirement has a completion window: the time from the initiator’s signature until the proposal must be approved and executed. The default and maximum is 30 days. Shorten it for payments and other time-sensitive actions, so an approval does not authorize a transaction long after the circumstances that justified it have changed. Decide whether approved changes run automatically. With auto-execute on, a change applies as soon as the last approval arrives. With it off, an authorized member must execute the proposal, which adds a final check at the cost of an extra step. Signing proposals always need the initiator to resume them, and a resumed EVM transaction is returned signed but not broadcast. Every step must finish inside the window: a proposal that reaches its completeBy deadline without executing expires, and the initiator has to start again. Review open proposals after you tighten a rule. A signing request already in flight is not re-evaluated against a changed quorum rule, so veto pending proposals that would not meet the new rule and ask the initiator to start again. An eligible approver can veto a proposal, and a veto rejects it permanently.

​

Treat step-up and approvals as separate checks

Step-up authentication confirms that the person initiating a sensitive change has just re-verified their identity. Approvals confirm that other people agree to the change. Step-up does not replace approvals, because one member who re-verifies is still one member. If your backend issues elevated tokens through an external auth assertion, it can authorize sensitive account changes without the member interacting at all. Protect its signing keys as you would any credential that controls funds, mint only the scope the requested action needs, and keep token lifetime short.

​

Monitor changes as they happen

Subscribe to the account action webhooks and the proposal webhooks, and alert someone outside the account’s admins on the events that change who holds power:

• businessAccount.governance.updated
• businessAccount.ownership.transferred
• businessAccount.member.roleChanged
• businessAccount.member.removed
• businessAccount.signer.added
• businessAccount.signer.revoked
• businessAccount.role.defined

No webhook fires when a wallet’s policy rules change today, so record policy changes in your own system when you make them. Also track vetoed and expired proposals. A run of vetoes can point to an attempted change that others rejected, and expired proposals can mean the approver pool is too small or too slow for the completion window. Store the events you receive, so you keep your own record of who changed what and when.

​

Example configuration

This example combines the practices for a small finance team with an operations wallet on an EVM chain. The amounts are illustrative. finance-approver is a custom role that inherits viewer, so its holders can read the account but cannot manage it. The account’s approval requirements protect its controls: The operations wallet’s policies limit what it can sign: When Sam pays a vendor 6,000 USDC, the payment is within the allowlist and under the cap, so it reaches the quorum rule and opens a proposal. Any 2 of Mia, Noah, and Priya approve it, and Sam resumes it to produce the signed transaction. The approvers cannot sign or change the account, and Sam cannot change the wallet’s rules. If Mia is away, Noah and Priya can still approve, which is why the pool has 3 members for a threshold of 2. The signer requirement is tighter. Only an owner or admin who is already a signer can add signers, so Eli initiates and Sam is the only other signer who can approve. Add a third signer to the operations wallet if new signers must be addable while Sam is away.

​

Next steps