Dynamic: Choosing Between Embedded Wallets and Server-Controlled Automation

A marketplace wants to pay sellers automatically after an order clears. Its customers already use embedded wallets, so the team considers reusing the same provider for a payout worker. The first decision is about control: is the worker acting with a customer’s delegated authority, or moving funds from a wallet owned by the marketplace’s backend?

Research boundary: official product and technical documentation reviewed November 1, 2026. This article proposes implementation checks; it does not report a deployed payout system or a tested recovery procedure.

Keep the product identity clear

Dynamic’s current product page sits within Fireblocks and presents embedded wallets alongside other financial-product capabilities. That relationship does not make Dynamic’s integration identical to every Fireblocks wallet product. Evaluate the specific SDK, wallet type and policy configuration you plan to operate.

For the marketplace example, user login and unattended disbursement are separate paths. An embedded wallet may belong in the customer experience, while a backend-controlled wallet may fit the platform’s own payout funds. Choosing between them also chooses who is responsible for authorizing and recovering access. A familiar login screen does not answer that question.

The server wallet runs in a particular environment

Dynamic’s server-wallet setup describes a Node SDK using native MPC addons. It requires a supported standard Node runtime and explicitly excludes browser and edge environments such as Cloudflare Workers. A site hosted at the edge can still call a separate backend, but that is another service to secure and operate.

Plan the signing worker’s deployment before writing the payout queue. Separate the public API that accepts business requests from the service allowed to retrieve wallet material and sign. The language or framework of the frontend should not determine where signing authority ends up.

Persistence is part of the wallet design

Conceptual server-wallet flow, not a tested deployment. Metadata and protected signing material have different storage and access requirements.

Dynamic’s storage guide says the SDK is stateless. The application must retain complete wallet metadata, including recovery-related fields, and protect customer-side key shares when it manages them. Keeping only the public address is insufficient for later signing or export operations in the documented flow.

That has a practical consequence for disaster recovery. A database restore that brings back seller IDs and addresses may still leave the signing service unusable. Design and rehearse recovery for the complete wallet state and its access permissions, not just the payout ledger. Do not place key shares in ordinary application logs to make debugging easier.

Know what the policy actually measures

The policy documentation describes checks before signing for current v3 TSS-MPC wallets. It exposes per-transaction value limits and address rules. Wallet- and signer-level policy layers were marked early access at review time; chain-specific validation also has exceptions. A supported chain name alone is not proof that every rule applies to every operation there.

For a seller payout system, a per-call ceiling does not express a monthly seller allowance. Splitting a large request into several smaller requests can still satisfy a per-call check. If the product promises a cumulative budget, the architecture must identify where that total is maintained and enforced, including concurrent workers.

Likewise, a merchant address allowlist can be too narrow for a contract-mediated workflow that touches additional contracts. Review the simulated execution path and required participants; do not respond to a legitimate rejection by disabling the allowlist for the entire environment.

Review operational ownership before enabling automation

Question	Why the marketplace needs an answer
Who can modify a policy?	A payout worker should not casually rewrite its own restrictions
Who restores wallet state?	Recovering business data and restoring signing access are separate duties
Which service can decrypt shares?	An unrelated API compromise should not automatically unlock payouts
What happens after a policy rejection?	The order must remain unpaid, not silently switch to a broader signer
Which state marks a payout complete?	A signature or broadcast attempt is not the seller’s reconciled receipt

These are editorial acceptance criteria, not a claim that one configuration satisfies them automatically. The team should also account for wallet-service charges, RPC use, network fees and recovery operations rather than treating an embedded-wallet feature as the entire payout cost.

Our take

Dynamic is relevant when a product needs both a user-facing wallet experience and programmable backend operations. The strongest evaluation begins with an ownership diagram, a realistic runtime choice and a recovery drill. MPC changes how signing material is handled; it does not remove the application’s duties around credentials, permissions or duplicate payouts.

See the Dynamic reference and payment idempotency guide for the next layer of design. A small, clearly bounded payout workflow is a better first proof than a worker with authority over every wallet in the environment.