> ## Documentation Index
> Fetch the complete documentation index at: https://docs.hedgin.xyz/llms.txt
> Use this file to discover all available pages before exploring further.

# How the Hedgin protocol works

> Who holds the money, who can move it, and which rules a Solana program enforces for every Hedgin vault.

Hedgin runs investment vaults on Solana. A **vault** is a shared pot of one token, such as USDC. Depositors put tokens into the pot. A manager invests the pot through three trading venues. Every action follows rules written into a Solana program, so nobody, including the manager and Hedgin, can take the money out by another route.

This page explains who does what and why the design looks the way it does.

## The program holds the money, not the manager

A **Solana program** is code stored on the Solana blockchain. Hedgin's program is called Hedge Vault. Its program ID is `r2ahBQ6gbPCJ9FxBymYcXuwXi8NmenRry7SE7QR7FAt`.

Each vault's tokens sit in token accounts controlled by a **program-derived address (PDA)**. A PDA is an address that only the program can sign for. No person has a private key for it. The manager signs instructions that ask the program to act, and the program decides whether the request is allowed.

Because of this design, a manager can trade a vault's tokens but cannot send them to a personal wallet. The program only moves vault tokens to three places:

* [Jupiter](/managers/jupiter-swaps), a swap router that exchanges one token for another.
* [Meteora DLMM](/managers/meteora-dlmm), a pool where the vault provides liquidity and earns trading fees.
* [Phoenix Perpetuals](/managers/phoenix-perps), a market for leveraged long and short positions.

Tokens go back to a depositor only when a request is cancelled, refunded, or settled. The program pays them to the depositor's own wallet.

## Who does what

Each role below is a Solana public key that the program checks before it acts.

| Role | What it can do |
| - | - |
| Depositor | Creates and cancels its own deposit and withdrawal requests. |
| Manager | Owns one or more vaults. Changes vault settings, trades through Jupiter, Meteora DLMM, and Phoenix, claims manager fees, and closes empty strategies and vaults. |
| NAV keeper | A Hedgin service that values each vault every 4 hours and posts the result on chain. It cannot move vault tokens. |
| Resolver | Anyone. A resolver submits the transaction that settles a ready request. It cannot change the outcome. |
| Hedgin administrator | Adds managers to the whitelist, sets protocol-wide limits, can pause the protocol or a single vault, and can refund a pending request. |

The manager role is permanent for a vault. The program has no instruction that moves a vault to a new manager key, so the wallet that creates a vault controls it for its whole life.

## The chain is the source of truth

The program stores every number that matters: token balances, share supply, posted value, fees, open requests, and status. The website, the manager bot API, and the keeper all read this state. None of them can override it.

This has three practical results:

* A number on the website can be a few seconds old, or partly priced when a price feed is missing. The value the program stores is the one used for accounting.
* The website checks your action before you sign, so you see most errors early. The program checks the same rules again when the transaction runs. A check passing on the website does not guarantee the transaction succeeds.
* A Hedgin API key lets a bot ask the server to build transactions. It cannot sign them. The manager's wallet key still signs every action.

## Deposits and withdrawals wait for a valuation

A vault's tokens are spread across idle cash, swapped tokens, liquidity positions, and perpetual positions. Their total value changes every second. To price a deposit or a withdrawal fairly, Hedgin needs one agreed value for a moment in time.

So deposits and withdrawals are **requests**. A request waits until the keeper posts a new value for the vault. That value is the **net asset value (NAV)**: the total value of the vault, and from it the value of one vault share. The keeper posts NAV at most once per **epoch**, a fixed 4-hour window. When the new NAV lands, waiting requests settle at that price.

This delay is the main trade-off in the design. Depositors wait up to a few hours. In return, nobody can deposit or withdraw at a stale price while the manager's positions move. [Vaults and NAV](/concepts/vaults-and-nav) explains the timing in detail.

## Three surfaces for three audiences

* The [web app](https://hedgin.xyz/vaults) covers every user action: browsing vaults, deposits, withdrawals, and the full manager console.
* The [manager bot API](/api-reference/introduction) lets a manager's bot automate most manager actions. It does not cover deposits, withdrawals, or request settlement.
* The [published IDL](https://hedgin.xyz/idl/hedge_vault.json) describes every program instruction for teams that build their own Solana client. The IDL is a program interface, not a list of HTTP endpoints.

All three surfaces end in the same place: a transaction that the program checks. [How transactions work](/concepts/transactions) describes that path.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.