The chain clock becomes real time at height 77,100,000

1. What the clock is today

A contract on Thebes reads the time with Time.now() (Motoko) or ic0.time() (Rust). Until the crossing that value is a block counter: one "second" per finalized block, counted from the first block. Blocks are produced several times a second, so the value advances faster than a wall clock, and it reads as a date in 1972. Nothing about consensus depends on it; it is simply what a contract sees.

2. What changes at height 77,100,000

• The value becomes real time. From the first block at or above the height, every node stamps its block with UTC nanoseconds within a bounded skew of true time, every node executes with the same stamp, and a contract reads 2026, not 1972. The value is monotone from block to block and advances at the wall-clock rate. A query observes the time of the latest finalized block.
• Every deadline written in the old clock lies in the past. A contract that stored now + ttl before the crossing holds a number of the order of 75,000,000 seconds; the first real reading is of the order of 1,789,000,000 seconds. Such a deadline is expired the moment the clock changes unless the contract translates it (section 4 shows how the identity contract does).
• Armed timers fire once. A timer set with the old clock is due at the crossing and runs in that block's timer phase.
• Message expiry is checked against real time. A signed message carries an expiry; after the crossing an expired one is refused at execution. Client libraries that set the expiry in real time are unaffected.

3. What does not change

• Block heights, block hashes and the chain's history. Nothing is rewritten.
• Contract code, state, stable memory and identifiers. No contract is reinstalled by the crossing.
• Determinism: every node executes the same block with the same time value, exactly as before.
• Identities, handles, passkeys and the principal each application derives for a person.
• The public API paths, the boundary and the deploy tooling.

4. The Memphis identity change that ships with it

Memphis, the identity contract behind passkey sign-in, minted every lifetime scaled for the block clock (a 30 minute session was written as 30 × 60 × 13 block-seconds). Left as it was, the same arithmetic under a real clock would keep a session alive for six and a half hours. The upgrade installed before the crossing does three things:

• Lifetimes are chosen from the clock the contract observes. Below the crossing the arithmetic is unchanged; above it a session is 30 real minutes, a sign-in challenge 5 real minutes, a "stay signed in" credential 14 days of inactivity within 30 days, a factor-removal delay 24 real hours.
• Nothing already issued expires at the crossing. A deadline written in the block clock is translated when it is read under real time: the block-seconds that remained at the crossing become the real seconds that remain. A person signed in ten minutes before the crossing stays signed in for the twenty minutes they had left; a "stay signed in" credential keeps its remaining days; a factor removal requested before the crossing still waits its full day.
• Sign-in with the passkey alone. The same upgrade lets a person sign in without typing a handle: the passkey on the device names the identity. Applications need no change; the sign-in window offers it where the device supports it.

Applications and their users do nothing. The upgrade is in place before the height arrives, and the contract is correct on both sides of it.

5. If you maintain a contract

• If your contract compares stored deadlines with the clock, decide before the crossing whether they should be translated (as above) or allowed to expire, and say so to your users.
• After the crossing, compare dates with the clock using a tolerance of a couple of seconds; sub-second precision is not promised.
• A rule of the form "refuse a date earlier than the latest one recorded" is correct with either clock and needs no change.