CHAPTER 05
Wallets and Digital-Asset Control
Wallet capability, customer authority, and policy-aware asset operations without exposing the wallet's proprietary mechanisms.
- Participants
- Policy
- Signing controls
- Wallet authority
- Digital assets
A wallet is an authority boundary as well as an asset interface. An address alone does not explain who may authorize an operation, which network it belongs to, how organizational policy applies, or which responsibilities arise if normal access is interrupted. Hybrid-Chain's wallet offering is presented around those operational questions.
The role of MPC
Multi-party computation provides a foundation for distributed participation in cryptographic operations. In a wallet context, its value must be assessed alongside customer authorization, operating responsibilities, and the supported lifecycle. Hybrid-Chain's public description focuses on those capabilities and their integration. The proprietary details of wallet construction, signing coordination, key lifecycle, and recovery are not specified here.
A deployment's custody and authority model must be stated explicitly. Who operates infrastructure, who authorizes an action, and who controls recovery are separate questions. Neither the use of MPC nor a self-custody label is sufficient to answer them. An organization should establish its actual responsibilities before relying on a particular wallet arrangement.
Wallet roles and control models
Wallets serve distinct business purposes, but a business role must not be confused with a signing technology. Treasury custody, merchant collection, and collateral allocation describe why funds are organized; MPC describes a signing-control model; AI Wallet Control evaluates proposals under policy. These layers can coexist.
| Role or control | Business purpose | What to establish |
|---|---|---|
| Treasury or asset vault | Organize holdings and the primary destination for an organization's funds. | Ownership, authorized operations, recovery responsibilities, and network. |
| Rotational merchant wallet | Separate merchant collection from primary treasury operations. | Merchant allocation, independent MPC authority, and settlement to the workspace's primary treasury on the same network. |
| Collateral or margin allocation | Associate eligible value with a defined obligation or exposure. | The enabled product's valuation, reservation, release, and loss rules; not a universal wallet capability. |
| MPC signing | Distribute participation in authorized cryptographic operations. | Activation, threshold authority, and current signing readiness. |
| AI policy evaluation | Evaluate a workload's proposed action against permissions and budgets. | A decision is not a signature, reservation, broadcast, or payment. |
Balances, collateral, and buying power
A recorded holding, an available balance, eligible collateral, and buying power answer different questions. A deposit may be observed before its reserve evidence is accepted. Accepted value may still be reserved for another obligation. A product may apply eligibility and valuation rules before treating it as collateral. Buying power, where an enabled product defines it, is a product-specific limit rather than a synonym for the wallet balance.
An integration should retain the asset and network, valuation source and time, applicable adjustments, existing commitments, and the authority for allocation or release. Follow an allocation through reservation, settlement or cancellation, and reconciliation. This edition does not promise leverage, a lending facility, or automatic conversion of holdings into spendable credit. The earlier MarginWallet terminology describes a role to evaluate, not a guarantee that a margin product is currently enabled.
Assets in their network context
Wallet and portfolio discovery help an application understand relevant assets and networks. They do not establish that every discovered asset supports every operation. Enrollment, receiving, fee information, withdrawal, signing, and broadcast have different requirements. The enabled capability for the exact wallet, network, asset, and operation is what matters to an integration.
This distinction also applies to public evidence. An explorer entry can help explain an observed event or retained record without authorizing a subsequent transaction. Applications should communicate readiness and availability accurately, including the difference between a supported read and an enabled action.
FROM ARCHITECTURE TO INTERFACE
Engineering references
Network discovery and public readiness demonstrate the difference between seeing a capability and being authorized to perform a wallet operation.
Discover token-import networks
Make network selection explicit when inspecting or importing a token.
GET/api/v2/wallets/token-import-networks- Observable result
- The network choices currently accepted by the token-import interface.
- Authority and limits
- These choices do not establish signing, withdrawal, or cross-chain transfer support.
Inspect public wallet readiness
Relate the wallet narrative to an inspectable readiness record.
GET/api/v2/explorer/mpc-wallets/{wallet_uuid}/operational-readiness- Observable result
- The public, read-only operational-readiness projection for the specified wallet.
- Authority and limits
- The projection does not grant authority or reveal the wallet's proprietary signing or recovery mechanisms.
Selected operations were checked against the public OpenAPI contract on October 1, 2026. Links open documentation; they do not invoke an operation. Authentication, exact schemas, and deployment requirements remain defined by the current contract.
Connected financial workflows
Wallets connect naturally to funding, settlement, governance, and policy evaluation. Funding history can help explain the relationship between an observed deposit and a usable balance. Organizational policy can shape which proposed actions are acceptable. AI Wallet Control can supply a decision for review, while the financial operation remains subject to its separate authority and enabled route.
The advantage is a richer operating model than simply displaying balances and submitting transactions. A business can connect asset context to permissions, decisions, and evidence. That connection is valuable only when the integration preserves the difference between a request, its approval, its execution, and its eventual outcome.
Evaluation without publishing the mechanism
A meaningful evaluation defines the intended operation and its network, names the authorization and recovery responsibilities, and tests the agreed behavior in an appropriate environment. It records what succeeded, what was denied, and which dependencies remained. These outcomes can substantiate capability without requiring the public whitepaper to describe the internal means by which the wallet system achieves it.