“Hold your own keys” is incomplete advice for a product team. It tells you who controls assets, but not who can authorize a payout, recover access after an incident, or explain a balance discrepancy to finance.
A non custodial software wallet leaves transaction authorization with the user or customer rather than a centralized custodian. For an institutional deployment, that promise only holds if the signing policy, recovery arrangement, and operating ledger preserve that control in production, including when devices fail, requests time out, or an operator makes a mistake.
Table of Contents
- The Single Secret That Decides Every Transaction
- Wallet Models Compared by Who Controls Signing
- How Key Shares and Ledger States Share Control
- How to Integrate Wallet Calls Without Duplicate Transactions
- Which Wallet Model Fits Your Product Type
- Risk Controls to Set Before Go-Live
- Buyer Questions About Non-Custodial Wallets
- Confirm Your Wallet Model Before Launch
The Single Secret That Decides Every Transaction
A single signing secret can authorize every transaction from a wallet. If possession of that secret is enough to sign, a stolen private key or leaked seed phrase can expose the associated balance. A compromised front end can also trick the legitimate holder into approving a harmful transaction without stealing the key.
Non-custody changes who bears this risk. It reduces dependence on an intermediary, but the user's device, application interface, and signing decisions still need protection.
The scale warrants attention. TRM Labs' 2026 Crypto Crime Report reported that private-key, seed-phrase, privileged-access, wallet-infrastructure, and front-end attacks caused USD 2.2 billion in losses across 45 incidents, representing 76% of reported crypto-theft losses.
Recovery expectations are part of the problem
Users may understand ownership but misunderstand recovery. A 2026 wallet-recovery study, based on 22 interviews and a 430-person follow-up survey, found that a considerable share of participants mistakenly believed a lost secret-recovery phrase could still be retrieved.
That belief can lead users to assume a provider will restore access after a failure. In a non-custodial arrangement, the provider may not have the authority or materials to do so.
The practical distinction: Ownership determines who has authority. Signing policy, recovery design, and the operating ledger determine how that authority is applied, restored, and accounted for. If the setup relies on a customer-controlled Co-Signer or recovery materials, the customer is responsible for protecting and operating them.
A wallet can execute a valid signature and still produce a disastrous business outcome. Non-custody shifts control and responsibility; it does not remove the need to design how transactions are approved, access is recovered, and balances are reconciled.
Wallet Models Compared by Who Controls Signing
| Model | Signing authority | Recovery path | Main failure mode | Typical fit |
|---|---|---|---|---|
| Custodial account | Provider holds the keys | Provider-run support and account reset | Provider failure, account freeze, or insolvency | Retail apps needing support-first recovery |
| Single-key software wallet | User holds one seed or private key | User-held seed phrase only in this model | Lost or leaked seed, phishing approval | Individual users managing small balances |
| Hardware wallet | User holds the key on a device | Seed backup kept offline | Device lost without backup, unsafe signing on a compromised computer | Individual holders and cold storage |
| Smart account (ERC-4337) | Contract logic enforces signer and spending policies | Recovery signers defined in the contract | Contract bugs, upgrade-authority misuse, weak recovery governance | Teams needing on-chain spending limits |
| MPC 2-of-3 with client Co-Signer | Three parties hold shares; two must cooperate | Surviving shares and the configured client-controlled Co-Signer recovery path | Policy misconfiguration, Co-Signer compromise, unclear approval rules | Product teams, treasuries, embedded wallet programs |
Read the table as a map of authority, not a security ranking. A hardware device changes where signing happens, but it doesn't automatically establish business approval rules. A smart account can enforce rules on-chain, but its recovery and upgrade permissions may introduce additional authorities.
For broader organizational context, Arch's Web3 explained for digital leaders is a useful companion when product and finance stakeholders need shared vocabulary before reviewing a technical custody design.
Evaluate the deployed configuration
BroSettlement provides MPC custody and embedded wallets. The asset custody model and each party's responsibilities depend on the service configuration and contractual terms, not just on the product name.
Make the authority review concrete:
- Normal operation: Identify everyone whose cooperation can produce a valid transaction.
- Recovery: Identify who can replace a signer or restore access.
- Exceptional access: Inspect administrative, upgrade, and emergency permissions.
- Exit: Establish what happens if a participant or service becomes unavailable.
Preference figures don't answer those questions. CoinLaw estimated that approximately 59% of global crypto-wallet users preferred non-custodial wallets in 2025, while 41% preferred custodial wallets; those are preferences, not evidence that a particular deployment preserves customer control.
The decisive test is straightforward: if another party can move funds without the customer's approval, including through a recovery or administrative bypass, the model is custodial regardless of its marketing.
How Key Shares and Ledger States Share Control
Start with the key lifecycle: generation, storage, backup, use, recovery, and destruction. Assets remain on-chain, but control of the authorization material determines who can move them.
NIST's key-management guidance explains why strong cryptography can't compensate for weak key management. Encrypting a wallet file helps protect stored material, for example, but doesn't protect a decrypted key that malware reads from application memory.
Distribute signing without losing accountability
NIST's threshold-cryptography guidance describes secret-sharing a private key across participants and performing operations distributively; in a 2-of-3 arrangement, two participants must cooperate, while one unavailable participant can be tolerated. No participant needs to reconstruct the complete key during normal signing.
Consider a customer signing service becoming unavailable during maintenance. A properly configured surviving quorum can preserve continuity, but only if its cooperation is permitted by the customer's approval policy. Availability isn't permission to bypass approvals.
BroSettlement combines distributed key generation, MPC signing, network submission across 10 networks, and a customer-controlled Co-Signer. Our MPC wallet guide provides additional context for evaluating that operating model.
For Ethereum-compatible deployments, a smart-account layer can add executable authorization rules. Ethereum's account-abstraction research describes capabilities including modular authorization and recovery; an ERC-4337 account can implement spending limits, recipient allowlists, and delayed withdrawals.
The trade-off is explicit: authorization becomes executable code. Contract correctness, upgrade authority, and recovery signers need governance comparable to the signing materials themselves.
Record settlement separately from authorization
A signed transaction isn't a settled payment. Record chain activity through observed, pending, confirmed, or rejected states, using append-only entries rather than overwriting a balance without history.
For example, a detected deposit can appear in an operational view while remaining unavailable for withdrawal. Bitcoin's payment-processing documentation recommends at least six confirmations for high-value or fraud-sensitive payments, a policy convention rather than a universal guarantee.
Set release rules by network, asset, value, and risk. Don't apply a Bitcoin confirmation convention indiscriminately to other networks.
Our operational log records wallets and transactions for reconciliation and audit. It supports evidence about authorization and settlement, but doesn't itself create blockchain signing authority.
The threshold determines who must cooperate. The recovery process and audit trail determine whether that cooperation remains accountable.
How to Integrate Wallet Calls Without Duplicate Transactions
A timeout means the caller doesn't know the result. It doesn't mean the payout failed, and generating another withdrawal can turn an availability incident into a financial loss.
Our integration interface provides REST API, Ed25519 authentication, and WebSocket events. Build the command path and reconciliation path together, with durable records between them.
Build a retry-safe command path
Issue a scoped API key. Give each service only its required actions and restrict access with an IP allowlist. This limits the reach of a compromised worker or leaked credential.
Authenticate each request. Use Ed25519 authentication and enforce replay protection, binding authentication to the request being executed. A valid signature alone shouldn't allow an intercepted request to execute repeatedly.
Persist idempotency before execution. Save the key with the business command, amount, destination, and status before sending the withdrawal. Stripe's idempotency documentation recommends high-entropy keys such as version-4 UUIDs and retains results for at least 24 hours, illustrating why retries must reuse the same key and parameters within the actual provider's documented retention window.
Record the initial deposit observation. Write an observed ledger entry and preserve its chain identifier before performing downstream work. This prevents a notification from becoming an untraceable balance adjustment.
Consume WebSocket events durably. Subscribe to deposits, confirmations, withdrawals, and policy outcomes, and deduplicate event processing. Treat delivery as a notification, not proof that your database committed an update or that the network settled a payment.
Apply the configured release threshold. Move a record to confirmed only when the relevant asset-and-value rule is satisfied. This prevents an early observation from becoming spendable credit prematurely.
Reconcile independently. Compare ledger records with chain records on a schedule and replay missed activity after connection failures. Bitcoin Core's transaction-notification documentation illustrates tracking transactions until a target confirmation count is reached rather than relying on a single notification.
Force failures in the sandbox. Test timeouts after submission, duplicate deliveries, out-of-order updates, and worker restarts. These exercises expose duplicate payouts, lost events, and drifting balances before live funds are involved.
Test behavior, not just successful responses
Use AskYourQA's API contract and functional testing guidance to structure assertions around request semantics and failure behavior. A successful HTTP response isn't sufficient evidence that retry handling is safe.
Our crypto wallet SDK guide is useful when mapping application calls to this workflow. Keep a stable business-command identifier across workers so finance can trace a payout without reconstructing application logs manually.
Which Wallet Model Fits Your Product Type
| Product type | Recommended model | Controls to require | Compliance load |
|---|---|---|---|
| Crypto exchange or trading platform | MPC wallets with a client-controlled Co-Signer | Signing policy, withdrawal limits, reconciliation | AML screening, audit trails, role-based access |
| Neobank or fintech app | Embedded MPC wallets per user | Role-based access, real-time event alerts | KYC, AML screening, audit trails |
| Payment gateway or PSP | Per-merchant MPC wallets with an operating ledger | Idempotent payouts, policy check before signing | Settlement records, reconciliation evidence |
| iGaming operator using USDT on TRON | TRC20 deposit address per player | Operator policy before payout signing, deposit.confirmed events | Player balance reconciliation, applicable local gaming rules |
| AI agent product | Per-agent wallets with MPC control, in development | Scoped keys, spending limits, audit trail | Agent action logs, approval records |
| Enterprise treasury | MPC quorum with client-controlled Co-Signer | Quorum signing, delayed withdrawals | Approval records, role-separation evidence |
These are operating recommendations, not determinations of legal status. Read each row by asking who must approve an outflow and who must explain it later.
Player wallets need event-to-balance discipline
Our iGaming scenario supports a TRON/USDT wallet and TRC20 USDT deposit address per player account, without a custodial PSP. The application receives deposit.observed and deposit.confirmed events in real time, while an operator policy runs before a payout is signed.
A concrete flow starts with matching an incoming transfer to the player's address. The operator records the observation, applies its credit-release rule on confirmation, then evaluates a later withdrawal against its payout policy.
The append-only log links these actions to player balances. That matters because detecting a transfer, crediting a player, and approving a payout are separate business decisions.
Agent wallets need bounded authority
Our AI Agent Wallets, with MPC control and gas abstraction, are currently in development. The intended per-agent model combines role-based access and audit trails rather than giving an autonomous process unrestricted treasury access.
Consider an agent proposing payment for a purchased service. Its application should submit a bounded payment intent, obtain the required approval, and retain the agent action and policy outcome with the resulting transaction.
For exchanges and PSPs, per-user or per-merchant records make attribution and reconciliation manageable. Treasury teams need deliberate approvals rather than consumer-style convenience.
If the same team can approve a payout and independently certify its reconciliation without review, the design has a control gap regardless of wallet type.
Risk Controls to Set Before Go-Live
Launch readiness requires evidence that controls work, not merely that configuration fields exist. Use a signing-policy review and a recovery drill as release gates.
Require controls around every authorization
- Transaction simulation: Show readable recipients, asset movements, contract calls, and approval changes before signing to expose unexpected effects.
- Address-book allowlists: Restrict destinations to approved recipients to reduce substitution and misdirection.
- Spending limits: Enforce per-period budgets so a valid credential can't authorize unlimited outflows.
- Delayed withdrawals: Hold transactions above your defined threshold to create time for independent intervention.
- Role separation: Keep payout proposal, approval, and recovery authority distinct to prevent unilateral misuse.
- Independent policy review: Have someone outside the implementation team inspect signer permissions and exception paths.
- Phishing-resistant authentication: Protect operator access against credential capture rather than relying only on passwords.
- Signing monitoring: Flag unusual volumes, destinations, and operating hours for investigation.
- Sandbox and pause plan: Prove that operators can stop new submissions and restore service safely, without assuming broadcast transactions can be rolled back.
Our wallet security guide provides context for comparing protections across wallet designs.
Make the responsibility boundary explicit
The customer is responsible for correct wallet addresses, network and asset selection, amounts, recipient data, transaction instructions, and its own compliance and risk decisions. Blockchain transactions may be irreversible.
Where the configuration uses a customer-managed Co-Signer or customer-controlled signing or recovery materials, the customer must operate and protect those components. That includes access control, backups, and approval rules.
Our liability terms exclude losses caused by customer instructions or controls, a customer-managed Co-Signer, compromised customer credentials, unsupported workflows, external blockchains, or third-party systems, unless directly caused by our own breach of the terms. Treat that allocation as an operational boundary when assigning owners, not as a substitute for incident planning.
The practical lesson is to separate who can sign from who can recover, then test both paths. A backup that nobody has restored and a recovery policy nobody has exercised aren't launch evidence.
Buyer Questions About Non-Custodial Wallets
Can the provider recover my funds if access is lost?
No, not by default in a pure non-custodial design. Recovery depends on the path you configured, the surviving authorization materials, and the customer-controlled Co-Signer where that arrangement applies.
Who pays network fees?
You do, through the wallet that initiates the transaction. Network fees are debited from that wallet, we add no separate third-party fee, and you must keep enough of the required fee asset available because the blockchain fee is independent of us and can change between estimation and execution.
Is BroWallet available now?
No, BroWallet is listed as coming soon, including its planned AI agent wallet positioning and Telegram, web, and mobile interfaces. BroWallet and BroCard are separate products: website mentions don't grant access or include their future features in BroSettlement, and separate terms will apply when they become available.
Does non-custody remove compliance work?
No, non-custody doesn't remove the customer's compliance responsibilities. AML screening, audit trails, role-based access, and regulatory decisions still need accountable owners; technical infrastructure supports those workflows rather than replacing them or making us the customer's legal advisor.
Who operates the application after integration?
Your team remains accountable for its application operations, even when it delegates defined support tasks. Grail Computer Labs' explanation of what application management services cover helps distinguish ongoing application maintenance from custody authority, transaction approval, and recovery ownership.
Confirm Your Wallet Model Before Launch
Apply the who-signs, who-recovers, who-explains rule to a sandbox demonstration, not just an architecture slide. The deployment should remain understandable when a signer is unavailable, an event arrives late, or a worker retries a completed command.
Bring evidence for the launch decision
- Name the signing quorum: Document the Co-Signer owner, permitted participants, recovery owners, and the approvals needed to change them.
- List the ledger states: Demonstrate observed, pending, confirmed, and rejected outcomes, with identifiers connecting business commands to chain activity.
- Run duplicate and retry tests: Show that repeated requests and notifications don't create extra payouts or unsupported credits.
Finance should be able to trace a transaction without asking engineering to interpret an unstructured log dump. Operations should know which component to pause, while compliance should be able to retrieve the relevant approval evidence.
Our engineers help design wallets, operating logs, signing policies, and events from start to finish. The hands-on path from sandbox to go-live includes console setup and fee calibration, with BroSettlement and the API documentation on our website providing the technical detail.
Choose the configuration whose failure behavior your team can demonstrate. A successful transfer proves connectivity; a controlled failure proves much more about readiness.
BroLabel offers embedded MPC wallet infrastructure, customer-controlled Co-Signer integration, and operational logs for building accountable transaction flows. Visit BroLabel to plan a BroSettlement sandbox covering your signing policy, recovery ownership, event handling, and reconciliation checks. Bro has your back!
