Skip to main content

2026-09-10

· 3 min read
Kaan Kacar
Kaan Kacar
Developer Advocate

This week was planned as a protocol discussion on CAP-87 and CAP-88, with Jay Geng and Garand Tyson from the core team. Jay had audio problems and we could not hear him even after he rejoined, so this recording covers only CAP-88. Jay presented CAP-87 the next week.

CAP-88: Millisecond-Resolution Close Times​

Garand presented CAP-88, which he expects to be a straightforward change.

The problem: All ledger close times on Stellar are whole seconds. This has two effects:

  • Two ledgers cannot close less than one second apart. Sub-second ledgers are still far away, but the limit is there.
  • The network cannot target a ledger time that is not a whole number of seconds. With 5-second ledgers today, a small step such as 4.5 seconds is not possible.

The change: Close times move to millisecond resolution for consensus and validators. The time is the same, it is just not rounded to the second.

What stays the same: Everything a transaction sees still uses whole seconds. This includes the Soroban ledger timestamp, claimable balance predicates, time bounds and minSeqAge. The existing whole-second closeTime in StellarValue stays, and the new millisecond value is added next to it. Downstream systems that decode ledger headers must update their XDR definitions for the new union arms, but they can keep using the whole-second value, or pick up the new one. The near-term targets are steps like 5 to 4 or 3.5 seconds, so whole seconds are still fine at the transaction level. If ledger times get much shorter, the team may revisit milliseconds in the transaction interface.

Questions​

  • Milliseconds for random numbers: Someone in chat suggested that milliseconds in the interface would help pseudo-random number generation. Garand and Dima disagreed. Soroban already has a PRNG on the host, and validators set the timestamp. A Byzantine validator could choose arbitrary millisecond values more easily than whole-second values, which are tied more closely to real-world time.
  • Why not micro or nanoseconds: Network latency in a distributed system makes anything below milliseconds useless at the consensus layer. Stellar launched with whole seconds because ledger times were much longer at the time, and clock sync (NTP) and servers have improved a lot since then.
  • Do validators need synced clocks: No. The validator that proposes a ledger includes its local timestamp in milliseconds. Clocks can still drift between validators, as they can with whole seconds today. The change improves the resolution, it does not require millisecond-level sync.

Please add your comments to the CAP-88 discussion thread.