Hibachi exchange profile

Hibachi offers leveraged crypto perpetuals alongside stablecoin-funded foreign-exchange trading. Its trading guide separates continuously available crypto markets from weekday FX markets and requires an FX-enabled subaccount for the latter. That distinction matters when comparing activity figures or interpreting a product page focused on currencies: the documented crypto service remains part of the exchange.[1]

Protection attached to a new order becomes active after its first fill. Cancelling an entirely unfilled parent cancels its attached protection; fully closing the position also removes associated take-profit and stop-loss instructions. A triggered instruction therefore needs monitoring until the intended position change is confirmed.[2]

Hibachi applies cross-margin within an account: the same collateral supports its positions, and unrealised profit or loss changes usable equity. Initial margin is position notional divided by the market’s permitted leverage. Maximum leverage is an opening constraint, not a promised amount of loss protection. A hypothetical 10,000 USDT position at a 20-times maximum requires 500 USDT of initial margin before other requirements or costs.[3]

Subaccounts provide a separate boundary. Each has its own balances, positions and margin calculation, so a strategy can be separated from another subaccount’s exposure. Positions inside a particular subaccount still share its collateral. Transfers between these accounts require the platform’s security verification; moving funds changes the receiving and paying accounts’ available risk capacity.[4]

The pricing guide distinguishes the external spot reference, the most recent execution and the mark used for risk. It describes a spot reference using Pyth and Stork, while the mark combines price inputs through a median calculation. A chart’s latest trade can therefore differ from the price used for margin or a trigger. These reference prices do not eliminate execution slippage.[8]

Volume is calculated at 00:00 UTC daily, with the revised tier normally taking effect around 03:00 UTC. Subaccount volume aggregates; vault volume is separate. At the base rate, a hypothetical 10,000 USDT taker fill costs 4.50 USDT. Opening and closing the same notional as taker costs 9 USDT before funding, slippage or transfer charges.[10]

Perpetual funding is an additional hourly transfer between opposing positions. Its direction depends on the relationship between the perpetual and underlying market, so either side can pay or receive. Hibachi describes this as a payment between traders rather than an exchange trading commission. The rate can change while the position remains open; a low maker commission does not make a funded leveraged position costless.[11]

The withdrawal guide distinguishes network gas from an additional convenience charge for instant withdrawals. It does not supply a universal fixed convenience tariff in the inspected passage. The quoted withdrawal cost and available route should therefore be checked at the point of exit, especially when comparing ordinary and accelerated delivery.[14]

Accounts can be opened using a supported wallet or email. The wallet route requires deterministic signatures: the guide warns that a different signature method can prevent access to the derived account. Its supported examples include MetaMask, Phantom, Trust, Fireblocks and Fordefi; it identifies MPCVault and Gnosis Safe as unsupported. The newer onboarding page includes Arc, extending the older two-network FAQ.[13]

Ordinary withdrawals are limited to collateral that is not required for open exposure. Withdrawing the maximum while positions remain can leave less room before liquidation. The older withdrawal walkthrough uses an Arbitrum destination and gives 10–20 minutes as an expected standard duration, not a delivery guarantee. Its route description should not be generalized automatically to every newly supported deposit chain.[14]

Internal transfers use a selected source account, destination account and amount, followed by two-factor verification. They move available collateral within Hibachi rather than proving an external blockchain withdrawal has completed. Reconcile the receiving balance and recheck the source account’s margin after a transfer, particularly if it still holds positions or pending orders.[15]

Hibachi’s verification documentation describes on-chain checks over collateral movements and account-state transitions, including signatures, margin and liquidation. This is the project’s account of its verification design. It does not by itself establish an independently audited recovery guarantee, an insured bank deposit or identical key control across email and wallet accounts.[17]

The risk panel adds unrealised trading and funding results to the account’s USDT balance when displaying net equity. It also distinguishes position leverage from exposure committed by pending orders. The guide describes cancelling pending orders first when limits are exceeded, followed by position liquidation if necessary. A displayed cash balance alone is therefore insufficient to assess how much can be withdrawn or committed to another order.[5]

Liquidation is described as a sequence of partial market orders intended to restore the account’s health, repeated if the account remains below its requirement. The displayed liquidation price marks the onset of that process rather than a guaranteed price at which every position is closed. It can change as collateral, prices and positions change. A liquidation charge contributes to the protocol’s insurance fund.[6]

The insurance fund is an internal resource intended to absorb negative balances and exceptional losses in the protocol. Hibachi says it is seeded initially and grows through liquidation fees. The inspected page does not establish an external insurance policy, an individual customer claim limit or statutory deposit compensation. Its existence should be understood as one part of the liquidation design, with a different role from an insurer’s contractual promise to a depositor.[12]

