Add `order` parameter to `getEvents` for descending order support

[tomerweller]

What problem does your feature solve?

There's no efficient way to query the N most recent events matching a filter. The getEvents endpoint only returns events in ascending order, forcing clients who want "latest events" to either:

1. Scan the entire retention window and discard all but the last N events
2. Guess a startLedger near the tip and retry with expanded windows on misses
3. Implement binary search to find recent events

This is a common need for any tool that requires fetching latest activity.

What would you like to see?

An optional order field in pagination options:

{
  "startLedger": 1000,
  "pagination": {
    "limit": 10,
    "order": "desc"
  },
  "filters": [...]
}

Value	Behavior
"asc" (default)	Current behavior - oldest first
"desc"	Newest first, starting from endLedger (or latest ledger)

Implementation cost should be low:

• No database changes - existing composite indexes support reverse scans
• Fully backwards compatible - defaults to "asc"

What alternatives are there?

• Client-side filtering: Fetch all events in ascending order, keep last N. Inefficient and wasteful.
• Heuristic windowing: Start queries near latest ledger, expand on miss. Unreliable and complex for clients.
• External indexing: Use a separate service like SubQuery or a custom indexer. Adds operational complexity for a simple use case.

[Shaptic]

There's no efficient way to query the N most recent events matching a filter.

Maybe I'm missing something, but is this a meaningful thing to know? Events are meant to be consumed in chronological order to build a picture of activity, and the "last N" does not really provide any sort of picture.

If you know the last ledger you are interested in, this is trivial of course (noted by point 2 in the issue, but I don't see why someone wouldn't know when they want to start from...), and the ledger timestamp provides a clear, delineated time at which your "event story" begins.

Allowing a search into an arbitrary amount ledgers into the past from the current tip until N <= 200 events are found feels (a) mildly dangerous since it's an unbounded search and (b) not very useful since you should always have some notion of time around the events you're interested in. Can you provide a clear example where this would be useful and has no workaround?

[tomerweller]

Well I created this issue because I was looking for it :)

There is no role that events should be consumed in an ascending order. I think it's perfectly legitimate for a system to decided to index in reverse order within the retention window if, for example, they have a static sized window of events they're interested to maintain.

Given that we're trying to get consumers to prefer rpc's getEvents over horizon functionality it seems appropriate to give them tools to do so, especially now with rich cap67 events.

It is also very common and well established for APIs that offer ordered results to offer these in both directions.

From a cost perspective this introduces some minimal complexity to the query logic (as demonstrated in the draft pr) but no operational complexity.

I believe the benefits outweigh the cost.

[Shaptic]

this introduces some minimal complexity to the query logic

My concern is that while the added complexity is average, it's added to an already overloaded and complex endpoint that is difficult to understand (#426 covers essentially rewriting this entirely).

Well I created this issue because I was looking for it :)

For sure, after checking out Lumenitos I can see your use case, but I would argue that's bordering on indexer territory which is a fairly explicitly not the role of RPC. Also, back-filling a time-based (as in, check the last day) rather than count-based window of events makes more sense, then sorting client-side easily on ID.

Of course it's nice for prototyping to use RPC for this, but if you wanted this to be prod scale you'd want your own backend: that's the model we've been trying to encourage from the get-go, basically by design by only offering limited history and "streaming-like" result ordering. Adding this also sets the precedent for other endpoints ("why does getEvents support this but getLedgers doesn't?") which expands the complexity and impact.

It is also very common and well established for APIs that offer ordered results to offer these in both directions.

The API we're emulating here, eth_getLogs, actually doesn't offer pagination at all; it's arguably regrettable that we support pagination in the first place 😆

---

I'm not entirely opposed to adding the feature, but I just want to offer the arguments against it and point out existing workarounds (2 isn't that bad imo and fits RPC + blockchain ethos). Regardless, we need to discuss as a team as there may be more detail and nuance that we're both missing here in adding this.