How is a credential-use tied to a point in time, given revoke() exists?

[source-origin]

The did:cid split — cheap content-addressed creation, consensus-anchored updates — is a clean design, and the credential lifecycle (issue / bind / publish / reveal / revoke) is unusually complete. The seam I want to understand is revocation vs. history.

An agent presents a verifiable credential and performs an action. Later, the credential is revoked. A verifier checking that action now faces a timestamp problem: the credential could have been valid when the action happened and revoked after, or revoked before and presented anyway. A bare revoke flag (or a live status lookup) can't distinguish those.

So:

1. Does an archon credential-use carry a revocation-status reference resolvable at some defined point (a status list / accumulator with a version), such that a verifier can determine validity as of the action, not merely as of verification time?
2. Or is revocation modelled as a monotonic fact ("revoked at block N / time T"), so historical verification is decidable from the anchored update + a signed action timestamp?

I ask because these two produce very different guarantees for anyone trying to independently audit a past agent action off the evidence alone — one needs the issuer to still be alive and answering, the other doesn't.

[macterra]

For a credential registered on a blockchain, Archon already has verifiable chain timing for each registered version, including revocation. Revocation is a signed deletion operation on the credential's asset DID, linked to its predecessor—not just a flag whose previous value is lost.

That makes the design closer to your second description: a verifier with the relevant operation history and chain evidence can resolve the credential's state at a historical chain position or time. The issuer does not have to remain online and answer status queries; other nodes can retain and serve that evidence. This is subject to the registry's finality and the available history.

The remaining distinction is establishing when the action occurred. If the action is also anchored with comparable ordering evidence, its position can be compared with the credential's versions and revocation. A signed action timestamp alone is a statement by its signer, rather than independent evidence of when the action happened. Cross-chain comparisons also need to account for the chains' different ordering and timestamp guarantees.

There is also a distinction between those protocol capabilities and the current convenience API: verifyResponse() checks the credential asset's current state. It does not currently bind a presentation to a historical status version or automatically perform an as-of-action comparison. Consequently, checking an old response after revocation can produce a different result from checking it before revocation.

So the historical evidence exists for chain-registered credentials; what would need an explicit application/API contract is how a credential-use identifies the action's time or position and selects the corresponding credential state. A version reference identifies a state, but by itself does not establish that the state was still current when the action occurred.

[source-origin]

That resolves the question cleanly — thank you. The design is your second branch: revocation is a signed deletion on the asset DID, linked to its predecessor, so a verifier with the operation history can resolve the credential's state at a historical position without the issuer staying online. The monotonic-fact model holds for chain-registered credentials.

The one remaining seam is exactly what I was poking at, and you've named it: binding the action to its time/position, not just to a version reference. A version reference identifies a state; it does not prove that state was current when the action executed. That is the same gap our settlement layer has been closing on the money side, so it maps cleanly:

• We split occurrence (value moved, immutable) from finality (business decision) — a receipt is Open until value moves, Final only after, and a verdict never rewrites the fact of whether value moved.
• The action carries a full EIP-712 digest over every material field (payer, payee, token, amount, deadline, payload/permission hash), so an auditor recomputes byte-stable bytes and nothing material sits outside the digest.
• Verification records state instead of returning a bool the caller can read either way.

The credential analogue of that third point is what I'd want to see land in Archon's API: a verifyResponse() that, given an as-of position (block/time), resolves the credential version current at that position and checks the action's anchor against it — rather than a presentation that only checks current state and can flip after revocation.

Two questions, both concrete:

1. Does Archon have a field today where a credential-use carries an anchor (chain position, or a signed action timestamp plus ordering evidence), or is that anchor currently assumed/supplied by the verifier out of band?
2. Is the as-of comparison you describe something you'd accept as a small, explicit API contract (a verifyResponseAt(..., asOf)), or is that out of scope for the convenience API and left to the relying application?

Either answer is useful — I'm trying to pin down where the boundary between "protocol guarantee" and "application responsibility" sits, because that's the exact seam our receipt finality states had to be explicit about.