Digital Asset Custody and Wallet Infrastructure Report 2026

Custody is a control architecture

Reliability depends on who can authorize movement, which operating rules surround that authority, and whether a tested recovery path remains available when a normal dependency fails.

Digital asset custody is often reduced to a label such as self-custody, qualified custody, MPC, cold storage, or smart account. Those labels describe only one layer. A complete architecture must explain who can create a valid signature, who can change the approval rules, where key material lives, which systems observe and reconcile movements, and what happens when a signer, provider, chain connection, or customer application is unavailable. Range's report is useful because it separates custody models, technologies, and the operating stack instead of treating them as synonyms. [1]

The first question is authority. Possessing one key share may provide participation without control, while a party holding enough shares to meet a threshold may have unilateral authority even if a customer also keeps a backup share. The second question is dependency. A customer can control signing material and still depend on hosted policy engines, account records, interfaces, blockchain nodes, or legal agreements. The third question is evidence. A documented feature is not the same as a demonstrated control, and a cryptographic design does not prove that backups, access management, or incident response work in a real deployment.

This report therefore evaluates architectures through four connected tests: signing authority, operational responsibility, recovery independence, and evidence quality. It does not assign a universal security score. A model can be appropriate for one asset pool and unsuitable for another because liquidity needs, legal obligations, transaction frequency, staffing, and recovery expectations differ. The practical objective is to make every trust boundary explicit enough that a product, security, operations, and compliance team can each identify the work it owns.

Four custody models distribute authority differently

Self-operated infrastructure, third-party custody, exchange-held assets, and hybrid control create different combinations of signing power, legal reliance, and operational work.

In a self-operated model, the organization runs the key infrastructure and designs its own approval and recovery arrangements. This can give direct technical authority, but it also concentrates responsibility for devices, software, access, backups, monitoring, staffing, and incident response. Self-custody is therefore not the absence of dependencies. It replaces a contractual dependency on a custodian with a larger internal operating obligation and with dependencies on chosen hardware, software, networks, and service providers.

A third-party custodian accepts a mandate to safeguard or execute movements under a specific entity, agreement, jurisdiction, and product configuration. The legal status of assets, withdrawal process, insurance, sub-custody chain, insolvency treatment, and service continuity cannot be inferred from the word custodian alone. Exchange-held assets add venue exposure because trading access and withdrawal execution sit inside the same commercial relationship. Exchanges may be operationally useful for liquidity, but limits and exit routes must reflect the concentration created by that convenience.

Hybrid arrangements divide signing or recovery authority across a customer and a provider, or combine different storage tiers. The category is too broad to determine control by itself. A 2-of-2 wallet, a 2-of-3 design where one party holds two shares, and a 2-of-3 design where the customer controls an independent two-share recovery quorum are materially different. The model table below focuses on who can act, which dependency remains, and what the customer must operate. It intentionally avoids labels such as highest security or no risk because those claims require a common test method that the available evidence does not provide.

Six technologies solve different parts of the system

EOAs, multisig, MPC, HSMs, TEEs, and smart accounts can be combined. None defines the complete custody or operating model.

An externally owned account authorizes blockchain actions with a private key. Its apparent simplicity moves complexity into key generation, storage, transaction construction, access, and recovery. Multisig accounts move the threshold into on-chain account logic. For systems such as Safe, owners and thresholds are configurable, signatures can be collected before one execution call, and modules can add separate execution paths. Multisig therefore cannot be summarized as one on-chain approval transaction per signer or as a design that always requires a new wallet for every owner change. [5]

MPC distributes signing computation across participants. Distributed key generation can create shares without first assembling a complete private key, while imported-key workflows may begin from different assumptions. The threshold and share ownership determine authority, not the number of shares visible in a diagram. An HSM protects key operations inside specialized hardware or a managed hardware service, but deployment decides whether the organization or a provider controls the signing interface. AWS CloudHSM, for example, documents PKCS#11 operations for key generation and signing; that says nothing by itself about the surrounding business approval model. [2, 6]

A trusted execution environment isolates code and data inside a protected compute boundary, yet the security claim depends on hardware, attestation, software supply chain, administration, and failure handling. Smart accounts add programmable authorization, batching, recovery, and policy paths at the account layer. EIP-7702 allows an EOA to set a code delegation that persists after the authorizing transaction until it is changed or cleared. It should not be described as automatically temporary or as support available in any wallet product without direct evidence. [7]

Technology selection should follow the authority model and operating need. A treasury may combine cold HSM-backed reserves with MPC operational wallets. An application may use a smart account on one network and an MPC-controlled EOA on another. A regulated custodian may use MPC internally while customers experience a contractual approval process. The relevant comparison asks what the technology protects, who administers it, how changes occur, which execution paths exist, and whether recovery has been rehearsed.

