The clock inside
a digital permission.

The Digital Scarcity programme uses BSV as its chosen design reference for shared ordering and timing. Height- and time-based transaction locks can connect a permission to that common record, provided the service distinguishes chain time, civil time and the action it promises to control.

Consider a hypothetical engineering service selling access to a scarce machine. A customer has permission until noon. A request reaches the gateway at 11:59:58, waits in a queue and begins running at 12:00:12. The signature on the customer's credential is valid. Has the service kept its promise?

The answer depends on the product. The customer may have bought the right to submit work before noon, to begin work before noon or to occupy the machine only until noon. Each arrangement can be coherent. They require different admission, scheduling and interruption rules.

The Digital Scarcity programme asks how a defined permission becomes effective control over performance. Earlier discussions addressed repeated use and the identity of the purchased object. Here the question is the temporal boundary: how a deadline in a record becomes a dependable limit in a service.

Use BSV as the common timing reference

For this Digital Scarcity programme, the design direction is to use BSV as the shared ordering and timing mechanism. A transfer or renewal should refer to a defined transaction, its place in the accepted chain and the applicable height- or time-based condition. Participants then evaluate the same chain evidence rather than treating a customer's laptop clock as the authority. This is the programme's architectural requirement, not a claim that the integration has already been implemented or tested.

The BSV Node v1.2.3 mainnet parameters specify a target block spacing of 600 seconds, or ten minutes. That gives the design a useful coarse time scale. It does not establish that every block arrives within ten minutes, that its timestamp is accurate to within ten minutes of civil time, or that a transaction is irreversibly settled within that period. Block production varies. The chain provides agreed ordering under its validation and chain-selection rules, not a precision wall clock.

A service can offer a deadline expressed in chain height when sequence is what matters. If the customer instead needs a civil-time appointment, the service must explain how its chain-time condition relates to that appointment and what margin it allows. Converting six blocks into a guaranteed hour would conceal the very uncertainty the contract needs to expose.

Specify height and time locks separately

In the inspected BSV Node v1.2.3 implementation, the transaction's nLockTime selects a height condition below 500,000,000 and a timestamp condition at or above that threshold. The active block-validation path uses the previous block's median-time-past for the time comparison. IsFinalTx uses a strict less-than comparison: equality with the relevant height or time cutoff does not satisfy that check. A zero locktime passes it; all-final input sequence values also bypass the locktime restriction. A transaction intended to retain the restriction therefore needs at least one non-final input sequence.

These details matter at the boundary. A design that means “eligible in block H” must encode and test that meaning against the implementation rather than assume that writing H into a field is sufficient. The older Genesis specification prose describes an inclusive boundary, whereas the inspected implementation uses the strict comparison above. That discrepancy is a reason to preserve the node version and boundary tests in the engineering record, not to blend the two descriptions.

A single nLockTime field represents one of those two forms, not simultaneous independent height and time constraints. If an application requires both, it needs an explicitly designed and tested transaction workflow or service rule. This article does not claim that the existing field enforces an arbitrary conjunction.

Locktime also establishes earliest eligibility, not an expiry deadline. Once a transaction passes that temporal check, other validity conditions and inclusion still matter. The check does not guarantee that a miner includes it immediately, make an already delivered file disappear, or prevent somebody with authority over the same funds from constructing a different spend. The signing arrangements, spending script and service state must enforce the intended agreement together.

Connect the chain condition to the permission

The proposed service should retain the entitlement identifier, authorised transition, transaction identifier, relevant output, chain reference and timing rule together. Before releasing the scarce performance, it should verify the required transaction and spending conditions and apply a declared confirmation policy. A block hash matters alongside height because a competing chain can contain a different block at the same height.

The service must also say what happens during a chain reorganisation, a stale view or unavailable chain evidence. It may delay release, maintain a bounded provisional allowance or require renewed verification. The selected response changes the customer's usable service and the provider's exposure. Agreement on chain order is valuable precisely because those decisions can refer to a common record; it does not remove the need to make them.

For expiry, the application must separately define when it stops admitting work or releasing capability. BSV provides the agreed timing reference for that rule, while the service enforces its operational consequences. Any design using signing, spending conditions or attested control must demonstrate that an old capability cannot continue through an unexamined route. We should test that complete path, including recovery, rather than call a timestamp alone an implementation of scarcity.

