Support
Frequently Asked Questions
Common questions about WalletSuite governed wallet operations: flexible signing, policy and evidence workflows, MCP Server, and how WalletSuite compares to platforms like Fireblocks.
21 questions · Last updated April 2026
Platform
WalletSuite is governed wallet operations infrastructure for teams that move digital assets programmatically. It gives stablecoin platforms, payment teams, treasury operators, and agentic workflows one policy, approval, and evidence layer across MPC, OWS, external signers, and HSM-based signing workflows.
No. Fireblocks is a full institutional digital asset and custody platform. WalletSuite is designed as a flexible-signing operations layer: WalletSuite MPC and self-hosted OWS are first-class signing options, and signed-payload workflows let teams plug in external signers, custodians, or customer-controlled HSM/KMS infrastructure under the same policy, approval, and evidence model.
Shadow Control lets enterprise design partners run WalletSuite policy evaluation beside existing backend rules before turning on enforcement. Each transaction can be evaluated by both systems, compared for approve, deny, or requires-review outcomes, and recorded as evidence for migration and audit review.
Tenant governance means each customer, merchant, fund, business unit, or workspace can have its own wallets, policies, approvers, limits, KYT settings, agent tokens, audit logs, and evidence exports. This is especially useful for payment platforms, stablecoin platforms, RWA platforms, and multi-client treasury products.
Backend scripts usually prove that a team can write rules. WalletSuite is intended to productize those controls across signers, tenants, approvals, evidence, and automation workflows. Teams can start in shadow mode, compare WalletSuite decisions with existing rules, then move enforcement only after the policy behavior is trusted.
WalletSuite separates read, prepare, approve, sign, and broadcast. Agents and backend jobs can be limited to only the capabilities they need, while large, risky, or new-counterparty transactions can require policy checks and human approval before signing or broadcast.
80+ blockchains today, including Ethereum, Solana, Bitcoin, Polygon, Arbitrum, Optimism, Base, BNB Chain, Avalanche, and Tron. Every chain is accessible through the same API surface, with normalized data formats so you don't need chain-specific integration code.
Yes — modular by design. Use only the endpoints or tools you need: balance queries, swaps, price feeds, transaction construction, or full governed-signing flows. Every surface (MCP Server, SDK, REST API) shares the same primitives — bands, policy gates, flexible signing, hash-chained audit — so you can adopt the surface that fits your stack and add others later.
Teams use WalletSuite for AI agent wallet access, crypto payment processing, portfolio tracking, exchange backends, DeFi aggregators, DApps, and neobank on-ramps. Any product that needs to read balances, look up prices, resolve tokens, or prepare transactions across multiple chains.
Integration
WalletSuite should not be understood as an official Fireblocks partner or native Fireblocks integration unless separately agreed. The flexible-signing model supports signed-payload workflows designed to work alongside external signing infrastructure, including Fireblocks-like operational patterns, Turnkey-like wallet infrastructure, Ledger workflows, AWS KMS, and customer HSMs.
It depends on the surface. The MCP Server runs in under 15 minutes — npx install, API key, agent token, first signed transaction. The SDK and REST API typically take up to 2 days to integrate end-to-end depending on use case. Building the same functionality in-house usually takes 12+ months and 5–7 separate vendor integrations.
No. The API and SDK handle chain-specific complexity for you: nonce management, fee estimation, gas optimization, UTXO selection, calldata encoding, token resolution, balance aggregation, price lookups, transaction simulation, webhook delivery, contract decoding, and multi-chain routing. Your team works with a standard REST API and typed SDK. The MCP Server goes further by letting AI agents interact with wallets through natural language, with no blockchain code at all.
MCP Server
The MCP Server is the agent-facing surface of WalletSuite, alongside the SDK and REST API. It connects AI agents to on-chain wallet operations via the Model Context Protocol, an open standard by Anthropic. The server exposes tools for balance queries, token resolution, price lookups, transfer preparation, transaction signing, and broadcasting. By default, signing happens via hosted 2-of-2 MPC — no key management, no HSM procurement, no MPC provider integration. Self-hosted OWS is available as an opt-out for HFT and regulated environments. Works with LangChain, CrewAI, Pydantic AI, Claude Agent SDK, or any custom MCP runtime.
Token resolution maps a human-readable identifier like 'USDC' to the exact contract address on a specific chain. Since the same symbol can exist on dozens of chains at different addresses, the resolver verifies the asset against a curated registry and flags ambiguous matches. This prevents misrouted transfers in both API integrations and AI agent workflows.
An agent token is a scoped credential issued to an autonomous agent process. The token binds the agent to a specific wallet, a band cap (which of read, prepare, sign, broadcast it can use), and a policy set (chain allowlist, spend caps, expiry). The agent never sees private keys — it presents the token, and WalletSuite enforces what the token is allowed to do. Tokens are revocable independently of the underlying wallet, so rotating an agent's authority is issuing a new token, not redeploying. One token per strategy, treasury, or operator process.
Security
Flexible signing means policy, approval, audit, and automation logic are not locked to one signing backend. WalletSuite supports WalletSuite MPC, self-hosted OWS, external signer workflows, HSM/KMS patterns, and signed-payload emit flows — teams choose the signing model that fits the workflow without rebuilding governance.
The Evidence API turns wallet operations into structured receipts. A receipt can include tenant ID, wallet ID, transaction facts, policy version, policy hash, matched rules, decision reason, approval trail, signer path, KYT pre-check result, broadcast status, and hash-chain links for tamper-evident audit review.
KYT and Travel Rule pre-check workflows are available for enterprise design partner validation. The goal is to evaluate compliance signals before broadcast and attach the result to the transaction evidence record. Production availability depends on the selected provider, jurisdiction, workflow, and enterprise deployment scope.
Non-custodial by architecture, with two paths. Default at all paid tiers: 2-of-2 MPC — WalletSuite holds one share, your team holds the other, both signatures required for every transaction. Neither party can move funds alone. Opt-out for HFT trading agents who need sub-millisecond local signing: self-hosted Open Wallet Standard (OWS) where keys stay on your infrastructure, AES-256-GCM encrypted at rest. Either path emits unsigned payloads through the API or MCP Server for any external signer (Safe, HSM, custom) when you prefer to bring your own. A four-band permission system (read, prepare, sign, broadcast) controls which operations an agent can perform, and per-wallet policy gates enforce chain restrictions, spend caps, and expiry rules.
Security is layered across every level. All inputs are schema-validated before processing. The MCP Server enforces a four-band permission system (read, prepare, sign, broadcast) so AI agents can only access the operations you explicitly enable. Default 2-of-2 MPC means WalletSuite cannot produce a signature alone; the customer share is required for every transaction. In OWS opt-out mode, keys are encrypted with AES-256-GCM in a local vault on your infrastructure. In either path, secrets never pass through tool arguments or chat, every signing and broadcast operation is logged to a tamper-evident SHA-256 hash-chained audit trail, and policy is evaluated before any signature is produced.
Hosted MPC is the default for most teams. Choose self-hosted OWS only when: (1) you need sub-millisecond local signing for HFT trading agents, (2) you're in a regulated environment that requires keys never reach vendor infrastructure, or (3) you have an existing operator workstation that signs locally and you want bands without changing the signing path. Hosted MPC ships zero infrastructure to operate, hosted policy, hosted audit. OWS gives you full key residency on your own servers but requires running the OWS daemon and your own audit log storage. Both are non-custodial — the customer always holds a key share, and a compromise on either side can't move funds.
Get in touch
Still have questions?
Our team typically responds within 2 hours during business hours. For technical questions, check the documentation first.