Getting Started
Last updated
Hinkal's privacy protocol is exposed through the API — a REST API whose server runs inside a secure enclave (a GCP Confidential VM, AMD SEV). Private key material never leaves it.
The API is the foundation. On top of it, Hinkal offers a higher-level product — Wallet-as-a-Service (WaaS) — for a different integration style. Both run on the same enclave and the same host, https://api.hinkal.io.
The core API. The caller keeps their own wallet (EVM, Solana, or Tron) and signs each request with it — a session signature authorizes all requests for 24 hours by default, or a per-transaction EIP-712 typed-data (EVM/Tron) / ed25519 (Solana) signature authorizes individual operations. The enclave custodies only the Hinkal shielded key that operates the privacy layer.
A managed-wallet layer. Hinkal generates and custodies EVM, Solana, and Tron wallets for your users inside the enclave, organized under an organization / user / policy model. Requests are authenticated with an Ed25519 X-Stamp signature.
Who holds the wallet
The caller
Hinkal (managed)
Authentication
EVM, Tron, or Solana wallet signature
Ed25519 X-Stamp
Org / user / policy model
No
Yes
Typical integrator
Dapp / wallet
Team wanting managed wallets
API Overview — how the enclave model works
API Authentication — signing requests
API Examples — runnable code
WaaS Security & Architecture — enclave security model
Last updated