# Overview

### Architecture Overview

Hertzflow implements a modular, upgrade-friendly design for decentralized perpetual futures and liquidity management on BNB. At the center lies the **DataStore**, a generic key-value state store that decouples logic from storage, enabling seamless upgrades of underlying modules without state migration. Core logic—funds custody, perps execution, risk controls, and configuration—resides in dedicated contracts (Handlers, Utils, Vaults) that can evolve independently without disrupting external integrations.

The architecture balances **security**, **composability**, and **low-latency execution**:

#### Security

All assets are custodied in specialized Vaults with isolated accounting:

| Vault           | Purpose                       |
| --------------- | ----------------------------- |
| OrderVault      | Holds execution fees          |
| DepositVault    | Holds LP deposit collateral   |
| WithdrawalVault | Holds withdrawal collateral   |
| ShiftVault      | Holds market shift collateral |

Permissioned updates are tightly scoped through a **RoleStore** with granular roles:

| Role                 | Responsibility                  |
| -------------------- | ------------------------------- |
| `ORDER_KEEPER`       | Execute regular orders          |
| `LIQUIDATION_KEEPER` | Execute liquidation orders      |
| `CONTROLLER`         | Call critical handler functions |
| `CONFIG_KEEPER`      | Market and fee configuration    |

Additional protections include **GlobalReentrancyGuard** against reentrancy attacks and **FeatureUtils** for graceful feature deprecation.

#### Composability

A shared **OracleModule** provides normalized, manipulation-resistant price feeds to all consumers:

* OrderHandler, DepositHandler, WithdrawalHandler
* Position utilities (increase/decrease)
* Risk checks and liquidation logic

Off-chain keepers sign prices with block hashes to prevent front-running.

#### Execution Flow

<figure><img src="/files/wlOPtOYtojVg3ArdfLR0" alt=""><figcaption></figcaption></figure>

1. **Request Phase**: Users submit requests via **ExchangeRouter** (multicall-enabled); requests are stored in DataStore with tokens transferred to appropriate Vaults.
2. **Execution Phase**: Keepers monitor the blockchain, trigger execution through specialized Handlers (`OrderHandler`, `DepositHandler`, `WithdrawalHandler`), and provide signed oracle prices via the `withOraclePrices` modifier.
3. **Settlement Phase**: Execution modules (`IncreaseOrderExecutor`, `DecreaseOrderExecutor`) resolve requests using validated prices from the Oracle.

{% hint style="info" %}
The two-step execution model prevents front-running by separating request creation from price-dependent execution.
{% endhint %}

#### REST API

| API              | Description                 | Documentation                                                          |
| ---------------- | --------------------------- | ---------------------------------------------------------------------- |
| Kline API        | Historical candlestick data | [Kline API](/hertzflow-docs/tech-docs/api/kline-candlestick-api.md)    |
| Latest Price API | Current oracle prices       | [Lastest Price API](/hertzflow-docs/tech-docs/api/latest-price-api.md) |

#### Smart Contracts

| Contract       | Description                          | Documentation                                                                |
| -------------- | ------------------------------------ | ---------------------------------------------------------------------------- |
| ExchangeRouter | Create orders, deposits, withdrawals | [ExchangeRouter](/hertzflow-docs/tech-docs/smart-contract/exchangerouter.md) |
| Reader         | Query market and position data       | [Reader](/hertzflow-docs/tech-docs/smart-contract/reader-contract.md)        |

#### TypeScript SDK

### Supported Networks

| Network     | Chain ID | Status      |
| ----------- | -------- | ----------- |
| BSC Testnet | 97       | Active      |
| BSC Mainnet | 56       | Coming Soon |


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://hertzflow.gitbook.io/hertzflow-docs/tech-docs/overview.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.