A user-facing product determines the trading experience; an API and SDK for developers, however, determines how much new stuff a protocol can grow.

If market data, positions, and trade records can only be viewed from the official interface, this project's room for expansion is basically tied to its own team. If the data can be read and trading capabilities can be opened up through standardized interfaces, only then do third-party developers have the opportunity to build new terminals, data dashboards, position alerts, strategy tools, and account management products.

@Hertzflow_xyz has already put a REST API for BNB Smart Chain in the official documentation. The coverage includes market lists, prices, user activity, Vaults, liquidity pools, leaderboards, recommendations, XP, Credit, and Dashboard data, and you can also look up historical K-lines.

All these interfaces are publicly accessible GET requests. No API Key is needed, and they won’t trigger on-chain transactions. In terms of design, "reading data" and "moving assets" are kept distinctly separate: data-type products can look up market information and historical activities without touching users’ wallets at all. When it truly involves asset changes, authorization and signatures remain within the internal trade flow.

More importantly, it’s @hertzflow/sdk-v2. This TypeScript SDK unifies contract read/write, oracle and statistical interfaces, trade simulation, derivative calculations, and account event subscriptions under a viem-based interface.

Developers can read the market, tokens, prices, positions, and orders—and also compose market orders, limit orders, reduce positions, take-profit/stop-loss, and margin adjustments. Before submitting a trade, they can also estimate Gas and protocol execution fees. The liquidity module handles the storage and retrieval of HzLP and HzV, while the events module can listen for position, order, and fund changes.

The real value of all this is eliminating duplicated wheel-spinning. Developers don’t have to parse every piece of contract data themselves, nor re-handle price precision. They also don’t need to stitch together or cobble together oracles and statistical services—so they can focus their effort on the product itself.

For example: market tools can use market lists plus K-line data to build cross-asset dashboards; position assistants can subscribe to order changes and send alerts when conditions are triggered; new trading front-ends can run simulations first, then pass the signature to the wallet. Hertzflow provides the underlying protocol capabilities, while surrounding applications are responsible for shaping the user experience into their own forms.

Currently, the official API and most protocol SDK modules are still mainly based on the BSC testnet. As the mainnet contract configuration and interface stability gradually catch up, this developer infrastructure has a chance to become an important path for Hertzflow to expand its user entry points.

A protocol’s growth doesn’t only rely on the official team continuously adding features—it also depends on external developers being willing to keep building on top of it. The API and SDK are a concrete step that Hertzflow has made for this purpose.