Skip to Content
DocumentationRadixTimestamp Validation

Timestamp Validation

The Challenge of Market Hours

One of the key challenges in providing reliable price data for on-chain applications is handling the different operating hours of various markets. While cryptocurrency markets operate 24/7, traditional markets like US equities have specific trading hours and are closed on weekends and holidays.

This creates a unique challenge for oracles that need to provide valid price data at all times:

  • Crypto markets: Generate new price ticks continuously
  • Traditional markets: Only generate price ticks during trading hours

The Problem with Simple Timestamp Validation

In the initial version of the Morpher Oracle, we used a simple timestamp validation approach:

  1. The Oracle would sign price data with a timestamp
  2. The smart contract would verify that the timestamp wasn’t too old (e.g., not more than a few minutes)

This approach works well for 24/7 markets like crypto, but creates problems for traditional markets:

Example: US Equities After Hours

If a user tries to execute a transaction using Apple (AAPL) price data at 8:00 PM EST on a Friday, the most recent price tick might be from 4:00 PM EST when the market closed. The timestamp would be 4 hours old, causing the Oracle to reject the data as “stale” even though it’s the most recent valid price.

This limitation made it difficult to use the Oracle for traditional markets outside of regular trading hours, which is a significant constraint for many DeFi applications.

Our Solution: Enhanced Timestamp System

To address this challenge, we’ve developed a more sophisticated timestamp validation system that takes into account market operating hours and status.

Key Components of the New System

The enhanced timestamp system introduces three distinct timestamps:

  1. Oracle Timestamp (oracle_timestamp)

    • When the Oracle signs the price data
    • Must not be older than 2 minutes from the current time
    • Ensures the Oracle signature itself is recent
  2. Data Timestamp (data_timestamp)

    • When the most recent market data was received
    • For open markets, should be very recent
    • For closed markets, will be from when the market last closed
  3. Market Status Timestamp (market_status_timestamp)

    • When the market status last changed (e.g., from “open” to “closed”)
    • Initially set equal to the data timestamp
    • Will be managed by a dedicated market hours service in future updates

Market Status Types

The system also introduces a market status field that indicates the current state of the market:

  • open: Market is currently trading
  • closed: Market is closed (end of day, weekend, holiday)
  • pre: Pre-market trading
  • after: After-hours trading
  • trade-halt: Trading temporarily halted

Validation Rules

With these new components, the validation rules become more nuanced:

  1. Oracle Timestamp Validation

    • oracle_timestamp must be less than 2 minutes old
    • Ensures the Oracle signature is recent
  2. Data Freshness Validation

    • For open markets: data_timestamp should be very recent
    • For closed markets: data_timestamp can be older, but must be less than 1 minute before the market_status_timestamp
    • Example: If market closed at 4:00 PM, the last valid data timestamp could be 3:59 PM

This approach allows the Oracle to provide valid price data for all markets at all times, while still ensuring the data is as fresh as possible given the market conditions.

Implementation Timeline

We are implementing these changes in phases:

Phase 1: New API Endpoint (March-April 2025)

  • Introduction of /v2/prices endpoint
  • Implementation of the three-timestamp system
  • Basic market status integration

Phase 2: Market Hours Service (Q2 2025)

  • Dedicated service to track market hours for all supported markets
  • Real-time updates to market status
  • Enhanced validation based on precise market hours

Phase 3: Advanced Market Status (Q3 2025)

  • Support for special market conditions (circuit breakers, holidays)
  • Predictive market status for scheduled events
  • Extended market metadata

Backwards Compatibility

To ensure a smooth transition, we’re maintaining backwards compatibility:

  • Existing endpoints will continue to function as they do now
  • New endpoints will use the enhanced timestamp system
  • DApps can choose which version to use based on their requirements

Integration Guide

For developers integrating with the Morpher Oracle, we recommend:

  1. Use the new /v2/prices endpoint for all new integrations
  2. Implement validation logic that respects market status
  3. Consider different validation rules for different market types

For detailed integration instructions, see our Integration Guide.

Conclusion

The enhanced timestamp validation system represents a significant improvement in the Morpher Oracle’s ability to provide reliable price data for all market types at all times. By taking into account market operating hours and status, we can ensure that DApps have access to the most accurate and up-to-date price information possible, even for traditional markets outside of regular trading hours.