How history resists replay and rewind

Each workspace keeps its own history of accepted operations. The governance service writes that history as a chain of blocks. Each new block points at the block before it and carries a hash of what it contains. The service signs the block. The chain shows that the record follows the previous record and that the governance service signed it. This article describes that protection at a high level. It does not describe how to disable it.

The history belongs to the workspace that accepted the operations. Another workspace has another chain. A block records the accepted change, points at the previous block in that same workspace, and carries a hash of what the block contains. The governance service signs the block with its own key. The signature is the service's statement that it appended this block. It is not a substitute for the human approvals collected earlier.

The application is the place where people prepare and sign. The governance service is the place that records an operation only after those approvals and the application's other checks have finished. The service asks for waiting operations. It does not accept a proposal posted to it from a browser. That separation is why a repeated call from the application can be recognized as the same change, instead of becoming a second record.

Before a waiting operation is written, the service checks whether that change is already in the history. If the same change comes back, for example because an earlier answer did not reach the application, the service does not treat the copy as a new approval and does not append a second block for it. The time on the operation is stored with the record. It is not used as a clock that rejects an old or future timestamp. The check is that the recorded change is unique. Rolling the sequence of blocks backward is a separate check.

Picture the account request from the governance guide. The two founders have signed, the policy is satisfied, and the service appends one block. The answer is delayed, so the application asks again about the same change. The service finds that change already recorded. It does not append another block, and it does not describe the copy as a fresh approval. The account is created once, when execution of the accepted operation succeeds. Asking again does not create a second account from the same recorded change.

This is not a claim that every similar request collapses into one. A new operation, with its own identity, is a new proposal. People still have to read it. If the details differ, the signatures on the first operation do not cover the second. Anti-replay is about the change the service has already accepted coming back. It is not a filter that guesses two business requests were meant to be the same, and it is not a window on the clock.

The service also remembers a tip for each workspace: the latest block number and the hash of that block. When the service starts, it compares the history it can read with that tip. If they agree, or if the history has simply grown further, work continues. The first time a tip is needed, the service saves the tip from the history it finds. If a tip already exists and the history is missing, shorter than the tip, or the block at that position is a different block, the service treats the history as rewound or forked and stops. It does not keep approving operations on a history that no longer matches the tip it saved.

Growth is allowed. A history that continues past the saved tip is treated as later work, not as a rewind. A history that now ends earlier than the block number in the saved tip is shorter. The service stops. A history that still reaches that block number, but the block there is not the block that was saved, is a different history. The service stops for that too. The comparison at startup uses the latest block the service can read for that workspace. It is the tip check, not a tour of every earlier block.

A stop is the protection. The service refuses to keep recording operations on a history that does not match the tip it saved. Treat that stop as a problem to investigate with the people who operate the deployment. Do not delete the saved tip so the service will start, and do not look for a switch in this article. This page does not describe how to disable the check or how to rewrite a tip. Clearing the marker that remembers the history would hide the disagreement. It would not repair it.

The first time a workspace has no saved tip, the service can save one from the history it finds, including a history that is still empty. That first save is not a rewind. A later start, with a tip already saved, is the start that can stop. If the tip cannot be read, the service treats that as a missing tip and can save one from the history it finds. A missing history when a tip is already present is a stop, not a fresh start.

Together, the two checks keep a repeated delivery from becoming a second approval, and they keep a shortened or replaced history from being treated as the current one. They protect the governance record. They do not replace the preview and the distinct human approvals collected before an operation is eligible for that record. They are not a certification, an insurance policy, or a promise about a particular deployment. Subscribed workspaces can read the technical account of the same checks. Reading either public article does not enable a module or change a policy.

Anti-replay does not read the preview for you. Anti-rewind does not decide that the original operation was a good idea. Before anyone signs, compare the target, the action, and the values. A solo organization can finish with one eligible identity when its policy says so. Two founders who must both sign are still two people after these checks exist. A team that requires three approvals from five still requires three distinct approvals. The history checks run later, on the operation those people already approved.

Use Getting Started to create an organization and a Bitcoin account on a test network, and the governance guide to see how that request is submitted and signed. Use this page when the question is what happens if the same change is delivered twice, or if the history on disk is no longer the history the service remembers. The Bitcoin RGB guide is about a different verification problem: a confirmed Bitcoin transaction does not by itself prove that an asset transfer was validated by the receiver.

Medusa Custody™ is in beta. These checks are part of the governance record we are building. They are not a statement that a deployment is audited, insured, or ready to hold customer funds. They do not name the file that stores the tip, the settings that turn the check on, or the hash inputs of a block. A subscribed workspace can read that technical account. This public page is the briefing: a repeated change is not a second approval, and a history that disagrees with its saved tip stops the service.