Security Diligence

No full key ever exists on WalletSuite infrastructure. The property is structural, not a policy promise - and it is the starting point for every other question on this page.

​

Keys Isolation

No WalletSuite employee can move customer funds unilaterally. Signing runs through 2-of-2 MPC. WalletSuite holds one of two DKLS23 shares; the customer holds the other. Both shares are required to produce a valid signature, and no full private key is ever assembled in one place. Neither party alone can sign - the property is mathematical, not contractual. Internal access to our share is M-of-N gated and audit-logged. We hold a share that cannot sign without the customer share. The backend API sees chain queries and transaction preparation requests - public blockchain data and the address involved. It cannot access signatures, key shares, or signed payloads. The Trust Model enumerates what each component can access.

​

Data Residency

The customer key share never leaves customer infrastructure - any cloud, on-prem, bare metal, or edge environment the customer chooses. There is no “WalletSuite copy” of it. Whatever network boundary a deployment sits behind, that is where the customer share stays. The WalletSuite backend API serves public chain data: balances, fees, metadata, unsigned transaction payloads. Residency requirements that apply to signing material are satisfied by the fact that the customer share never leaves customer infrastructure and no full key is ever assembled. Requirements that apply to public chain data are satisfied by the fact that it is public.

​

Deployment Modes

Signing runs through 2-of-2 MPC regardless of how the MCP server is deployed. The WalletSuite-side MPC share runs on WalletSuite infrastructure (HSM-backed, M-of-N gated); the customer-side share is stored on customer infrastructure, encrypted at rest, and never leaves it. The MCP server placement is the deployment axis:

1. Hosted MCP server. The MCP server runs on WalletSuite infrastructure.
2. Self-hosted MCP server over HTTP. The MCP server runs on the customer’s own infrastructure. Suited to trading agents and regulated environments that need the agent runtime and the customer share on customer infrastructure. See Self-Hosting over HTTP.

Server placement is orthogonal to the signing-layer guarantee. In either mode no full key ever exists on WalletSuite infrastructure; the property is structural to 2-of-2 MPC, not a deployment-mode artifact.

​

Band Filtering as Prompt-Injection Defense

Band filtering is also a prompt-injection defense — enforced at the tool-visibility layer. Tools outside the active band are never registered with the MCP client. They do not appear in tools/list, do not have a callable handler, and cannot be discovered through any in-session negotiation. An agent compromised by a malicious prompt — a poisoned search result, a hostile tool output from another server, a user instruction that was actually an injected command — cannot call a tool that the client does not know exists. It cannot invent send_transaction if broadcast is outside its band. The enforcement point is the tool schema itself, not a runtime permission check. Bands are resolved once, at server startup, and reflected in the tools/list response the LLM receives. A model cannot reason around a tool that was never surfaced. See Band Filtering for the band hierarchy and configuration.

​

Verification Path

1. Architecture — Security Overview. Trust boundary, defense in depth, attack model.
2. Key lifecycle - Key Management. DKLS23 2-of-2 share custody, share storage, and signing flow.
3. Audit trail — Audit Trail. Receipt schema, hash chain, redaction model.
4. Build provenance — Build & Supply Chain. Signed releases, runtime response validation, secret boundary.
5. SDK source — public at github.com/walletsuite.

​

Incident Response

If you find a vulnerability, security@walletsuite.io is the canonical contact. The Responsible Disclosure page documents acknowledgment SLAs, severity definitions, and scope. For operational incidents on a customer deployment, the audit trail is the starting point. The hash chain lets an operator prove, after the fact, that no entries were inserted, modified, or removed. Exporting the trail to a SIEM preserves this property across longer retention windows than a single host.

​

Certifications Roadmap

Formal certifications are on the plan for procurement readiness. They do not change the architectural guarantees above. Auditors and target quarters will be published once engagements are signed. Until then, the architecture is the proof.

​

Related

• Security Overview — trust model and defense in depth
• Key Management - MPC share custody and key lifecycle
• Audit Trail — tamper-evident receipts
• Build & Supply Chain — signed releases and runtime validation
• Responsible Disclosure — reporting vulnerabilities