Key shares matter only through the threshold

A share is participation material. Control comes from a sufficient quorum, the administrative domains behind it, and the rules governing its use.

Threshold notation must be read literally. In a 2-of-3 arrangement, any permitted pair can create a valid signature. If a provider controls two active shares, it may already have a sufficient quorum even when a customer controls the third. The customer's share may improve backup options or participate in selected workflows without providing veto power. Conversely, if the customer controls two shares in separate domains, it may have an independent recovery quorum, but the security benefit of separate compromise domains disappears if the two shares are routinely co-located or accessible through the same compromised administrator.

Administrative separation is therefore part of cryptographic meaning in practice. A complete share map connects each share to a legal owner, infrastructure boundary, access group, backup location, encryption context, intended path, and operating state. A diagram showing three letters without those facts can create false comfort. The same scrutiny applies to policy changes: whoever can replace a signer, lower a threshold, enable a module, or change destination rules may hold a form of control that is not visible in the signing quorum.

DKG changes the generation story, but it does not complete the operating design. The participants still need authenticated communication, durable encrypted storage, access rotation, backups, and evidence that all required artifacts correspond to the same wallet generation. A recovery exercise verifies this relationship before an incident. If a procedure first discovers that Share B, Share C, a passphrase, or network metadata is missing during a provider outage, the theoretical quorum did not create an operational recovery capability.

The operating stack begins before signing and ends after confirmation

Wallet creation, transaction intent, approvals, signing, network delivery, event handling, accounting records, and reconciliation form one continuous control path.

A valid signature proves that the selected cryptographic authorization condition was met. It does not prove that a payment was permitted by the business, that the destination passed screening, that the right legal entity funded it, that a chain accepted it, or that the customer's balance was updated correctly. Custody architecture becomes operational only when transaction intent, approval context, signer state, network state, and financial records can be connected without relying on manual interpretation after every movement.

Liquidity design determines which wallets must be available for frequent movement and which assets can tolerate slower controls. Hot, warm, and cold are operational descriptions rather than universal security grades. A high-frequency payout wallet may justify automated policy within strict limits, while long-term reserves may require a slower ceremony and different personnel. The ledger or operating journal must then preserve the obligation created by each action: who requested it, which account supplied value, what fee was charged, which network transaction resulted, and how reversals or failures are represented.

Blockchain delivery is also a lifecycle, not a binary broadcast. Transactions can remain queued, be signed but not submitted, enter a mempool, be replaced, fail, confirm, or be affected by a reorganization. Event consumers need idempotency because messages can be repeated or arrive after a temporary disconnect. Reconciliation must compare the on-chain outcome with internal obligations and account for pending states, fees, unsupported assets, and manual corrections. Range's operating stack makes this broader responsibility visible, while the implementation details belong to each product and customer process. [1]

Policy, monitoring, and response are separate controls

A pre-signing decision can prevent an action, monitoring can detect a pattern, and incident response can contain damage. No one layer substitutes for the others.

Pre-signing policy evaluates the facts that define a permitted movement: organization, role, asset, network, amount, destination, counterparty, time, velocity, and approval state. A callback or policy engine provides a place to make that decision, but the existence of an integration point does not prove that the customer's rules are complete. Effective separation of duties, destination controls, limits, emergency holds, and change management depend on the configuration and on the people allowed to alter it.

Monitoring answers a different question: what is happening across wallets, signers, APIs, users, and networks? Useful signals include failed authentication, unusual destination changes, signer unavailability, queue growth, delayed confirmations, repeated nonces, balance differences, and recovery-material access. WebSocket events and audit records can supply evidence, but they do not automatically create anomaly detection, sanctions screening, alert ownership, or a response procedure. A complete monitoring design includes explicit thresholds, routing, escalation, and evidence retention.

Response turns detection into a controlled state change. That may mean pausing a customer flow, rotating API credentials, disabling a signer, lowering wallet exposure, changing a network route, or beginning a recovery ceremony. Each action has a different owner and blast radius. A recovery path that moves assets but leaves the application without its operating journal may protect value while creating accounting and customer-service problems. A complete runbook names the layer being restored and the evidence required before normal operation resumes.

BroSettlement maps to a client-managed hybrid MPC model

Routine A+B signing joins BroSettlement infrastructure with a customer-hosted Co-Signer. The customer separately controls B and C for an independent recovery quorum.

BroLabel develops BroSettlement, so this section is a disclosed product example rather than a neutral assessment of an unrelated vendor. The public documentation describes embedded MPC wallet infrastructure with DKG, 2-of-3 threshold signing, a customer-hosted Co-Signer, API-authenticated transaction operations, an operating journal, and lifecycle events. Our architectural classification is client-managed hybrid MPC because routine authority spans BroSettlement and infrastructure operated by the customer. That classification does not establish the legal status of a deployment or replace a regulated custodian where one is required. [2, 3]

