HYBRID DEVNET · PUBLIC EVIDENCE LIVEVerifiable infrastructure for value, markets, identity, and operational dataInspect the network

Security & privacy

Can we separate transaction requests, approvals, and signing?

3 min read

Treat these as separate responsibilities when designing your workflow. A recorded proposal or review can make the decision trail clearer without itself becoming a signature or completed transaction.

Give each role a clear purpose

A requester explains the action wanted. A reviewer considers whether it should proceed. An authorized execution workflow handles the consequential action. These responsibilities may be assigned to different people or systems. Separating them can help a business avoid giving every application or employee the power to complete a transfer alone. The separation must exist in the actual access model, however, not only in a diagram or a checklist.

Tie approval to the exact request

The reviewer should know which wallet, recipient, asset, network, amount, and relevant terms they are considering. If those details change, the workflow must handle that change according to its supported rules rather than reusing an unrelated approval. Keep the proposal and decision references connected. A governance record can make the review understandable without itself being the cryptographic signature or external transaction that completes the financial operation.

Test both normal and bypass scenarios

In an agreed evaluation, demonstrate that a requester can perform the intended preparation but cannot skip a required approval. Check what happens if the reviewer lacks the right authority or the proposal changes. Also review administrative and recovery paths, because those can alter the effective separation. Business and security owners should be able to explain who can change the rules and which evidence records that change. Confirm the enabled product operations before designing a production approval process around them.

Illustrative example

An application prepares a request, a finance reviewer checks it, and a separately authorized signing workflow handles execution.

In plain language

A policy needs a person responsible for it

A policy is a set of rules about what should be allowed, refused, or reviewed. Software can help apply and record those rules, but someone still needs to decide what they mean for the business. Name the owner of the policy, the people permitted to change it, and the person responsible when an exception occurs. An approval should apply to a clearly identified version or request; otherwise a later change can make an old approval misleading. Keep the technical decision separate from the business decision when they are not the same. For example, a proposal may satisfy a configured limit while still needing a budget owner’s agreement. This is not unnecessary bureaucracy: it lets different teams understand the same result without assuming that another team has completed work that is still outstanding. Start with a small, explicit responsibility map and test the handoffs.

In plain language

Permission, signing, and completion are different

Think of a business bank payment: preparing the instruction, approving it, and seeing it complete are separate events. A wallet workflow also has distinct responsibilities. Authorization means the required person or policy permits a particular action. Signing means the participating systems produce the cryptographic signature needed for that action. Completion means the relevant system has accepted or settled the result under its rules. A screen displaying a wallet, or a service responding successfully, does not combine these steps into one. In Hybrid-Chain, customer authorization is separate from distributed signing participation. When reviewing a status, ask which of these stages it describes, which asset and network it concerns, and whether the evidence is current. This distinction helps prevent a common mistake: treating an informational record as permission to move money. An operator should be able to explain the stage in ordinary language without asking you to share any secret material.

Conditions & limitations

The required roles and supported approval operations must be confirmed for your deployment. A governance record does not automatically enable signing.

What to do next

Map each role to its exact operation and test that a requester cannot bypass required authority.

Governance & Approvals ↗Native MPC Wallets ↗