EIP-6372: Contract Clock

Amxx · January 25, 2023, 12:44pm

Following the work on EIP-5805, we decided to spin off the clock part as its own EIP

sbacha · June 29, 2023, 11:33pm

Hey @Amxx I have a few questions/suggestions if you dont mind:

Why state that it must be “not decreasing” — why not say monotonically increasing?

Their does not seem to be support for sub second precision, which is actually available in Quorum.

I have seen contracts that actually use different time standards than the normal civilian UTC

I have seen use cases for having timestamps in WAD

github.com

IPOR-Labs/ipor-protocol/blob/main/contracts/libraries/Constants.sol

// SPDX-License-Identifier: BUSL-1.1
pragma solidity 0.8.16;

library Constants {
    uint256 public constant MAX_VALUE =
        115792089237316195423570985008687907853269984665640564039457584007913129639935;

    uint256 public constant D18 = 1e18;
    uint256 public constant D21 = 1e21;
    int256 public constant D18_INT = 1e18;
    uint256 public constant D36 = 1e36;
    uint256 public constant D54 = 1e54;

    uint256 public constant YEAR_IN_SECONDS = 365 days;
    uint256 public constant WAD_YEAR_IN_SECONDS = D18 * YEAR_IN_SECONDS;
    int256 public constant WAD_YEAR_IN_SECONDS_INT = int256(WAD_YEAR_IN_SECONDS);
    uint256 public constant WAD_P2_YEAR_IN_SECONDS = D18 * D18 * YEAR_IN_SECONDS;
    int256 public constant WAD_P2_YEAR_IN_SECONDS_INT = int256(WAD_P2_YEAR_IN_SECONDS);

    uint256 public constant MAX_CHUNK_SIZE = 50;

This file has been truncated. show original

I also have a proposal still in draft for a different timestamp unit

Finally, GitHub - bokkypoobah/BokkyPooBahsDateTimeLibrary: Gas-Efficient Solidity DateTime Library is the Gold standard in terms of date and time libraries out there. Its been rigorously tested and audited. Its based off of the US Naval Observatory specifications and fwiw NTP is directly dependent upon them for accuracy etc.

If your available to talk on telegram my username is @sambacha

Amxx · March 5, 2026, 10:18pm

Hello, and sorry for the (very) late answer.

About the use of other clocks beside timestamps and block number, I believe they are supported (and that is exactly what this ERC is designed for).

For example if you have access to a milisecond clock, you could do

    function clock() public view virtual returns (uint48) {
        return (time in miliseconds);
    }

    function CLOCK_MODE() public view virtual returns (string memory) {
        return "mode=timestamp&step=milliseconds";
    }

or any other description you want.

The limitation would come from uint48 is not a big enough type. 2**48 milliseconds from 1-1-1970 is march 5th 2026 .

Using WAD would make things even worst (I have no clue why anyone would need this level of precision in a blockchain context).

Amxx · March 5, 2026, 10:23pm

I don’t see any incompatibility between this and ERC-6372. I’m not sure why anyone would want to represent date and time in “human” format inside a smart contract (IMO, this format should only be seen by humans in UIs).
Also curious if this library not supporting leap seconds might ever become an issue.