[DeFi][FIN-22] Chain-authenticated time, freshness and expiry feasibility #72

Umbrella #43 · work-item FIN-22 · proposal / no release milestone.

What does it do? Plain English

A wallet deadline and a historic block timestamp are not proof that a transaction is still valid at the current chain tip. This task determines which time limits can actually be enforced on-chain.

Visual walkthrough

flowchart LR
A["Claimed deadline/freshness"] --> B["Actual chain-observable evidence"]
B --> C{"Can verifier prove required bound?"}
C -- No --> X["Unsupported or explicit trust adaptation"]
C -- Yes --> D["Reject stale/replayed transactions"]

Implementation layer: Temporal security contracts and chain-observation semantics.

Prerequisites: Closed #12 temporal types, #24 bounded CKB observations and #43 accepted chain context.

Detailed design and security review

The security question

On CKB, a historical HeaderDep proves information about a referenced header, not by itself that a transaction is being validated at the wall-clock moment advertised by a wallet. The ordinary since contract expresses admissible lower bounds; it does not automatically establish an arbitrary expiry upper bound. Do not claim a true chain-enforced expiration without proving an authoritative clock/freshness source under the target chain rules.

Exact proof obligations

Define each temporal claim separately: earliest valid consumption, not-before/relative lock, observed header time, claimed trade deadline, oracle sample age, order expiration and signed-intent revocation. For each, identify the exact consensus-visible sources, canonical units and source scope, and what additional trust assumption (if any) makes the claim sound. One source's timestamp cannot silently stand in for another kind of time.

Decision and implementation process

1. Inventory actual CKB-VM syscalls, header-dependency rules, input since and observable chain ordering from pinned CKB specifications and test-node behaviour.
2. Produce executable minimal examples and counterexamples for every claimed temporal property—especially a historic-but-valid header supplied after a purported expiration.
3. Freeze three explicit support classes: chain-enforced, external-trust / checkpoint-assisted, and client-only. Unknown properties are unsupported.
4. Create a versioned typed observation/expiry contract only for the selected provable or explicitly trusted classes; keep external clock identities separate from system consensus.
5. Integrate consumers: order expiry, signed intents, TWAP sample freshness and stale-pool rebuild, with accurate user-facing errors.

Adversarial cases

Completion rule

A well-documented not supported result is a legitimate research conclusion where CKB cannot prove the desired upper time bound without extra trust. Do not invent a timestamp syscall, claim a lower-bound check enforces a deadline, or quietly change the signing model to disguise that gap.

Security flow

flowchart TD
    A["Requested timing property"] --> B["Identify real chain-visible evidence"]
    B --> C{"Is the required bound provable?"}
    C -- Yes --> D["Canonical typed check + adversarial replay"]
    C -- No --> E["Disclose external trust or client-only limitation"]
    D --> F["Only then expose admitted protocol guarantee"]

Shared assurance rules

• The protocol owns its economic policy; these issues do not add finance-specific syntax or special compiler behaviour. Any missing business-neutral general primitive needs a separate minimal failing case, versioned contract and evidence.
• Freeze concrete source/chain/ABI/asset roles, numerical bounds, revocation semantics and a named reviewer/waiver disposition before claiming acceptance. No original issue or human review is silently inherited.
• Execute complete actual CKB transactions with all required script groups. Preserve independent model, generated builder, checker mutation, exact source/ELF/CellDep/tx/node evidence and worst success/late-rejection budgets. A valid simulator trace, RPC response or indexer record alone is not authority.

Implementation contract

• Inventory authentic source fields, header/tip evidence, since semantics, observable ordering and possible freshness assumptions; distinguish lower bounds from upper validity bounds.
• Specify accepted time domains, replay and reorganisation behaviour, stale-source rejection, and what a client-only timeout can/ cannot guarantee.
• If true upper expiry cannot be implemented within the chosen chain security model, record its limitations or an explicit oracle/checkpoint trust assumption instead of inventing a syscall.
• Offer a minimal independent counterexample for replaying an old valid observation after a purported expiry.

Acceptance

• Valid, past/future, missing, reordered, disputed and replayed observations exercise each claimed guarantee.
• A historic HeaderDep or user-supplied clock cannot incorrectly authorise a supposedly current deadline.
• Affected order/hook/permit consumers can distinguish proven on-chain bounds from wallet timeouts and explicit external trust.
• Any unsupported upper-bound deadline is documented as unsupported rather than marked passed; exact CKB-VM evidence for admitted claims.

Explicit exclusions: This issue does not grant new consensus clock semantics or authorise a chain upgrade.

Programme-wide acceptance discipline

• Proposed only; assign accountable implementer/review disposition, versioned threat/ABI/numeric limits and exact evidence before claiming implementation.
• Financial semantics live in ordinary CellScript protocol packages and generated builders, not hard-coded finance language constructs. A genuine general core gap must become a separate business-neutral issue.
• Preserve exact compiler/checker/source/ELF/CellDep/transaction/model identities, full-transaction positive/hostile cases, frozen resource ceilings and applicable gates. No node deployment or human audit is inferred.

Verified dependencies and implementation sequencing

Hard prerequisites: #12, #24.

Unblocks / integrated by: #73, #76.

Security and scheduling rationale: Research may conclude that some upper-expiry claims are not chain-enforceable; record unsupported rather than assert that a historical HeaderDep proves current time.

These are referenced planning contracts; no automatically enforced GitHub blocking relationship or accepted implementation is claimed.