Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.hyfi.finance/llms.txt

Use this file to discover all available pages before exploring further.

At its core, HyFi is one Uniswap v4 hook (HyFiHook) that overrides UniV4’s pricing function. When a trade is received, HyFiHook routes the trade to the Quoter, which provides a quote. If no Quoter is specified in the hook calldata, a default Quoter for that trading pair is used. There is no concept of adding or removing liquidity to HyFiHook as a whole — Quoters own and manage their own inventory in their Quoter contract, so tokens from different Quoters are isolated for clarity and security. Before the swap, the caller (typically an aggregator) simulates every Quoter registered on the hook for that pair (via our SDK) — the same way the Uniswap interface today simulates routes across pools — and picks the one that gives the best price for the specific trade, and passes its address in hookData. Like Uniswap splitting trades across multiple pools, trades can be split among multiple Quoters in a single tx if that results in the best overall price for the trader.

​
High-level architecture

  1. The trader (or, more commonly, an aggregator routing on their behalf) submits a swap to the Uniswap v4 PoolManager.
  2. PoolManager calls beforeSwap on the HyFiHook attached to that pool.
  3. HyFiHook reads the most recent price update for that trading pair.
  4. The hook resolves the Quoter — either the address passed by the caller in hookData or the pool’s default quoter as a fallback — and calls its getQuote function, passing in HyFiHook’s price as an input to the function.
  5. The Quoter returns a price computed from its own on-chain inventory and pricing logic.
  6. The hook returns the swap delta.
  7. PoolManager settles the tokens between trader and hook, and the trade is done.
The trader sees a single, standard swap() call. Everything — pricing, inventory, and settlement — happens on-chain.

​
Price Oracle

HyFi runs a centralized price oracle that pushes updates on every supported pair every few seconds, or whenever the top bid or ask changes on the underlying CEX — whichever comes first. In practice this means the oracle is updating almost continuously. Critically, the oracle doesn’t publish a single mid-price. It publishes the top bid and the spread, which means Quoters can trivially derive the top ask as well. Giving Quoters both sides of the CEX book lets them implement on-chain pricing logic that mirrors how they actually run their CEX inventory and hedging — instead of being forced to reason about a single price point. The result is less risk for the Quoter, and tighter quotes for the trader.

​
Multi-propAMM coexistence

A single HyFi deployment can host many propAMMs simultaneously:
  • Each trading pair can host multiple Quoters; the aggregator simulates them all and routes the trade to whichever gives the best price, or splits between multiple Quoters if that’s the best overall price.
  • New propAMMs can be added without redeploying the hook — they’re automatically picked up by aggregators that simulate Quoters on the pool.
  • A sensible default Quoter is configured per pool so even naive callers (no routing simulation) get a working price.
This is the core of the platform thesis: integrate once, route to many.

​
Settlement

Users send tokens to the Uniswap v4 PoolManager and receive tokens back from the PoolManager as normal — identical to a regular Uniswap v4 swap. Same approvals to UniV4 itself, no additional approvals, nothing different from the trader’s perspective. Under the hood:
  • All Quoters hold their token inventory in ERC-6909 form inside the PoolManager for gas savings.
  • All Quoters must give permission for HyFiHook to spend their ERC-6909 balances.
  • During execution of a trade, HyFiHook mints the input token ERC-6909 balance to the relevant Quoter and burns the Quoter’s output token ERC-6909 balance.
  • The only way HyFiHook can modify a Quoter’s balances is during execution of a trade — there is no other mechanism. It is effectively the same as giving approval to a contract that calls transferFrom with your tokens.

​
Fees

Each Quoter defines its own fee structure and is responsible for charging it however it sees fit — fees can be flat, or dynamic based on factors like trade direction, the Quoter’s current inventory of each token, volatility, or anything else the Quoter wants to price in. Whatever the fee, it is already baked into the quote the Quoter returns to HyFiHook. From the hook’s perspective, there is no separate fee field — there is just a price. HyFiHook itself has a protocol-fee mechanism, but it is turned off and will remain off for the foreseeable future to promote growth. We don’t know what the fee will be if it is ever turned on, but it will be tiny and enough to collectively cover the cost of all the oracle update gas costs.

​
Security model

The HyFi hook treats every Quoter as untrusted, read-only code. This is enforced at the call-site level:
  • Quoters are invoked via staticcall. The Quoter’s getQuote(...) entry point is a Solidity view function and the hook calls it from a view helper (_fetchQuote), which the Solidity compiler compiles to a STATICCALL — even on the state-changing swap path. A malicious or buggy Quoter therefore cannot write state, emit events, transfer tokens, or re-enter the hook or the PoolManager. Any attempt reverts the swap.
  • No code injection surface. A Quoter cannot upgrade the hook, change a pool’s default Quoter, drain inventory, or affect another pool’s pricing. Its only power is to return a price (or revert) for the current swap intent.
  • Bounded blast radius. If a Quoter returns a bad quote, the worst it can do is make its own pool quote badly.
  • Settlement is hook-owned. Token transfers and BeforeSwapDelta accounting happen inside HyFiHook after the Quoter has already returned. The Quoter never touches funds.
In short: deploying a new Quoter on HyFi is a pricing decision, not a trust decision. The hook’s surface area to Quoter logic is exactly one view call.

​
Is HyFi decentralised?

Sort of — but it is non-custodial and permissionless. HyFi’s pricing path is centralised by design: a shared off-chain oracle pushes prices on-chain every few seconds, and each Quoter is operated by a single market-maker. But:
  • Users are in full control over which market-maker they choose.
  • Users don’t need to trust HyFi with their tokens — the actual tokens are only ever held by UniV4’s PoolManager.
  • UniV4 guarantees that the user gets at least the minimum amount of output tokens they specify, or the tx reverts.
In other words: the pricing is centralised (by both the oracle and the market-maker), but the settlement is enforced by Uniswap v4 — the same set of audited contracts that already secure billions of dollars of on-chain volume. A misbehaving oracle or Quoter can at worst make a swap revert; it cannot drain a user. And in practice, users only care about the best prices. Aggregators route to whichever venue gives the user the most output tokens for the least input, period. HyFi’s job is to be that venue.