Use Herd with Sazabi: decode on-chain transactions during an incident

Last verified on Nov 8, 2026.

If your product moves value on a blockchain, some incidents have two halves. Your backend logs a failed submission, and the explanation sits on-chain: a reverted call, a contract that was upgraded under you, a relayer wallet that ran low. Looking those up means switching to a block explorer and reading traces by hand.

Sazabi is AI-native observability and security. With Herd connected, the Sazabi agent reads the on-chain half in the same thread as your service logs, so you can line up a log error with the transaction it refers to.

What the Sazabi agent can do with Herd

Herd runs a hosted MCP server and authenticates with OAuth, so access follows your Herd account. The Sazabi connector page lists four areas, and Herd's docs name the tools behind them:

• Contracts. contractMetadataTool reads ABI signatures, deployment details and token information. It follows proxy implementations and returns the full known implementation history. getContractCodeTool searches verified source, and getDeployedContractsTool lists what a deployer or factory created.
• Transactions. queryTransactionTool decodes traces, logs, transfers, balance changes and contract creations for one real or simulated transaction. getLatestFunctionTransactionsTool and getLatestEventTransactionsTool return the latest 20 matching calls or events for a contract.
• Wallets. getWalletOverviewTool, getTokenActivityTool and getTransactionActivityTool summarize balances, token transfers and enriched activity for an address.
• HAL actions. Herd Action Language lets the agent build, search and simulate actions before anything runs on mainnet.

One limit matters when you plan an investigation. Herd separates registered chains from fully indexed ones. Transaction inspection works on all registered EVM chains. Function and event search and wallet analysis need Base, Ethereum or Monad.

Questions it answers

• What did this reverted transaction call, and which trace step failed?
• Was the contract's implementation upgraded before the errors started?
• Which functions on this contract were called most recently, and with what arguments?
• What is the token balance and recent transfer history of our relayer address?
• Did a simulated call actually run, or hit an address with no code?

A worked example: submissions fail after a contract change

Your backend starts logging execution reverted for settlement submissions on Base. You ask:

Our settlement service logs reverts on Base since about 09:40 UTC. Using
Herd, check whether the proxy at 0x00000000000000000000000000000000000000a1
changed implementation recently, decode the failed transaction
0x00000000000000000000000000000000000000000000000000000000deadbeef,
and show the latest calls to settle() on that contract.

The agent starts with contractMetadataTool, since it returns the proxy's implementation history, and notes whether a new implementation appears before 09

The output is a short chain of evidence: when the implementation changed, which internal call reverted and how successful calls differ. Your logs supply the other side, such as which requests produced that hash.

Keeping it read-only

The Sazabi docs say writes are governed by the per-connection read-only toggle. For incident work, that is the sensible default. Herd also warns that a successful simulation can still call an address with no deployed code, so zero gas and no calls or logs mean nothing ran. Ask the agent to say so when it sees that.

How it fits with other integrations

On-chain data answers part of the question. Your own telemetry answers the rest, and it arrives through OpenTelemetry or your cloud, such as AWS. If the settlement flow runs as a workflow, see durable execution. Browse everything on the integrations page, and see pricing for Sazabi plans.