Share A is held in BroSettlement infrastructure. Share B is encrypted material used by the customer's Co-Signer in the normal A+B path. Share C is separate customer-controlled recovery material kept outside the active Co-Signer environment. A single share is insufficient. In normal operation, the customer Co-Signer polls outbound for signing work and can call a customer policy endpoint before participating. The platform cannot form a valid signature with A alone under the documented distribution. This is a conclusion from product documentation, not an independent validation of the cryptographic implementation. [2, 3, 4]

The product boundary extends beyond signing into wallet and transaction operations. Public material describes organization-scoped access, Ed25519 request authentication, RBAC, IP allowlisting, nonce checks, enabled assets and networks, WebSocket events, and journal records. These capabilities provide building blocks for an embedded wallet product, but the customer still owns user mapping, approval design, destination and counterparty rules, regulatory analysis, exception handling, and reconciliation to its own obligations. BroSettlement is infrastructure inside the customer's product, not an OTC desk or a complete compliance service. [2, 3, 8]

Recovery must name the dependency it removes

BroSettlement's B+C path can remove Share A and the BroSettlement API from asset-access recovery. It does not automatically restore the service, journal, events, or customer application.

The customer-controlled B+C quorum is intended to authorize recovery without BroSettlement participation. The currently public disaster-recovery tooling documents one native TRX or standard TRC-20 transfer on TRON mainnet or Nile, using matching Share B and Share C artifacts plus the original encryption material. This is the present public implementation boundary as checked on September 14, 2026. It should not be generalized into current tooling for every network or asset. [4]

The next step is to bring the same customer-controlled B+C recovery model to every blockchain supported by BroSettlement. The roadmap extends a clear operating principle: customers retain an independent path to their assets when the platform is unavailable. Current implementation details and network coverage are documented in the recovery guides. [4, 11]

Asset-access recovery is narrower than service continuity. A successful B+C transfer can move assets to a destination controlled by the customer, but it does not recreate wallet APIs, restore journal history, replay events, rebuild user balances, reopen customer withdrawals, or recover the customer's own application. Those outcomes require backups, alternate infrastructure, reconciled records, communication procedures, and tested responsibilities. No SLA, RTO, or RPO for this broader recovery was established in the reviewed evidence.

A useful recovery test therefore has three layers. First, cryptographic recovery verifies that the quorum and artifacts can sign. Second, network recovery verifies that a supported transaction can be constructed, funded for fees, delivered, and confirmed. Third, operating recovery verifies that internal records, customer obligations, permissions, and support processes reach a known state. Passing the first layer is necessary evidence, but it is not proof of the third.

Configurations reveal more than company names

Provider portfolios can contain several authority models. A useful comparison identifies the exact product, threshold, execution layer, recovery path, and evidence date.

Range distinguishes Fireblocks Direct Custody 3-of-3 from Embedded Wallets 2-of-2, yet broader market comparisons can lose that distinction when they compress a provider into one row. The two configurations do not assign customer and provider authority in the same way. The relevant evidence is the current documentation for the specific workspace and product under review; this report uses the distinction only to show why company-level labels are insufficient. It does not audit Fireblocks or generalize one configuration across its portfolio. [1, 9]

Safe illustrates a different layer. Its smart-account design exposes owners, threshold, transaction execution, and modules on-chain. A Safe account can participate in a custody arrangement, but the account contract does not define who legally controls each owner, where signer material is stored, how approvals are staffed, or how off-chain books are reconciled. Similarly, an HSM product describes a protected signing environment, not a complete custody service. Architecture comparisons need to align layers before they compare features. [5, 6]

The configuration table below records only the properties supported by the cited documentation. Not verified means the review did not establish that fact; it does not mean the capability is absent. This treatment avoids converting missing evidence into a negative score. It also prevents a documented source repository, policy callback, or recovery procedure from being presented as proof of certification, insurance, operational performance, or legal qualification.

Operational fit starts with the asset flow

Embedded wallets, treasury, exchange liquidity, and regulated safekeeping need different authority, availability, recordkeeping, and recovery designs.

An embedded stablecoin wallet is a strong example of a high-frequency operating flow. The product operator maps a wallet to a user or business account, observes deposits, waits for its required confirmation policy, credits an internal obligation, checks a payout request, participates in signing, delivers the transaction to an enabled network, consumes lifecycle events, and reconciles the final outcome. The wallet infrastructure supplies addresses, signing, events, and records. The operator owns the customer experience, business limits, financial crime controls, customer balances, and exception handling.

