How governance handles an operation

Medusa Custody™ separates the proposal to move or reconfigure value from the record that the proposal was approved. An operation is that proposal: open an account, create an organization, send a transaction, or change who may approve later work. The governance module is its own service. It does not accept these proposals from the public internet. It asks the application for operations whose policy has already been satisfied, checks that it is not recording the same change again, and appends each accepted change to that workspace's history.

One person prepares the operation. That person is not automatically the only approver. Eligible approvers are the identities the organization and the policy name for this kind of work. A workspace administrator can invite people and register devices. Registration lets a phone confirm a login and, once the phone is an eligible signer, review an operation. Registration alone does not approve the operation and does not grant the organization's signing authority.

Read the preview before you store the operation and again before you sign it. The preview shows the target, the action, and the values. Compare those with the instruction you were asked to approve. If the target is an account, confirm the organization and the network. If the action changes who may approve later work, confirm the people and the rule, not only the title of the change. A documentation page is not the preview. Do not sign from a screenshot in a chat when the product can show you the operation itself.

While an operation has no signature, it can still be corrected. Read the target, the action, and the values in the preview, and compare them with the instruction you intend to approve. A draft that nobody has signed remains editable. The first eligible signature fixes that operation. Later signers add their approval to the same content. They do not change what was already signed.

The form offers two ways to hand the operation to the other approvers. Submit stores the operation and leaves your own signature off it, so an eligible signer can review it in the browser or on a registered phone. Sign & Submit adds the browser extension's signature first, then stores the same operation. Both paths keep the same checks. An extension signature does not dismiss anyone else the policy still requires. The same key in the browser and on a phone is one approver, not two.

A solo arrangement can be completed by one eligible identity. A shared arrangement asks for more than one distinct approval. A new workspace can start with one approver, with two approvers who must both sign, or with a team that requires three approvals from five. An organization can use a larger rule. The policy for that operation decides when enough signatures have been collected. The button label does not. A login confirmation on a phone confirms a sign-in. It does not approve the operation.

Consider two founders who must both approve an account request on a test network. The initiator uses Submit, so the request is stored without that person's signature. The first founder reviews it on a registered phone and approves. The policy still needs the second founder, so the request stays open. The second founder uses Sign & Submit. That is a second distinct approver, and only then is the signature set complete. If the second founder instead signs with the same key the first founder already used, the policy is still short one person. The product does not count that repeated key as a second approval.

When the policy accepts the collected signatures, the application still runs the checks configured for that kind of operation. Only then does the operation wait for the governance service. The service reads those waiting operations, refuses a second recording of a change it already holds, and requires a signature on an ordinary operation. It writes the operation into the next block of that workspace's history and signs the block with the governance service's own key. The application accepts that result only when it refers to the same workspace and the same operation, and only then carries the operation out. If recording or execution fails, the operation remains visible with that outcome. Accepting a notification does not make the operation effective.

After the first signature, the operation is no longer a draft you can edit. Leave it in place for the remaining approvers. They should open the same operation, in the browser or on a registered phone, and compare the preview with the instruction. A new operation with slightly different details is a different proposal. It does not amend the one already signed. If the signed details are wrong, stop and follow the visible outcome. Do not ask a later signer to pretend the preview says something else.

The governance service does not take the operation from a browser call. It asks the application for operations whose approvals are already complete and whose other checks have passed. You cannot finish the record by calling the governance process yourself. When the service accepts the operation, it appends one block for that change and signs the block. The application then checks that the answer names the same workspace and the same operation before it carries the operation out. A matching answer that arrives again does not create a second execution of a completed operation.

A missing approver leaves the operation waiting. A policy that no longer accepts the collected signatures does not carry the operation forward. A check configured for that kind of operation, including a compliance rule on a destination or an amount, can refuse it before the governance service records it. A recording failure or an execution failure stays visible on the operation. None of these outcomes become a success because someone accepts a notification or because the same request is submitted again under a new story.

Cancel remains available until the operation has been handed to the governance service. After that handoff, read the recorded outcome. If the service has already accepted the change, a later copy is not a second approval and is not a way to undo the first one. The history page describes that refusal, and the separate stop that occurs when the workspace history no longer matches the tip the service saved.

Two protections sit under that record. Anti-replay recognizes a change the service has already accepted, so a repeated delivery is not a second approval. Anti-rewind compares the history with a saved tip. If the history is shorter than that tip, or the latest block is not the block that was saved, the service stops instead of continuing on a rewritten history. The public article on replay and rewind explains both ideas. A subscribed workspace also has a technical article for each subject. This public page does not certify a deployment, insure funds, or replace the review you do before anyone signs.

Use this page to brief a team before a rehearsal. Agree the operation, the eligible approvers, and whether one signature is enough. On a test network, create the organization and the account from the Getting Started guide, and watch the same request move from an editable draft to a stored operation, through the remaining signatures, and into a visible result. The Bitcoin RGB guide is a different subject: an asset transfer needs its own receive request and client-side validation. It still uses the approval rule when the workspace exposes that operation.

This page does not name the internal statuses, the hash inputs, or the startup results of the history check. It does not tell you how to disable the governance service or how to skip an approver. Medusa Custody™ is in beta. A successful rehearsal on a test network is not a certification, an insurance policy, or evidence that a particular deployment holds customer funds. If an action is missing in your workspace, ask the administrator. Reading this article does not enable a module, a network, or a signing identity.