An agent that cannot
outlive its deadline.

CHRONOS composes homomorphic encryption, a verifiable delay function, and a zero-knowledge erasure proof so that a 128-byte artifact shows an autonomous agent stopped on time and destroyed its key — without trusting the agent or whoever ran it.

Read the code Verify it yourself
The gap

Four questions with no verifiable answer

Autonomous agents are being handed real credentials — cloud accounts, payment rails, code execution — for bounded periods. Increasingly the party bearing the risk is not the party operating the agent.

Question 1

Did it stop on time?

Logs are written and held by the operator. They record what the agent reported, which establishes the provenance of a claim rather than its truth.

Question 2

Did it stay in scope?

Scope enforcement runs inside operator-controlled code. Nothing outside that code can confirm the boundary held.

Question 3

Was access destroyed?

Key deletion is operator-attested. A console showing "deprovisioned" is not evidence that key material is gone.

Question 4

Can anyone else check?

Today, no. Every answer above reduces to the operator asserting it — the party with the strongest incentive to assert it.

This is not a claim that operators lie. It is a claim that a guarantee which depends on the honesty of the party with the most to lose from admitting otherwise is not a guarantee.

Mechanism

Two properties do the work

Property one

Time-bound release by construction

The agent's key is sealed under a value that requires T sequential squarings to compute. No parallelism shortens it, no policy decision governs it, and no network connection is needed for it to hold. The deadline is a property of arithmetic, not of anyone's cooperation.

Property two

Proof-carrying containment

Containment is expressed as five order-theoretic invariants over a lattice-valued capability state: capabilities only shrink, budgets only decrease, the lifecycle only advances, no admitted operation outlives the deadline, and shutdown is reachable from every state. The execution summary is bound into the same proof that attests key destruction.

One record therefore covers both what the agent destroyed and how it behaved. An agent that ran a mission but never erased cannot produce the proof at all. The nearest existing work is certified deletion, which certifies the fate of a ciphertext; the composition here binds classical erasure to a capability-monitor trace instead.

Measured, not asserted

What the prototype actually does

Every figure below comes from a test in the repository, on a recorded machine. Earlier revisions of this work asserted numbers that did not hold; those corrections are catalogued in the audit log.

8,267
R1CS constraints, all load-bearing
128 bytes
Proof size
1 ms
Verification time
505k/s
VDF squarings, constant in T
1,728
Abstract states checked at startup
~2 s
Per homomorphic multiplication

Homomorphic inference scaling

NetworkMultiplicationsInferencePer multiplication
8 → 4 → 24079.0 s1975 ms
16 → 8 → 10208383.9 s1846 ms
32 → 8 → 10336696.9 s2074 ms
Intel Core 5 210H, 8 physical cores, 16 GB, mains power. All three shapes verified against a plaintext reference. Per-operation cost is flat as the network grows, so the ceiling is the constant rather than the scaling — FheInt64 carries 64 bits where the worst-case magnitude needs about 23, making a narrower ciphertext type the obvious next optimisation.
Reproduce

Check it yourself in five minutes

Nothing in the demonstration is staged. The VDF performs real sequential squarings, the key is genuinely sealed and genuinely opened, and the proof is produced by the agent then verified against commitments the agent did not choose.

# Clone and run the full protocol end to end
git clone https://github.com/ChronosResearch/project-chronos
cd project-chronos

# Windows
pwsh scripts/demo.ps1 -T 500000

# Linux and macOS
bash scripts/demo.sh --t 500000

# Every measurable claim, collected with a machine spec
cargo test --workspace
  1. The provisioner seals a key under a time-lock requiring T sequential squarings, and publishes commitments it cannot later change.
  2. The agent verifies its containment axioms exhaustively before accepting a single request, and refuses to start if any invariant fails.
  3. The agent works over encrypted inputs, never seeing plaintext.
  4. The deadline arrives by arithmetic. No signal is sent and none is needed.
  5. The agent erases and proves it, emitting 128 bytes that a verifier checks in a millisecond without trusting the agent or its operator.
Scope

What this is not

CHRONOS is a verification primitive, not an alignment technique. It does not make an agent's objectives safer, detect deception, or constrain what a sufficiently capable system might do inside its window. It narrows one thing: the distance between what an operator asserts about shutdown and scope, and what a third party can check.

Two limitations are load-bearing, and we do not minimise them

  • The trusted setup is single-party. Verification is therefore conditional on trusting whoever ran it. This binds every claim above. It is fixable by a standard multi-party ceremony — engineering, not research.
  • No argument in a circuit can establish that memory was freed. A SNARK constrains values, not memory locations, so the prover supplies the post-wipe buffer and could retain a copy elsewhere. The residual assumption is that the operating system honours memory locking, keeps pages out of swap, and suppresses core dumps. Discharging it needs hardware attestation bound into the proof's public inputs, which is not implemented.
  • An earlier revision was substantially weaker. Its erasure circuit checked that a prover-supplied buffer equalled a constant and nothing else, so a prover who had never seen the key, the ciphertext, or the VDF output could produce a passing proof. That is disclosed, not buried: the result here is reducing an unbounded gap to one stated assumption, which is not the same as closing it.

The strongest objection

If ground control can sign a revocation, why build a cryptographic deadline? Because the two fail differently: revocation fails open when the channel is gone, expiry fails closed. CHRONOS is a complement to revocation, not a replacement — but only one of them leaves evidence a third party can check afterwards.

Read the full argument

SAFETY_CASE.md sets out why this is worth building and what it does not do. AUDIT.md lists every defect found in this codebase, including four critical ones in our own prior revisions.