A wallet can have more than one responsibility, but those responsibilities should not automatically share the same authority. Hybrid-Chain’s dual-wallet architecture separates the customer’s beneficial claim and transaction authorization from the protocol’s reserve and settlement duties. Each customer and network can therefore be represented by two independently generated MPC roots: PERSONAL_MPC and HYBRID_ESCROW_MPC.
Why one root was not enough
Customer authorization and protocol escrow answer different questions. The personal domain establishes who may authorize activity for the customer and where the customer’s claim is represented. The escrow domain supports controlled reserve and settlement workflows whose policies are governed by the protocol. Combining those duties under one root would make an implementation shortcut into a permanent trust assumption.
Hybrid-Chain instead treats the domains as separate security systems. They cannot share a DKG ceremony, wallet identifier, activation, key root, group key, signer-policy commitment, or security-domain identity. A relationship certificate may prove that the two domains belong to the same customer and network context, but that relationship does not collapse their authority.
Independence must be provable
- Each root is produced by its own distributed key-generation ceremony.
- Each activation package is threshold-certified and independently retained.
- Core verifies that plans, ceremonies, results, wallets, roots, and group keys have not been reused.
- Public Explorer views expose commitments and public chain accounts without exposing private shares.
- Interrupted schema deployments are audited and repaired additively rather than by deleting retained evidence.
The result is not merely two wallet labels in an interface. It is an enforceable boundary carried through ceremony evidence, activation state, public commitments, and recovery procedures. If the required independence cannot be demonstrated, the pair is not treated as ready.
Network isolation remains part of the model
Devnet and Testnet are isolated synthetic-value environments with separately named assets and faucet authorities. Mainnet has no synthetic-asset or faucet registry. New chain accounts also begin with external receipt disabled. These constraints prevent a development convenience from inheriting production authority simply because the wallet types share an application surface.
Related responsibilities can share context without sharing a root of authority.
What this makes possible
The dual-domain model gives later funding, settlement, reserve, and withdrawal workflows a precise place to attach their evidence. A customer authorization can be evaluated as a personal-domain fact. A reserve transition can be evaluated as an escrow-domain fact. A workflow that requires both must prove both, instead of relying on a wallet record whose internal responsibilities are ambiguous.