Add market state verification layer for agent toolkit

[LembaGang]

Hi,

I saw OpenBB is building the agent-compatible market data platform. Impressive stack.

I've been building Headless Oracle — a signed market oracle that gives agents a verified pre-trade gate. Before any trade or capital commitment, the agent fetches an Ed25519-signed receipt confirming the exchange is OPEN. 60-second TTL. 28 exchanges. UNKNOWN must be treated as CLOSED.

It fills a gap in the agent data stack: OpenBB provides the market data agents trade on, but no one provides verified metadata about whether trading is possible right now.

import requests

r = requests.get('https://headlessoracle.com/v5/demo?mic=XNYS')
receipt = r.json()

MCP server at headlessoracle.com/mcp for Claude/Cursor integration. Also on the Official MCP Registry.

If there's interest in adding a market-state verification layer to OpenBB's agent toolkit, I'd love to contribute.

— Mike (headlessoracle.com)

[deeleeramone]

This doesn't seem like a real problem. If you have a trading agent making actual trades for you, then it already has this information from being connected it to your brokerage account and API, which is the real source of truth for the specific order being placed.

[LembaGang]

Fair challenge — and you're right for the common case. If an agent trades through one broker it's authenticated to, the broker's reject is the source of truth for that order, and HO isn't trying to replace that.

Where the broker-as-source-of-truth model doesn't reach:

1. Pre-trade vs. post-submit. The broker tells you by rejecting. A signed pre-trade gate lets a fail-closed agent decline to act at all, rather than submit-and-get-rejected — which still costs the round-trip and can trip risk flags or rate limits in autonomous loops.

2. No broker in the loop. Agents settling on-chain (stablecoin/RWA rails) have no brokerage API rejecting a settlement during an equity halt. There's no source of truth to lean on.

3. Third-party verifiability. The broker knows for itself. A counterparty, auditor, or mandate-issuer checking that an agent acted within its constraints can't see the agent's broker connection — a signed receipt is portable, independent proof rather than the agent's private knowledge.

So it's less "data the agent lacks" and more "verifiable metadata other parties can check" — which is why it shows up in the agent-authorization standards work (it's the reference implementation for environment.market_state in Mastercard's Verifiable Intent). @HOYALIM already built a working provider for it in #7463, fail-closed, with tests — so if the use case lands, the integration's effectively ready.

Completely fair if that's out of scope for OpenBB's toolkit. But that's the problem it solves, not a duplicate of the broker.

[LembaGang]

Worth being precise on one thing I said above, since it matters for evaluating this: environment.market_state is a proposed extension — open as a PR on Mastercard's Verifiable Intent repo, not merged or ratified. I'd rather understate that than have it read as more settled than it is. The standards angle is where this is heading, not where it is today.

On the actual objection, which is the real question: you're right that for an agent trading through a brokerage it's authenticated to, the broker's reject is the source of truth, and HO isn't trying to replace that. The case I'd make is narrower — it's the settings where no broker sits in the loop.

The concrete one is on-chain. An agent settling a tokenized-equity or RWA position on-chain during an equity halt has no brokerage API to reject the settlement — there's no source of truth to lean on, because the chain doesn't know the underlying venue halted. This isn't hypothetical: there are documented cases of on-chain protocols compensating users for liquidations executed against stale post-halt oracle state — attributable losses from exactly this gap. A signed, fail-closed market-state check before the agent acts is a pre-trade gate for the case where the broker-as-source-of-truth model structurally doesn't reach.

The second is third-party verifiability — a counterparty or auditor checking that an agent acted within its constraints can't see the agent's broker connection, but a signed receipt is portable, independent proof rather than the agent's private knowledge.

Completely fair if that's narrower than OpenBB's toolkit is scoped for — that's your call, and I'm not trying to argue it into scope if it doesn't fit. But that's the problem it solves, and it's distinct from "data the agent already has from its broker." @HOYALIM's provider is built, tested, and fail-closed, so if the use case lands, the integration's effectively ready.