Hinkal can now be integrated directly into Go applications

Developers can add Hinkal to a backend service with a single go get command. The SDK is written in Go, so there is no Node.js runtime and no WebAssembly in your process. It requires Go 1.25 or later and runs on Linux and macOS, on both amd64 and arm64. It is built for backend services, payment infrastructure and settlement systems.
‍

What changed

Backend teams have already been able to use Hinkal through the Hinkal TypeScript SDK.

That SDK covers Node.js, browser, React and Next.js applications. It remains supported and is still the right choice for teams building in those environments. A Go service, however, previously had to run a Node.js environment that the rest of the service did not need, and communicate with it across a process boundary. The Go SDK removes that requirement.

Developers now call Hinkal directly through ordinary Go functions. The library handles the privacy proofs, private balance records and transaction processing behind the scenes. Proof generation and balance decryption run in Hinkal's secure enclave rather than inside your process, so the SDK needs outbound HTTPS access to Hinkal's services alongside your blockchain RPC endpoints.

Your signing key stays in your infrastructure

A backend service has no user wallet to connect to, so the SDK is given a signing key by your application - normally from wherever your service already keeps its operational keys. Separate signers are available for EVM networks, Solana and Tron.

Hinkal does not hold your funds. Your blockchain signing key never leaves your infrastructure: the SDK signs locally and the private balance is controlled by that key. Shielded key material is encrypted to the enclave's public key before proof generation and balance decryption, and every enclave response is signature-verified by the SDK before it is used.
‍

What developers can build

Once the SDK is initialised, developers can add the following to a Go service.
‍

Private deposits

A service can move tokens from a public address into a private Hinkal balance. Several tokens can be included in one request. The SDK can also return an unsigned transaction instead of sending it, so a service that already has its own signing and broadcasting process can use that instead.
‍

Private transfers

A service can send funds from a private balance to another Hinkal user.

The sender, recipient and amount are not published on the blockchain. The recipient provides a Hinkal private address, which the service can verify before submitting the transfer.

Withdrawals

A service can withdraw funds from a private balance to any public wallet address.

The withdrawal can be processed through a Hinkal relayer, so the service does not need to send another public blockchain transaction, or the service can broadcast it directly. The relayer fee can be quoted before the withdrawal is submitted.

Payments to multiple public addresses

The SDK supports payments that start and finish with public wallet addresses.

A service can send one token from one public address to several public addresses through a single request, with the recipients, the amounts and a completion time. Each request covers a single token; paying in two tokens means two requests. The request returns an identifier the service can check for the status of each payment until it completes.

The recipients do not need a Hinkal account or a private address, and they do not need to change how they receive funds. This is the option to use for payout products, settlement runs and payroll tools that pay wallet addresses their users already have.

Private swaps

A service can exchange one token for another without leaving the private balance. Pricing is provided through aggregated decentralised exchange liquidity and can be quoted before the swap is submitted.

Private cross-chain transfers

A service can move private funds from one Hinkal-supported network to another. The transfer remains private on both the source and destination networks. Additional networks are reachable as bridge destinations, but funds arrive as a normal public balance there, since Hinkal is not deployed on them.

Deposits for another user

A service can deposit funds directly into another Hinkal user's private balance.

Balance reads

A single balance read covers one network and returns a balance for every token held on it.

A service can use cached balance information for routine reads and request a fresh scan after an operation that moves funds. There are no live updates to subscribe to, so a service checks the balance after a transaction confirms.

Recovering funds from incomplete transactions

Funds left behind by an incomplete transaction can be listed and withdrawn to a public address through the SDK, without contacting support.

Built for services that stay running

Hinkal keeps a record of private balances that has to be synchronised before the SDK can be used. In a browser that happens once per session. In a service that restarts on every deployment, it would happen on every restart.

The SDK can therefore store its synchronisation data in a file. A restarted service loads that file instead of scanning everything again.

Fees are made up of a fixed amount plus a percentage of the transaction, and both can be quoted before submitting. A payout service can calculate what a recipient will receive before it commits to the payment rather than reconciling afterwards.

Compliance

The compliance controls are the same across Hinkal's products.

Deposits are screened at the protocol level before funds enter the private balance. The screening is enforced by Hinkal's infrastructure rather than by the SDK, and using the Go SDK in a backend service does not change these requirements.

Package: github.com/Hinkal-Protocol/hinkal-go

Browser applications are not supported and are not intended to be. The Hinkal TypeScript SDK covers those.
‍

Supported networks

The SDK supports Hinkal's EVM networks along with Solana and Tron, each with its own signer.

The SDK can report which networks your configured providers support - the list depends on which signers and provider adapters you have wired up, so a service with only an EVM signer will not see Solana or Tron - and that is the list to build against.
‍

Why Go support matters

A payment platform that settles in stablecoins publishes its business as a condition of operating. Every payout names the recipient and the amount, and every settlement run is a timestamped list that a competitor can read.

Privacy cannot be limited to a wallet the user chooses to open. It has to be available inside the service that moves the money, in the same language that service is already written in.
‍
The Go SDK makes private balances and payments a normal Go dependency for the backends that settle stablecoin payments every day.
‍

Quickstart, guides and full API reference‍

Document: https://hinkal-team.gitbook.io/hinkal/hinkal-sdk/go-sdk?utm_source=hinkal-blog&utm_medium=referral&utm_campaign=go-sdk
Source: https://github.com/Hinkal-Protocol/hinkal-go

‍

‍