Treasury usually contains several pools with different movement needs. Operational balances may prioritize controlled availability, while strategic reserves prioritize reduced exposure and deliberate ceremonies. Exchange balances may be necessary for execution but should be limited by venue, asset, and withdrawal dependency. Regulated safekeeping may be required when the business needs a licensed entity, specific asset treatment, reporting, or contractual protection. A wallet component with shared signing does not automatically supply those legal and institutional functions.

The correct design may be a portfolio rather than one winner: customer-facing operational wallets, a separate reserve arrangement, controlled exchange exposure, and a documented path between them. Each transfer between tiers needs ownership, approval, timing, limits, and reconciliation. The purpose of the architecture is not to maximize one abstract form of control. It is to place the right authority and dependency around each asset flow while keeping the full position explainable.

Legal conclusions and evidence need exact boundaries

Signing design is relevant to legal analysis but does not decide it. Documentation supports architectural claims, while audits, certifications, performance, availability, and recovery outcomes require their own evidence.

A provider's inability to sign alone can be an important boundary, but it does not by itself establish whether an arrangement is custody, outsourcing, technology supply, or another regulated service. Legal analysis may examine contractual authority, possession or control concepts, asset segregation, insolvency treatment, customer disclosures, operational discretion, and the exact entities involved. The answer can differ by jurisdiction, asset, and customer type. The technical facts remain useful when they are kept separate from unsupported licensing conclusions.

The same discipline applies to accounting changes. In the United States, SEC Staff Accounting Bulletin 122 rescinded the interpretive guidance included in SAB 121. That change concerns prior staff accounting guidance; it does not grant a general custody authorization, insure digital assets, or establish the legal status of a particular provider. Any statement about balance-sheet treatment or safeguarding obligations needs current accounting and legal analysis for the reporting entity. [10]

Evidence requests should be matched to the claim. A licensing claim needs a regulator or registry record for the named entity and scope. A certification claim needs the certificate, period, and system boundary. An insurance claim needs policy scope and exclusions. An asset-segregation claim needs contracts and operating records. A cryptographic control claim needs design and implementation evidence. Broad compliance language without these links obscures the decision instead of simplifying it.

This review used Range's framework, public product documentation, normative specifications, and official technical guidance. Those sources support descriptions of intended architecture and documented interfaces. They do not independently confirm cryptographic correctness, secure deployment, uninterrupted availability, customer configuration, or the outcome of a recovery exercise. No live signing transaction, recovery transfer, penetration test, control audit, or customer evidence review was performed for this report.

For BroSettlement, the reviewed evidence did not establish an independent security audit, SOC 2 report, ISO 27001 certification, insurance coverage, qualified-custodian status, MiCA authorization, signing latency, throughput, SLA, RTO, or RPO. No such claim is made. Access to Co-Signer source can assist technical review, but source availability is not an audit of every platform component. A documented recovery command is evidence of a designed path, not proof that every customer has stored the right materials or rehearsed the procedure. [2, 3, 4]

Evidence also expires. Supported assets and networks, signer versions, APIs, legal entities, certifications, and recovery tools can change after publication. The fact-check date on this report is September 14, 2026. A launch or procurement decision therefore depends on a renewed check of the exact product configuration, with the version, date, scope, and source recorded for every material assertion. Unknown remains unknown until the relevant evidence exists.

A decision starts with authority and ends with rehearsal

The strongest architecture is the one a specific organization can explain, operate, observe, and recover under its real legal and staffing constraints.

A sound decision begins with the asset and obligation: who owns the asset, who owes value to whom, which entity operates the product, how frequently the asset must move, and what loss of access would mean. The analysis then covers every execution path, including the normal signing quorum, emergency quorum, policy administrator, credential administrator, signer hosts, account modules, provider actions, and network dependencies. A path that exists only in a diagram remains a design claim until its required artifacts and responsibilities are verified.

The next layer connects signing to operations through transaction states, idempotency, destination and counterparty rules, exposure limits, journal entries, event ownership, reconciliation, and exception queues. A complete design identifies which controls remain available during a provider, signer, API, or chain outage. The behavior of balances and customer communications after a delayed, late-confirmed, replaced, or independently recovered transaction reveals whether the organization controls the complete flow or only the signature.

The final layer is claim-specific evidence and rehearsal. Technical diagrams, contracts, licenses, audit reports, certificates, insurance terms, deployment records, monitoring data, and recovery results answer different questions and need named owners and review dates. Results from normal and recovery paths with representative assets show what remains unavailable at each stage. The central conclusion is simple: cryptographic technology can strengthen a control boundary, but reliability comes from aligning authority, operations, evidence, and tested recovery around the actual product.