Put the deadline at a decision point

RFC 7519 defines a JWT expiration claim against acceptance for processing, and a not-before claim for the beginning of acceptance. Both are optional in the general format. It permits small leeway for clock skew. An application therefore needs its own required-claim and validation policy; the format alone does not specify the commercial service.

For the hypothetical machine, I would record separate times for receipt, authorisation, admission, execution and completion. If the contract is about submission, the receipt must survive a queue or restart. If it is about occupation, a successful gateway check cannot be the last enforcement step.

A long operation also needs a defined stopping rule. Immediate interruption can discard valuable work. Allowing every admitted operation to finish can occupy capacity beyond the advertised window. Checkpointing may preserve progress, but it has an implementation and storage cost. The choice should be visible when the service is purchased.

Treat clock error as an exposure

Suppose a verifier accepts a request when its local clock is earlier than the stated expiry plus an allowed tolerance. Assume, for this illustration only, that the clock can lag actual time by at most 20 seconds and the tolerance is 10 seconds. A request can then remain admissible for nearly 30 seconds after the stated expiry. This is arithmetic under declared assumptions, not a measured property of a deployed system.

More generally, if local time equals actual time plus an error bounded in absolute value by e, and the acceptance rule is local time < expiry + L, acceptance implies actual time < expiry + L + e. That bound concerns the check itself. It says nothing about how long previously admitted work can continue.

The error bound has to remain justified. An unmonitored clock, a restored machine or a disconnected site cannot simply inherit yesterday's assurance. If the service cannot establish the bound, it needs an explicit response: suspend new admission, obtain a trustworthy reference or operate within a separately disclosed exposure limit. None of those choices is free.

Making the tolerance smaller can refuse legitimate customers whose requests arrive near the boundary. Making it larger extends exposure. A service comparison should count both consequences, rather than advertising the shortest printed credential lifetime as the strongest control.

Give fresh evidence a limited meaning

RFC 9334's remote-attestation architecture, an Informational RFC, distinguishes synchronized clocks, nonces and epoch identifiers as approaches to freshness. Its discussion explicitly recognises that device state or appraisal policy can change after evidence is generated. A nonce can show that claims were signed after a challenge was generated; it does not itself identify when every underlying claim was created.

In the machine example, a newly received attestation could support an admission decision under a declared policy. It would not automatically guarantee the same operating condition throughout a lengthy job. Rechecking at a checkpoint, monitoring a relevant condition continuously, and accepting a bounded interval of exposure are different service designs.

The useful question is therefore which change could invalidate the next action, and how the service learns of it before that action matters. Collecting more evidence without connecting it to a decision can add cost while leaving the relevant interval untouched.

Account for renewal as well as expiry

A provider might shorten permissions and renew them frequently. That can reduce the period during which an old permission remains usable, provided the enforcement assumptions hold. It also makes availability depend more often on the renewal path.

Consider a customer whose machine is functioning correctly but cannot reach the authorisation service. A policy that stops new work at expiry limits one exposure while imposing another: legitimate production is interrupted. An offline allowance can preserve some continuity, but its amount, scope and exhaustion rule need to be specified. The customer cannot assess the bargain from the lifetime field alone.

For procurement, I would ask for the renewal failure behaviour beside the normal response time. Which work can finish? Which new work stops? What evidence is retained for a disputed charge? Who bears the cost of a legitimate job refused because the provider's renewal service was unavailable?

Test the boundary the customer buys

A proposed evaluation would test nLockTime immediately below, at and above the height and median-time-past cutoff, including all-final and non-final input sequences, stale chain views and reorganisations. It would then submit requests immediately before and after expiry, offset the verifier's clock within and beyond its claimed bound, delay the queue, interrupt renewal and restart a worker with work in flight. It would distinguish an incorrect admission from a legitimate request wrongly refused, and both from an operation that was admitted correctly but ran beyond its permitted occupation interval.

The record should retain the reference timing method and its uncertainty, the policy version, the point of each check and the subsequent resource use. Measuring only the gateway response would miss the queue in our opening example.

The resulting commercial comparison concerns usable service under a stated risk boundary. A nominally tighter permission can cost more to operate or interrupt more legitimate work. A more permissive arrangement may be acceptable if its exposure is understood and priced. The research task is to expose that trade-off and test the complete promise, rather than treating an expiry field as the end of the argument.