Missing ticks from the Chainlink crypto prices websocket feed

[dariuszhang]

I'm experiencing issues with the chainlink crypto price feed sometimes being non-continuous, while the Binance source price seems to be fine.

I've observed that the price feed normally broadcasts a tick every second, but for chainlink souce sometimes the data looks like this:

1768214356000,2026-01-12T10:39:16.000Z,btc/usd,90475.28334409212
1768214357000,2026-01-12T10:39:17.000Z,btc/usd,90475.35790867529
1768214358000,2026-01-12T10:39:18.000Z,btc/usd,90475.56276204658
1768214366000,2026-01-12T10:39:26.000Z,btc/usd,90475.08856050493
1768214367000,2026-01-12T10:39:27.000Z,btc/usd,90475.08044465078
1768214368000,2026-01-12T10:39:28.000Z,btc/usd,90477.91088156824

Meanwhile the Binance feed gives consistent, continuous data.

Is there a way to ensure a continous feed, or to fetch/query the price history data for these missing seconds?

Or, is there another way to retrieve the start/end prices for the crypto markets effeciently?

[osr21]

The gaps are expected behaviour from the on-chain Chainlink round model, but the RTDS presentation makes it look like dropped data. Worth a precise breakdown.

**How the RTDS Chainlink feed actually works**

Chainlink's `AggregatorV3Interface` on Polygon publishes a new round under two conditions:
- **Deviation threshold**: observed price moves ≥0.5% from the last on-chain `answer`
- **Heartbeat**: 3600 seconds elapse with no deviation trigger (BTC/USD heartbeat; other pairs vary)

The RTDS doesn't re-broadcast at the round cadence — it emits a synthetic interpolated tick **every second**, holding the last known oracle price constant between real rounds. When a genuine new round lands on-chain, the stream jumps to the new `answer`.

Your 8-second gap (10:39:18 → 10:39:26) is the RTDS holding the round-N value because no new on-chain round had landed yet. Round N+1 arrived at 10:39:26, and the stream resumed. This isn't a missed tick — the oracle *did not update* during that window. Binance doesn't have this characteristic because it streams a new tick every second regardless of price movement.

You can verify directly against the feed contract:

```typescript
import { ethers } from "ethers";

const AGGREGATOR_ABI = [
"function latestRoundData() view returns (uint80 roundId, int256 answer, uint256 startedAt, uint256 updatedAt, uint80 answeredInRound)",
"function getRoundData(uint80) view returns (uint80 roundId, int256 answer, uint256 startedAt, uint256 updatedAt, uint80 answeredInRound)"
];

const provider = new ethers.JsonRpcProvider("https://polygon-rpc.com");
// BTC/USD on Polygon mainnet — confirmed active feed
const feed = new ethers.Contract("0xc907E116054Ad103354f2D350FD2514433D57F6f", AGGREGATOR_ABI, provider);

const latest = await feed.latestRoundData();
const phaseId  = latest.roundId >> 64n;
const aggRound = latest.roundId & 0xFFFFFFFFFFFFFFFFn;

// Walk back 5 rounds to see actual inter-round durations
for (let i = 0n; i < 5n; i++) {
const rid = (phaseId << 64n) | (aggRound - i);
const r = await feed.getRoundData(rid);
console.log(`Round ${r.roundId}: $${Number(r.answer)/1e8} @ ${new Date(Number(r.updatedAt)*1000).toISOString()}`);
}
```

Inter-round durations vary from ~2s during volatile markets to ~3600s during quiet overnight windows. The RTDS holds the last oracle value flat during those gaps — it isn't interpolating a price trajectory, just repeating the last confirmed on-chain answer.

**Critical implication for BTC-updown-15m trading**

If you're using the RTDS Chainlink feed to estimate the strike price for 5-min/15-min BTC markets, **don't use the RTDS tick stream**. The market contract resolves against the Chainlink round whose `updatedAt ≤ windowStartUnix` — a specific on-chain value, not the RTDS interpolation. Use `getRoundData` with a binary search on `updatedAt` to find the canonical strike round. The RTDS ticks between real rounds are hold values, not oracle data, and will give you a systematically wrong strike during high-frequency opens.

[osr21]

This is expected behaviour from the Chainlink oracle round model, not a bug in the RTDS feed.

Why gaps appear

Chainlink feeds on Polygon commit a new round only when either the deviation threshold (~0.5 % for BTC/USD) or the hourly heartbeat fires. Between rounds the RTDS re-broadcasts the last committed value — so an 8-second gap in your log simply means BTC stayed inside a ~$452 band and no new round was published.

The timestamp field in the RTDS payload is the Chainlink updatedAt (the round-commit time on-chain), not a wall-clock broadcast time. Two successive messages with the same timestamp are the same round repeated.

Practical de-duplication

const lastRound = new Map<string, number>(); // symbol → roundId

onMessage((_, msg) => {
  const { symbol, roundId, value } = msg.payload as any;
  if (lastRound.get(symbol) === roundId) return; // same round, skip
  lastRound.set(symbol, roundId);
  // process genuine new tick
});

Upcoming TWAP topics

The new crypto_prices_twap_thirty / crypto_prices_twap_sixty RTDS topics launching in August compute a windowed average over 30 s and 60 s of oracle observations. They are inherently smoother than the raw tick feed and absorb these inter-round gaps into the window calculation. If your strategy needs a continuous price signal rather than oracle ticks, the TWAP topics will be more suitable once they go live.

[osr21]

Confirmed gap pattern + subscription format that resolves it

We hit the same intermittent-gap behaviour on the Chainlink TWAP feed and traced it to two separate issues:

### 1. Subscription `type` field matters

The RTDS protocol accepts a `type` filter on each subscription entry. Using `type: "*"` (or omitting it and relying on defaults) causes the server to send **all** event types for the topic — including internal heartbeat/metadata frames that reset the client's "last message" timer without carrying a price value. This makes gaps *appear* shorter in wall-clock time than they actually are for price data.

The correct subscription for Chainlink TWAP prices:

```json
{
"action": "subscribe",
"subscriptions": [
  { "topic": "crypto_prices_twap_thirty", "type": "update" },
  { "topic": "crypto_prices_twap_sixty",  "type": "update" }
]
}
```

With `type: "update"` you only receive frames that carry a new price value, making the gaps visible and measurable.

### 2. The TWAP feed is not second-by-second by design

The 30s and 60s TWAP windows update when the rolling average changes by a meaningful amount — not on every wall-clock second. Gaps of 8–10 seconds in the 30s window and 15–20 seconds in the 60s window are normal under low-volatility conditions. The data you highlighted (8-second gap at 10:39:18 → 10:39:26) is within the expected publish cadence.

### Payload format (raw WebSocket, bypassing the SDK)

```json
{
"topic": "crypto_prices_twap_thirty",
"type": "update",
"payload": {
  "symbol": "BTC",
  "value": "64313.16",
  "timestamp": 1786534567000
}
}
```

Note: `value` is a decimal string (NOT E18 fixed-point), `timestamp` is epoch milliseconds. The SDK wraps this and adds `windowSeconds` client-side — it is not present in raw frames.

### Gap detection in production

We track `lastUpdated` per symbol and fire a stale-data warning when `Date.now() - lastUpdated > expectedIntervalMs * 2`. This gives early warning without the false positives from heartbeat frames masking the true gap.