Skip to main content
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, a swap router that exchanges one token for another.
  • Meteora DLMM, a pool where the vault provides liquidity and earns trading fees.
  • Phoenix Perpetuals, 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. 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 explains the timing in detail.

​
Three surfaces for three audiences

  • The web app covers every user action: browsing vaults, deposits, withdrawals, and the full manager console.
  • The manager bot API lets a manager’s bot automate most manager actions. It does not cover deposits, withdrawals, or request settlement.
  • The published IDL 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 describes that path.