What an MPC Team Wallet is#
An MPC Team Wallet is a self-custodied wallet managed jointly by your Team. It uses MPC threshold signatures (MPC-TSS) to manage keys: the private key is generated in distributed form as three shards, signing never reassembles it, and the complete private key is not constructed at any point.One of the three is the local key shard, generated and stored on a member's mobile device and held by that member alone. The other two are cloud key shards, generated and stored encrypted on DeepSafe MPC Nodes. Core signing operations are performed in a Trusted Execution Environment (TEE), such as AWS Nitro Enclaves, where key shards and sensitive computations remain isolated from the host operating system.Before a transaction enters the signing stage, it must pass validation against the policies your Team has configured. Transactions that fail validation do not proceed to signing.Compared with a single-user wallet, an MPC Team Wallet has no "one key, one person decides" situation — moving assets requires the Team to act together under the rules it has set. Compared with on-chain multisig, an MPC signature appears on-chain as an ordinary signature, so it is not limited by whether a given chain supports multisig contracts, and the address does not change when participants change.If your organization stops using DeepSafe, you can still regain control of your assets through the platform's offline recovery method, without relying on DeepSafe services.It suits organizations that manage assets collaboratively, need internal approvals and permission separation, and want to hold their own keys — trading platforms, asset managers, payment institutions, token issuers, and proprietary trading desks.Teams, wallets, and members#
A Team is the basic unit for using DeepSafe. Assets belong to the Team, not to any individual member.Team Wallets are created within a Team and hold its assets. A Team can create multiple wallets to separate business purposes.Members are the people in a Team. Members act through the permissions granted to them. Members joining or leaving does not change wallet addresses, nor does it affect the Team's control over its assets.Roles and permissions#
Team Creator — creates the Team and holds all permissions. The Team Creator role cannot be transferred.Admin — holds all Member permissions and votes on key Team decisions. Admin permissions are fixed: they are not set when inviting and cannot be adjusted afterward. A Team can have up to 7 Admins.Member — permissions are set by the person who invites them. Permissions fall into wallet permissions and management permissions, granted individually. No permissions are granted by default.One point deserves emphasis: permissions in DeepSafe are not just configuration. Granting a member the permission to approve transactions means that member receives the key shard needed to participate in signing; revoking that permission invalidates the corresponding shard. This is why permission changes require approval and take time to process.Approval and signing#
Approval is a person deciding whether a transaction or change should go ahead. It operates at the governance level.Signing is the holders of key shards participating in cryptographic computation to jointly produce a transaction signature. It operates at the cryptographic level.A transaction needs both because they answer different questions: approval decides whether the transaction should happen; signing determines whether it can be broadcast. An approved but unsigned transaction is not broadcast, and an unapproved transaction never reaches signing.Before signing, each participating member independently verifies that the content to be signed matches the transaction information shown at approval. If they do not match, signing stops.Decision Mode#
Decision Mode sets how many Admins must agree before a key Team decision takes effect — an m-of-n rule where n is the total number of Admins and m is the number of approvals required.Decision Mode governs changes to Team configuration: activating transfer policies, configuring whitelists, configuring API Keys, changing member permissions, removing members, and changing Decision Mode itself.Decision Mode and transaction approval are different things. Decision Mode governs changing the rules; transaction approval governs releasing an individual transaction. The first is determined by Decision Mode, the second by the Policy Engine and Approval Nodes. They do not overlap.Policies and whitelists#
Policies answer the question "which transactions should be stopped for a closer look." Your Team configures rules based on initiator, source wallet, destination address, token and network, amount, and frequency. Matched transactions are blocked or routed to approval.The Address Whitelist answers "which addresses do we recognize as counterparties." A whitelist accumulates address identity information; by itself it does not decide whether a transaction is released or blocked.Policies own the outcome. A whitelist can serve as one condition in a policy — for example, a rule requiring approval for transfers to addresses outside the whitelist — but the whitelist itself does not determine whether a transaction goes through. Approval Nodes then define who reviews a matched transaction and how many approvals are needed. In short: policies evaluate conditions, whitelists supply the evidence, Approval Nodes carry out the process.Two rules govern how policies are evaluated. When several policies match, they are evaluated in priority order. A transaction that matches no policy is blocked — the Policy Engine denies by default, so any transaction your Team needs to allow must be covered by a policy.An unknown address is any address that is neither in the whitelist nor one of your Team Wallets. It can be configured as a destination condition in its own right.Mainnet, testnet, tokens, and networks#
Mainnet is the live blockchain network, where assets have real value. Testnet is for testing; assets there have no value and cannot be exchanged for mainnet assets. We recommend getting familiar with the workflow on testnet before going live.Token and network are two separate dimensions. A token is the asset itself; a network is the blockchain that carries it. The same token may be issued on several networks — USDT, for example, exists on Ethereum, TRON, and others. These share a name but are independent assets on different networks.Choosing the wrong network causes asset loss. If the sender uses a network that does not match the network of the receiving address, the assets may never arrive and usually cannot be recovered. Confirm that both sides are using the same network before sending a transfer or sharing a receiving address.App and Web Console capabilities#
DeepSafe provides a mobile app and a Web Console.The app is the security root. Key shards are generated and held there, and every key-related operation happens on the app.The Web Console is designed for day-to-day operations and management, with an interface better suited to bulk actions and reviewing information. Signing in requires scanning a QR code with the app; account credentials alone cannot be used. After scanning, you select the Team to enter — Teams that have not been activated in the app cannot be opened.The two clients do not have identical capabilities. They divide as follows:App only — member management, key shard management, transaction signing, and final confirmation of all approvals.Web Console only — editing transfer policies, API Key management, and the Audit Log.Both — wallets and assets, transfers, whitelists, Approval Nodes, Gas Service, and transaction records.Some operations require both clients. Editing a transfer policy, for example, is submitted in the Web Console, which then generates a QR code for an Admin to scan in the app to complete approval.Each document states which client applies at the top. If you cannot find an entry point on one client, check that note.Modified at 2026-09-04 02:37:40
