Contract creation timestamp shown in UI doesn't match actual creation block timestamp

[torztomasz]

Describe the bug

The contract page in the explorer is displaying the wrong creation timestamp. Two different API endpoints return two different values for the same contract, and the UI is showing the incorrect one.

Contract: 0x20c00000000000000000000014f22ca97301eb73 (chainId 4217)

Endpoint A — /api/contract/creation/{address}

{
  "creation": {
    "blockNumber": "5253168",
    "timestamp": "1771320070",
    ...
  },
  "error": null
}

→ 1771320070 = 2026-02-16 17:21:10 UTC

Endpoint B — /api/address/metadata/{address}

{
  "address": "0x20c00000000000000000000014f22ca97301eb73",
  "chainId": 4217,
  "accountType": "contract",
  "lastActivityTimestamp": 1776423012,
  "createdTimestamp": 1771409331
}

→ 1771409331 = 2026-02-17 18:08:51 UTC

The two timestamps are roughly 24 hours apart, and the web UI currently displays createdTimestamp from the metadata endpoint, which does not correspond to the timestamp of the block in which the contract was actually created (block 5253168).

Independent verification

I cross-checked this directly against the chain using a binary search over eth_getCode (querying historical block states for whether code exists at the address). The binary search confirms block 5253168 is the actual creation block, matching what /api/contract/creation returns and contradicting what /api/address/metadata returns. So this isn't a "which source do we trust" question — the on-chain truth has been verified independently, and the metadata endpoint is wrong.

Expected vs. actual

Expected: The UI should display the timestamp of the creation block (1771320070 from endpoint A), since that is the on-chain truth.

Actual: The UI displays createdTimestamp (1771409331 from endpoint B), which appears to come from a different source and disagrees with the creation block's timestamp.

Likely root cause

The metadata endpoint isn't actually computing "creation timestamp" — it's computing "first interaction with this address" and labeling it createdTimestamp. Contract creation transactions have to = null, so they're not matched by a WHERE from = addr OR to = addr filter.

Specifically:

• fetchAddressTxAggregate (tempo-queries.ts:1336–1357) only looks at txs.from / txs.to. The deployment tx (where from = deployer EOA, to = null, and the contract address lives in receipts.contract_address) is invisible to it.
• For 0x20c0…eb73, the deployment was at block 5253168 (ts = 1771320070). The first tx where this address appears in from or to was ~24h later (ts = 1771409331). That delta — first‑interaction minus deployment — is exactly the bug.

Where did this happen?

https://explore.tempo.xyz/address/0x20c00000000000000000000014f22ca97301eb73?tab=transfers

Steps To Reproduce

No response

Operating System

None

Operating System version

No response

Browser

None

Browser version

No response

Anything else?

No response