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

> ## Agent Instructions
> HEVN accounts are non-custodial in both products. Self-serve (the General tab): the person who owns the email holds the only key and signs for themselves. Whitelabel (the Whitelabel and REST API tabs): the integrator's customer creates and owns their account through Sign in with HEVN, a HEVN-hosted popup on the integrator's site; the integrator's backend holds a developer key, operates linked accounts and books their payouts, and the account holder approves every payout in that popup. The developer key signs only for the integrator's own wallet; it never signs a client's money.
> Use HEVN's terms exactly. A rail is a bank route a client can request. A virtual account (bnk_) is an opened rail. Account details are what a payer needs in order to wire money, and arrive in a field named requisites. A client is a customer's own account linked to the integrator through Sign in with HEVN (POST /dapi/v1/connect/sessions, then POST /dapi/v1/clients/link); there is no API call that creates one. The business behind it is the integrator's customer. A contact is a saved destination; a beneficiary is the party at the far end of a fiat payout. Every departure of money is a payout, to a bank account or to a wallet alike.
> Never name a banking partner. Say 'a licensed banking partner'.
> There are no published fee rates, spreads or minimums. Prices come from a quote on a specific payment; direct pricing questions to HEVN rather than inventing numbers.
> The whitelabel API is at /dapi/v1 and takes a developer-key session plus an X-Hevn-Account header. Developer keys have an IP allowlist and no scopes. Remote transfers are at /api/v1/remote_spend_limit and take a remote transfer key (rsl_) in X-Api-Key, bounded by an onchain spend permission the account holder grants. They are different credentials and neither works on the other surface. The HEVN CLI is discontinued.

# What is HEVN

> HEVN is a non-custodial financial platform: your money lives in a smart wallet only you own, while HEVN provides the payment tooling around it.

HEVN is a financial platform for global payments built on USDC. It gives individuals and businesses the tools a finance team expects — invoices, contacts, contracts, payouts to bank accounts, cards, and statements — without ever taking custody of their money.

Every HEVN account is a [Base Smart Wallet](https://docs.base.org/base-account/overview/what-is-base-account) on the Base network, owned exclusively by a key that only the user controls. HEVN the platform stores metadata (contacts, invoices, virtual account details) and orchestrates workflows, but it **cannot move, freeze, or access user funds**.

## Two ways to use HEVN, two people holding the key

Everything on this tab describes the **self-serve** product: the person who owns the email owns the
wallet, and nothing moves without a signature from their own key. HEVN cannot sign for them.

The [whitelabel](https://hevninc.mintlify.site/whitelabel/overview.md) product keeps that rule and adds an operator. Your customer
creates their own HEVN account in a sign-in window on your site and links it to your product; your
backend, holding a developer key, verifies the account, opens its rails and books its payments; and
your customer still approves every payment with their own key in that window.

Read this tab for how the platform is built and what it cannot do with the money. Read the
[Whitelabel](https://hevninc.mintlify.site/whitelabel/overview.md) tab if you are building the product around it.

> [card] [Architecture](https://hevninc.mintlify.site/general/architecture.md)
>
> How email, Privy, and Base smart wallets fit together.

> [card] [Key management with Privy](https://hevninc.mintlify.site/general/privy-wallets.md)
>
> Self-custodial keys secured by Shamir sharding and TEEs.

> [card] [Base smart wallets](https://hevninc.mintlify.site/general/smart-wallets.md)
>
> Gasless USDC, deterministic addresses, and onchain ownership.

> [card] [Security model](https://hevninc.mintlify.site/general/security-model.md)
>
> What HEVN can and cannot do with your money.

> [card] [Whitelabel](https://hevninc.mintlify.site/whitelabel/overview.md)
>
> Run HEVN under your own brand: link your customers' accounts through a sign-in window and operate them from code.

## Core principles

### Non-custodial by construction

HEVN is not a wallet provider holding funds on your behalf. Your balance is USDC sitting in a smart contract wallet on Base. The only key that can authorize spending from that wallet is your [Privy embedded wallet](https://docs.privy.io/wallets/overview/embedded) — a key that is cryptographically sharded and never visible to HEVN or to Privy itself.

There is no HEVN omnibus account, no pooled balance, and no internal ledger that "represents" your money. The onchain balance **is** the balance.

### Deterministic identity

Your entire account chain is derived deterministically:

```mermaid theme={null}
flowchart LR
    A["Email"] --> B["Privy embedded wallet"]
    B -->|"initial owner"| C["Base Smart Wallet<br/>(your HEVN account)"]
```

Because each step is deterministic, HEVN can compute the wallet address for any email address **before** the recipient ever signs up. This is what makes sending money by email safe: funds go directly to a smart wallet that only the owner of that email will ever be able to control. There is no escrow step and no custodial holding period.

### HEVN is never in the money flow

* **Deposits** (bank transfers, card top-ups, crypto) settle directly to your smart wallet address.
* **Payouts** to bank accounts are executed by a licensed banking partner: the partner issues a one-time deposit address, and *you* send the funds from your wallet. HEVN never receives, forwards, or holds the money.
* **Cross-chain deposits and withdrawals** use the [NEAR Intents 1Click API](https://docs.near-intents.org/integration/distribution-channels/1click-api/about-1click-api) with one-time passive deposit addresses that HEVN does not control.

## What the platform layer does

The HEVN API (and the JWT it issues) covers everything that is *not* money movement:

* Contact book, invoicing, and contract management
* Virtual account details (IBANs / account numbers) requested from partner banks and surfaced to you
* KYC/KYB, statements, analytics
* Team and multi-user access administration

Authorization to actually **spend** funds always happens at the wallet layer, with a signature from your key. See [Authentication](https://hevninc.mintlify.site/general/authentication.md) for the split between platform auth and money auth.

## Interfaces

| Surface | What it is | Docs |
| - | - | - |
| Web app | Full product UI at [app.gethevn.com](https://app.gethevn.com) | — |
| REST API | The whitelabel integration surface: link and operate your customers' accounts | [REST API tab](https://hevninc.mintlify.site/api-reference/overview.md) |
| Whitelabel | HEVN as the payments engine behind your product, under your brand | [Whitelabel tab](https://hevninc.mintlify.site/whitelabel/overview.md) |
| Remote transfers | A capped key that lets your own server or script send USDC from your account. Advanced use only | [Remote Transfers tab](https://hevninc.mintlify.site/remote-transfers/overview.md) |


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