feat: read a whole market's depth in one call from Python

[MicBun]

get_full_market_depth(query_id) returns aggregated volume per price level for
both outcomes from one read, each level tagged with the outcome it rests on.

Related, no closing keyword:

• resolves: https://github.com/truflation/website/issues/4445
• https://github.com/truflation/website/issues/4387

#4445 is the Problem this action was written for and is already closed, by the
sdk-go and sdk-js PRs that consumed it. Python's consolidated book was reading
through it from the moment the preceding PR landed the sdk-go pin, so the job
story is satisfied without this. What is left is the direct accessor, which is
API parity rather than the problem.

Why

get_market_depth answers for one outcome, so comparing the two sides of a
market takes two calls at two independent points in time. An order landing
between them appears on one side and not the other, and the pair then describes
a market state that never existed. One statement is one snapshot, and that whole
class of artifact goes away.

The node has carried get_full_market_depth since trufnetwork/node#1413 and it
is live on mainnet. sdk-js and sdk-go both expose it. Python was the last SDK
reading a market two calls at a time.

What is in it

• get_full_market_depth(query_id) on TNClient, returning FullDepthLevel
  rows — outcome, price, buy_volume, sell_volume. Same aggregation as
  get_market_depth, for the whole market instead of one outcome. Rows arrive
  YES first then NO, price ascending within each.
• GetFullMarketDepth in bindings/bindings.go, delegating to sdk-go.
• Unit tests pinning the wrapper: forwarding, decoding, and that the outcome tag
  survives. The tag is the only thing separating a YES level from the NO level at
  the same price, so the fixture puts a sell at 60 on each side — lose the tag
  and the two rows are indistinguishable.
• A live check that the whole-market read and two per-outcome reads describe the
  same book, plus the live discovery scan switched over to it: "is this market
  two-sided?" is exactly the question this action exists to answer, so it now
  costs one read per market rather than two.

Testing

go build ./... and go vet ./bindings/ clean, bindings rebuilt with
make gopy_build.

• 105 offline tests pass.
• tests/test_order_book.py passes against a local node (44 tests).
• TN_LIVE_NODE_URL=https://gateway.mainnet.truf.network pytest tests/test_order_book_live.py
  — 5 passed against mainnet, including the new equivalence check.

The equivalence check is the one that matters. If the two reads ever disagreed on
anything but timing, every consolidated ladder built on the new one would be
wrong while the per-outcome reads stayed right, and nothing offline would notice.
It re-reads to confirm the market held still before asserting, so a moving book
skips rather than fails.

What is not in it

get_market_depth is untouched and stays the right call when you want one
outcome — a depth chart, or a bot quoting a single side.

get_consolidated_order_book needs no change: it already reads through this
action inside sdk-go, from the pin #132 brought in. This adds the direct
accessor for callers who want the raw both-outcome depth, which is what sdk-js
and sdk-go each expose alongside their consolidated method.

Note on the base branch

Was stacked on #132 while that was open. #132 has since merged, so this now
targets main and carries a single commit.

• feat: read consolidated order books from Python #132

[holdex]

Time Submission Status

Member	#	Time	Running Total	Status	Last Update
MicBun			3h	✅ Submitted	Aug 7, 2026, 4:02 PM

---

Submit or update total time with:

@holdex pr submit-time 2h

Add time on top of previous submission with:

@holdex pr add-time 1h30m

See available commands to help comply with our Guidelines.

[coderabbitai]

Warning

Review limit reached

@MicBun, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 31 minutes

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: bdbcdfd5-0bbb-4f8d-9d82-d583cbc79624

📥 Commits

Reviewing files that changed from the base of the PR and between 2433d4f and 4683cb2.

📒 Files selected for processing (6)

• bindings/bindings.go
• docs/api-reference.md
• src/trufnetwork_sdk_py/client.py
• tests/test_full_market_depth.py
• tests/test_order_book.py
• tests/test_order_book_live.py

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[MicBun]

@holdex pr submit-time 3h