The terms prohibit access by covered US and UK persons and restrict sanctioned persons and territories, including Iran, Cuba, North Korea, Syria, Myanmar and named occupied Ukrainian regions. They prohibit VPN circumvention. Their scope extends beyond a user’s current IP address to residence, organization and other specified connections; checking that the page loads is insufficient to establish eligibility.[26]

Email access uses a verification code and two-factor security, while wallet access relies on the supported signing process. The public onboarding workflow does not establish universal permission to use every market. In particular, a technical account connection should not be confused with a country-specific derivatives authorization.[13]

The mobile guide describes email access through a home-screen shortcut and wallet access through a wallet’s in-app browser. It claims the mobile trading functions match the desktop interface. A home-screen shortcut is not evidence of a separately distributed app-store application. The key-management distinction remains relevant when changing browsers or devices; a mobile session does not remove the need to preserve the appropriate account credentials.[18]

The official Python SDK exposes deposit and withdrawal history, trade records and settlement history. Its documented recent-history methods return up to 100 deposits and 100 withdrawals, and up to 100 trades. Those limits matter when assembling a long-term record: a single recent-history response is not a complete tax statement. A jurisdiction-specific tax certificate or full-history retail CSV workflow was not established from this SDK page.[21]

No dormant-account charge was established from the inspected published tariff. That finding is narrower than a promise of permanent access: the terms separately reserve suspension and termination powers, including restrictions on trading. Keep the state of an accepted order separate from whether the browser is open.[26][10]

The inspected terms name Hibachi PTE. LTD. and affiliates and use Singapore governing law. No entity-specific financial permission or customer compensation entitlement was established from that contract; neither is inferred from the company name.[26]

The project’s About page presents Hibachi as an exchange with privacy and verifiable execution as design priorities. It also discusses a long-term objective of unrestricted exits. An objective described in project positioning is not a present unconditional withdrawal mechanism; the operational exit rules and account model remain the relevant reference.[27]

No independently verified number of active people was established for this profile. Aggregate notional can grow through leverage, repeat trading and multiple accounts; it cannot be converted into a headcount of customers.[28]

Operator

Hibachi PTE. LTD. and affiliates

Exchange model

Hybrid

Service scope

Crypto perpetuals and separately enabled FX trading; vault participation has its own mandate.

Client types

Not established

Pricing publication

Public pricing

Funding scope

USDT on Arbitrum; USDC on Base and Arc, subject to the specified transfer form.

Custody and asset handling

Email accounts use exchange-managed signing; wallet accounts use locally stored derived keys.

Client eligibility

Territorial and sanctions restrictions apply, including covered US and UK persons.

Support

Support-ticket form and official Discord.

Authorisation and registration scope

No entity-specific financial permission established from the inspected contract.

Exchange metadata checked 20 Oct 2026Source 1Source 16Source 26Source 13Source 10Source 19

Vaults pool capital under a curator’s trading mandate. Depositors receive non-transferable shares; the curator can trade the vault’s funds but cannot withdraw them. Access can depend on a whitelist, capacity or a subscription window, and the risk is isolated at vault level. Management and performance charges are specified by vault, with a high-water-mark mechanism for performance fees.[22]

The Fire Liquidity Provider vault is curated by Kappa Lab and deploys capital in market making and liquidation-related liquidity. Its published charges are 0% management and 20% performance. Access is gated. The page describes allocations linked to points and realized-PnL competitions, with weekly volume bands, rather than an unlimited subscription open to every account. Campaign eligibility is not a guaranteed allocation or return.[23]

Hibachi Points track trading and other rewarded activity. The page describes a weekly distribution and anti-abuse controls; points are not presented as a fixed cash balance that can simply be withdrawn. A dated 5–12 October 2026 challenge shown in the material had already ended at this profile’s check date. Its presence on the page does not extend the campaign.[24]

The referral page describes a three-level share of generated fees: 10% for direct referrals, 5% at the next level and 1% at the third. These are conditional fee-linked rewards rather than a bonus on every deposit. The dedicated page says weekly Monday payment, while the FAQ says Tuesday; the public materials do not establish a consistent exact payout day.[25][19]

Hibachi links official API documentation, a Python SDK and integration resources including CCXT. These are tools for reading the market and implementing the account owner’s instructions. A platform-operated AI trading service or delegated investment mandate was not established from the inspected integration material.[20]

The Python SDK includes order placement, modification and cancellation as well as transfer and withdrawal methods. Its withdrawal method accepts a destination, network, amount and maximum fee, constrained by the account’s maximum withdrawable balance. Do not assume every automation credential is read-only merely because a script was initially created to fetch prices.[21]

Request budgets are also operational constraints. The limits guide lists 350 REST requests per 10 seconds per IP and separate placement, amendment and cancellation budgets; each action in a batch counts. An application that reaches a budget must reconcile existing orders before repeated retries create a misleading local view.[7]