Skip to content
TraceFast Docs

Relations of an address at a block

Open the USDC contract in TraceFast →

The relations an address was the subject of at the end of one block — which implementation a proxy pointed at, which beacon it read, who administered it, where an account had delegated — each with the window of blocks it held for.

GET https://tracefast.xyz/api/v1/chains/1/entities/{address}/relations/at-block?block={block}
ParameterInTypeNotes
addresspathstring0x-prefixed, 40 hex characters, any case
blockqueryinteger, requiredthe block to answer about — the state at the end of it

Access — an API key on the Intelligence plan or higher (plans), or no key at all: pay per call with x402 at the same path on https://mpp.tracefast.xyz/api/v1, at the price its 402 states. As a tool for AI agents: get_entity_relations_at_block on the MCP server. Stable — see stability.

chains/1 is a literal: other chain ids answer 404 chain_not_supported. An unknown parameter is refused rather than ignored.

What it covers, and what it does not

  • The subject side only. The answer is always "what did this address point at". There is no direction parameter. For "who pointed at it", use the relation history with direction=object.
  • Only the relation ids in coveredFamilies. A relation outside that list is not listed whether or not it held. The current relations cover more ids than the history does.
  • Absence means "not proven", never "false".
  • A block past the covered history is refused with the highest block that can be answered.

Response

200 application/json for the USDC proxy, here with ?block=20000000:

{
  "data": {
    "chainId": 1,
    "address": "0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48",
    "block": 20000000,
    "coverageBlock": 25924843,
    "addressKnown": true,
    "intervals": [
      {
        "attributeId": "relation:was_implementation_of",
        "counterpart": "0x43506849d7c04f9138d1a2050bbf3a0c054402dd",
        "startBlock": 18963716
      }
    ],
    "coveredFamilies": [
      "relation:was_implementation_of",
      "relation:eip7702_delegates_to",
      "relation:proxy_reads_beacon",
      "relation:proxy_administered_by",
      "relation:freeze_membership"
    ]
  },
  "meta": {
    "chain": "ethereum",
    "timestamp": 1789047687092,
    "cached": false,
    "asOfBlock": 25924843,
    "docs": "https://docs.tracefast.xyz/api/address-relations-at-block"
  }
}

At block 20,000,000 the USDC proxy pointed at the implementation 0x4350…02dd, which it has used since block 18,963,716. The interval has no endBlock: it was still open at the end of the covered history.

data

FieldMeaning
chainId1, Ethereum mainnet
addressthe address, lowercase — always the subject of the relations listed
blockthe block you asked about, echoed
coverageBlockthe highest block the history has been computed up to
addressKnownfalse when the history does not know the address at all — a different answer from an empty intervals. Absent when the history does not state it
intervals[]the relations that held at block, each with its window
coveredFamiliesthe relation ids the history is built for

An interval

FieldMeaning
attributeIdthe relation id, relation:name
counterpartthe object of the relation, lowercase
startBlockthe first block the relation held at
endBlockthe last block it held at. Absent when the interval was still open at the end of the covered history
valuethe relation's value over the interval, for relations that carry one; absent otherwise

Errors

StatuscodeWhendetails
400bad_requestblock absentreason: block_required
400bad_requestblock is 0 or not a numberreason: block_not_positive, block
422block_not_availableblock is past the covered historyreason: block_not_available, maxAvailableBlock

Malformed input, unknown parameters and the key check's 401/403/429 are the same for every method — see conventions and API keys.


Last updated 22 Oct 2026, 08:06 UTC · verified against TraceFast v1.0.261 · Markdown