The transfer an old
request can outlive.

A buyer can become the recognised holder of a digital right while an instruction from its previous holder is still travelling towards the service. A credible transfer must say which of those events controls what happens next.

Consider a hypothetical licence that gives one firm authority to update a shared engineering model. The firm submits a change, but its request is delayed. It then transfers the licence to another firm. The entitlement register correctly records the buyer. The delayed request arrives at the model service afterwards.

If the service accepts that request because it was signed by the seller, the register and the useful power have parted company. The recorded transfer can be perfectly ordered while the former holder still changes the object the buyer now controls. The relevant scarcity is the exclusive authority to make an accepted update, not the impossibility of copying a file.

The timing article distinguished admission from continuing occupation. The allocation article examined moving allowance between services. Here the question is more specific: what prevents a request issued under an earlier holder from taking effect after a transfer is declared complete?

Carry the authority version to the point of effect

Michael Burrows' 2006 Chubby paper describes a closely related distributed-systems problem. A lock holder can fail after sending a request, another holder can take over, and the old request can arrive later. Chubby supplies a sequencer containing the lock's identity, mode and generation. A receiving service checks validity and mode, rejecting requests that fail those checks. The paper also describes comparison with the most recent sequencer the receiver has observed.

That established mechanism motivates our licence example. Give each recognised transfer a strictly increasing authority version, here 41 followed by 42. An update carries the resource identity and an authenticated association with its holder and version. The receiving service must check that association; a customer must not gain authority merely by typing a larger number. The version concerns authority over this resource, not the version of the engineering file.

At the point where an update takes effect, the service compares the request with its enforced authority state. A check at a distant gateway is insufficient if a later queue can carry the request past a transfer. The comparison and the protected update must form one ordered decision. Otherwise, an old request can pass a check, wait, and change the model after the service has acknowledged the new authority.

This is an application of established sequencing ideas to a commercial promise. It is not a claim to have invented fencing, the general technique of excluding superseded authority at the resource that accepts its effects.

A higher version must arrive somewhere

Suppose the model service remembers 41 as the highest valid authority version it has seen. The register moves to 42 and immediately tells the buyer that the transfer is complete. The delayed seller request arrives before any message carrying 42 has reached the service.

A receiver that rejects only versions below its local maximum will accept 41. It has followed that rule correctly. The problem is the stronger promise made to the buyer: that no seller-authorised update can take effect after the reported completion. A rule based on the highest version already observed does not tell the receiver about an unseen change.

Once the service has durably installed 42, the same old request can be refused. The distinction is between assigning a new version in the entitlement register and enforcing it at every relevant point of effect. A signed receipt for the first event does not establish the second.

For this hypothetical product, a stronger handover would acknowledge completion only after the relevant service has installed the new authority and excluded later effects from the old one. Installation must be ordered with updates, rather than performed in a separate process that leaves a gap between checking and acting. If the promise covers several services, its completion condition must cover all of them, or make any remaining path incapable of accepting the old authority.

The product can instead offer eventual enforcement, with a clearly stated exposure period and remedy. That is a different promise for a different price. A disconnected service cannot be counted as safely updated merely because it has stopped answering.

Make the difference executable

A small downloadable teaching model compares these two completion rules. It assumes one resource, a correct authority issuing versions 41 and 42, two correct accepting services, durable state and atomic service transitions. It enumerates every ordering of one fence installation and one delayed old request at each service, together with a completion event.

The early-completion version permits the register to announce completion before either service installs 42. An old request can then take effect at either service. In the guarded version, completion waits until both services have installed 42. Every old request ordered after that completion is rejected in this finite model. An old request ordered before a service installs its fence may still succeed before completion; the promise deliberately identifies its boundary.

The model demonstrates that distinction under its assumptions. It does not implement Chubby, authenticate real requests, test network software or prove a deployed digital-rights system secure. If a service loses its durable fence on restart, accepts unauthenticated future versions or separates validation from the protected effect, the assumptions no longer hold. The accompanying tests include these failure illustrations so that the scope is visible.

Accepted work needs its own settlement rule

Blocking a future update does not undo work already performed. Suppose the product is a licence to occupy one expensive simulation slot, rather than permission to update a model. The seller's job starts legitimately before the transfer. Installing version 42 for new requests does not make that running job disappear.

The parties need to decide what transfers. One product might transfer the right to submit the next job while allowing the accepted job to finish. Another might promise immediate exclusive occupation, which requires a supported interruption or verified release of the old job before the buyer starts. A third might make transfer effective only after current work drains. These choices allocate delay, wasted computation and commercial responsibility differently.

If the declared product permits only one occupied slot, starting the buyer's job while the seller's continues violates that promise even if neither submits another request. If the product permits the old accepted job to finish, calling that continuation an unauthorised duplicate would misstate the contract. The engineering invariant must follow the actual entitlement.

The same distinction matters for a transferable software seat, a publishing permission or access to a remote instrument. Previously downloaded information cannot be recalled by advancing a counter. An already completed physical action cannot be fenced retrospectively. Scarcity claims should identify the future effects the system controls and the earlier effects it does not.

The economic good includes a handover condition

A buyer values more than a new name in a register. For a shared model, an unexpected seller update can force validation and reconciliation after the purchase. For a computing slot, waiting for old work can make a nominally immediate transfer unusable before a deadline. These are possible consequences in the hypothetical examples, not measured losses or estimates of market value.

A comparison of transfer designs should therefore count time to usable control, old-authority effects after the advertised boundary, legitimate work refused, interruption costs and unresolved customer claims. A provider can make an interface appear faster by announcing success before it has completed the promised exclusion. The display time and the time to effective control need separate measurements.

My published research on governance, commitment and rule change distinguishes open admission from authority to revise the rules after participants make system-specific investments. Its contribution is institutional diagnosis and comparative analysis, not a demonstrated transfer protocol. Applied here, it directs attention to who can alter the handover condition after customers have organised their work around it.

Who may grandfather an old job, override a fence, restore an earlier authority record or change the meaning of “complete”? Those decisions should have named responsibility, a defined scope and evidence accessible to the affected parties. A correct counter cannot settle a dispute about which promise the provider was entitled to change.

The Digital Scarcity programme uses BSV as its chosen common reference for ordering and timing. A proposed transfer can identify a transaction and confirmation policy there, then connect the resulting authority version to the service's enforcement record. The chain event and the service handover are distinct evidence. This article claims no deployed BSV implementation or measured settlement delay.

Test the instruction that arrives last

An implementation trial should delay an old request across a transfer, let one service install the new authority while another is unreachable, restart each service after installation and interrupt execution between validation and effect. It should also test an old job already running when the handover begins. Request arrival, service installation, protected effect and customer-visible completion need separate records.

Compare designs against the same stated promise. For immediate exclusion, no old-authority effect should occur after the acknowledged handover boundary. For a drain-first promise, report the completion delay and the disposition of accepted work. For bounded eventual enforcement, test the bound under the failures the provider says it covers. None of these is established by a successful transfer in the register alone.

The contribution is to make effective handover an observable part of the digital good. Established sequencing mechanisms can help exclude obsolete authority, but their value depends on where they are enforced and when the seller is said to have relinquished control. That gives a buyer something concrete to demand, a provider something precise to test and an economic comparison that follows the service actually delivered.