You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
--ascending flag has no counterpart; sort defaults to ascending with no way to sort descending #17
The markets list and events list commands sort results in ascending order by default. The --ascending flag exists but only reinforces ascending — there is no --descending flag or way to reverse the sort direction.
The help text implies descending should be the default ("Sort ascending instead of descending"), but results are always ascending regardless of whether --ascending is passed.
Steps to reproduce
# Without --ascending flag (should default to descending per help text)
polymarket markets list --active true --order volume --limit 5
# Returns markets with $0.00 volume (ascending order)# With --ascending flag (no difference)
polymarket markets list --active true --order volume --limit 5 --ascending
# Same result — still ascending
Expected behavior
Default sort direction should be descending (as the help text implies)
Or: add a --descending flag to allow explicit control
Actual behavior
Sort is always ascending. The --ascending flag is a no-op since ascending is already the default. There is no way to retrieve e.g. the highest-volume markets without fetching a large result set and sorting client-side.
I've submitted a fix for this in PR #43. Changed all list commands to use maybe_ascending() so the parameter is only sent when --ascending is explicitly passed, letting the API default to descending sort.
Activity
fix: correct sort order default to descending (Polymarket#17)
fix: correct sort order default to descending (Polymarket#17)
fix: correct sort order default to descending (Polymarket#17)
feat: add --descending flag to all list commands
fix: omit ascending param when not set, letting API default to descen…
mvanhorn commentedon Mar 10, 2026
I've submitted a fix for this in PR #43. Changed all list commands to use
maybe_ascending()so the parameter is only sent when--ascendingis explicitly passed, letting the API default to descending sort.