Find the question ID

For the UMA CTF adapter / Managed Oracle questions covered by this guide, the question ID is:

question_id = keccak256(request ancillary data bytes)

If you already index the Optimistic Oracle, use the exact ancillaryData bytes from the request's RequestPrice event. You do not need another discovery endpoint.

From an indexed request

import { keccak256 } from 'viem';

// A decoded RequestPrice event from your existing indexer.
// ancillaryData is the original 0x-prefixed bytes, not a rewritten question.
const ancillaryData = requestLog.args.ancillaryData;
const questionId = keccak256(ancillaryData).toLowerCase();

const signingDataUrl =
  `https://api.risklabs.co/v1/proposals/${questionId}/signing-data`;

Retain the event's requester, oracle identifier, timestamp, and emitting oracle address as well. The question ID identifies the question; those fields identify its request round and must also match the signing data.

Hash the exact bytes

• Include any initializer suffix already present in the request. The adapter appends it before hashing and requesting a price; the request event already contains it. Do not append it again.
• Preserve whitespace, punctuation, casing, and encoding. Do not hash only the market title or reconstruct the question from displayed text.
• Hash the bytes represented by the hex value. Do not UTF-8 encode the literal characters 0x…, and do not use SHA-256 or SHA3-256 in place of Ethereum Keccak-256.
• Use the original request ancillary data, not the later DVM dispute data with an extra ooRequester stamp.

If your indexer stores only the exact decoded UTF-8 text, convert it back to bytes first. This is valid only when that text is a lossless representation of the complete original ancillary data:

import { keccak256, toHex } from 'viem';

const questionId = keccak256(toHex(exactAncillaryText)).toLowerCase();

The question ID is distinct from the oracle's bytes32 identifier (such as YES_OR_NO_QUERY), a condition ID, or a token ID. This derivation is an adapter convention, not a universal ID scheme for every Optimistic Oracle requester.

For JSON requests, the market rules schema explains the fields, answer mappings, and clarification updates. Read clarifications when deciding the answer, but keep the original ancillary bytes for hashing and signing.

Before signing

Compare the preparation response's question_id and complete request against your indexed data. A re-request can keep the same question ID while changing its timestamp and signing context. The API must also know the request and consider it open; deriving the ID alone does not make it eligible for a proposal.

Continue with prepare, authorize, and track.