Business Accounts are in early access. See the overview for the model.
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-hooksinstalled and the app wrapped inDynamicProvider, 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.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.3
Add a second signer
Adding a signer exercises three SDK behaviors in one call:Expected outcome: the teammate’s email resolves to a user, the reshare mints their key share, and the call resolves to
- 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 withcheckStepUpAuth, then verify withauthenticatePasskeyMFA(or another MFA method) passingrequestedScopes. - Intent signing. When the SDK cannot construct the intent locally, for example when the target is identified by email,
addBusinessAccountSignerthrowsBusinessAccountIntentRequiredError. Signerror.intentwithsignBusinessAccountIntentand retry with the returnedintentandintentSignature. - Governance. When the account requires approvals for signer changes, the call returns a pending action instead of a share set. Narrow it with
isBusinessAccountActionRequiredand surface the proposal for approval.
{ 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 Expected outcome: the teammate is now 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.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.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, The teammate then approves from their own session, reading the proposals awaiting their approval.Back in the initiator’s session, Expected outcome:
signMessage rejects with SigningConsentRequiredError instead of returning a signature: the SDK signs the operation’s intent automatically and opens a proposal carrying that intent.resumeSigningProposal consumes the satisfied proposal and returns the signature.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 thebusiness_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.