> For the complete documentation index, see [llms.txt](https://hinkal-team.gitbook.io/hinkal/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://hinkal-team.gitbook.io/hinkal/api/hinkal-api/overview.md). # Overview The API is Hinkal's privacy protocol exposed as a REST API. It is a normal HTTP API with one defining property: **the server runs inside a secure enclave**. Every request is handled by code executing inside a GCP Confidential VM (AMD SEV), whose memory is encrypted at the hardware level and inaccessible to the host — including Google and Hinkal's own infrastructure. Think of it as "an API, but the compute is the enclave." ## Supported chains The API supports three chain families: | Chain | Chain ID | Notes | | -------------- | ----------------------------------------------- | ------------------------------------------------------------------------------------------------- | | EVM chains | Standard IDs (e.g. 1 = Ethereum, 10 = Optimism) | Full feature set | | Solana mainnet | 501 | Per-operation signing differences; see [Authentication](/hinkal/api/hinkal-api/authentication.md) | | Tron | 728126428 | TIP-712 typed-data signing (EIP-712 compatible) | ## What it does Hinkal lets users hold a **shielded balance** — funds whose ownership and movement are not visible on the public ledger. Working with that shielded balance requires: * decrypting the user's UTXOs (unspent shielded outputs), * generating zero-knowledge proofs that authorize spends without revealing them, * building the resulting on-chain transactions. The API performs all of this **inside the enclave** and hands back either an unsigned transaction for the caller to broadcast, or a relayed transaction hash. ## What never leaves the enclave Each shielded balance is controlled by a **Hinkal shielded key**. This key decrypts the user's UTXOs and authorizes their zero-knowledge proofs. It is: * generated inside the enclave, * stored encrypted outside the enclave — encrypted with a key held in **Google Cloud KMS**, which the enclave alone is authorized to use, * decrypted and used **only inside the enclave**. When a request needs to read the user's shielded balance or build a proof, the enclave decrypts the shielded key in memory, uses it for that single operation, and discards it — all within the enclave boundary. The decrypted key is never persisted and never returned in a response. No component outside the enclave — not the API host, not the database, not Hinkal engineers — ever sees a raw shielded key. ## You keep your own wallet The API is **not** a custodial wallet. The caller keeps their own wallet (EVM, Solana, or Tron) and uses it to authenticate every request. The enclave custodies only the Hinkal shielded key that operates the privacy layer — never the caller's key. ## Request model * **Base URL**: `https://api.hinkal.io` * **Response envelope**: `{ "success": true, ... }` on success, `{ "success": false, "error": "..." }` on failure. * **Authentication**: every request is signed by the caller's wallet. Read-only endpoints use a lightweight session signature; transaction endpoints accept either a write session signature or a per-operation typed-data signature that commits to the exact operation parameters. Signing method varies by chain — see [Authentication](/hinkal/api/hinkal-api/authentication.md). ## Endpoint groups | Group | Endpoints | | ------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Health | `GET /ping` | | Attestation | `GET /attestation` | | Sessions | `POST /create-session` | | Supported | `GET /supported-tokens`, `GET /supported-chains` | | Reads | `GET /balance`, `GET /stuck-utxo-balance`, `GET /recipient-info`, `GET /get-fee-structure`, `GET /get-swap-data` | | Cache | `POST /refresh-cache` | | Transactions (EVM/Tron/Solana) | `POST /deposit`, `POST /proofless-deposit`, `POST /deposit-for-other`, `POST /deposit-solana-for-other`, `POST /withdraw`, `POST /transfer`, `POST /swap`, `POST /withdraw-stuck-utxos` | | Private Send | `POST /private-send`, `GET /private-send/{orderId}` | See the [Examples](/hinkal/api/hinkal-api/examples.md) for end-to-end code, [Private Send](/hinkal/api/hinkal-api/private-send.md) for the asynchronous private-send flow, and [Attestation](/hinkal/api/hinkal-api/attestation.md) for verifying that the server is running the published code inside a genuine TEE. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://hinkal-team.gitbook.io/hinkal/api/hinkal-api/overview.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.