Skip to main content
Business Accounts are in early access. See the overview for the model.
This quickstart runs one end-to-end path in a React app: create a business account, give it an EVM wallet, add a teammate as a second signer and an admin member (which exercises step-up authentication and the intent-signing retry), attach a quorum rule, then sign a message through the propose, approve, and resume flow. Each step links to the full guide for that operation.

Prerequisites

  • A Dynamic client initialized with your environment ID (see Creating a Dynamic Client and Initializing the Dynamic Client)
  • An authenticated user, because every business account call acts on behalf of the signed-in user
  • Business Accounts enabled for your environment (early access)
  • @dynamic-labs-sdk/react-hooks installed and the app wrapped in DynamicProvider, as in the React quickstart
1

Create the business account

useCreateBusinessAccount returns a mutation hook; mutateAsync resolves to the new account, whose id you need for every later call. The signed-in user becomes the owner.
Expected outcome: account.id is set, and the caller is the account’s owner.
2

Create a wallet for the account

createWalletForBusinessAccount mints an embedded wallet owned by the account and seats the caller as its first signer. Use the useCreateWalletForBusinessAccount hook.
Expected outcome: the account owns an EVM wallet, and the caller can already sign with it.
3

Add a second signer

Adding a signer exercises three SDK behaviors in one call:
  1. Step-up authentication. Adding a signer requires an elevated token scoped to business_account:signer:add (see Step-Up Authentication for the model). Check first with checkStepUpAuth, then verify with authenticatePasskeyMFA (or another MFA method) passing requestedScopes.
  2. Intent signing. When the SDK cannot construct the intent locally, for example when the target is identified by email, addBusinessAccountSigner throws BusinessAccountIntentRequiredError. Sign error.intent with signBusinessAccountIntent and retry with the returned intent and intentSignature.
  3. Governance. When the account requires approvals for signer changes, the call returns a pending action instead of a share set. Narrow it with isBusinessAccountActionRequired and surface the proposal for approval.
Expected outcome: the teammate’s email resolves to a user, the reshare mints their key share, and the call resolves to { shareSetId } (or a pending proposal when governance applies). See Manage signers for password and targetSignerPassword, which are required when your environment mandates wallet passwords.
4

Give the teammate an admin role

A signer can sign, but only a member can approve proposals or administer the account. Add the same teammate as an admin member so they can approve the quorum in the next steps. This is the same pattern as adding a signer, scoped to business_account:member:add instead.
Expected outcome: the teammate is now an admin member of the account and a signer on its wallet. Members and signers are independent, so both grants are explicit.
5

Require an approval before signing

createPolicy attaches rules to the account. An approvalRequirements rule turns signing into a propose, approve, and resume flow. This rule requires one approval from an admin member for every signing operation on the account’s EVM wallets.
Expected outcome: the account-layer policy now requires one admin approval before the wallet signs. Set eligibleApproverRole explicitly; omitting it lets any verified approver role satisfy the requirement, and the initiator never counts toward requiredApprovals.
6

Sign a message through the quorum

With the quorum rule active, signMessage rejects with SigningConsentRequiredError instead of returning a signature: the SDK signs the operation’s intent automatically and opens a proposal carrying that intent.
The teammate then approves from their own session, reading the proposals awaiting their approval.
Back in the initiator’s session, resumeSigningProposal consumes the satisfied proposal and returns the signature.
Expected outcome: signature is a hex signature from the business-account wallet, produced only after the admin approved the proposal. For the full quorum flow, including intent inspection and transaction signing, see Quorum policies.

What just happened

You created a business account with yourself as owner, gave it an EVM wallet on which you are the first signer, elevated your session for the business_account:signer:add and business_account:member:add scopes, added a teammate as a second signer and an admin member (signing the server-returned intents when the target was identified by email), attached a quorum rule requiring an admin approval to sign, and produced a signature through the propose, approve, and resume flow. The account, not any single user, owns the wallet and its signing rights.

Next steps

Members & roles

Give the teammate admin rights, or invite viewers.

Governance

Require approvals for signer, member, and wallet changes.

Quorum policies

The full propose, approve, and resume signing flow, including transactions.

Policies

Constrain what signers and wallets may do.

Step-up auth

Every scope that requires an elevated token, and every way to get one.
Last modified on September 30, 2026