Skip to main content

Integration Overview

KuraPrivacy provides a service that handles complex operations — ZK proof generation, blockchain synchronization, and encrypted transaction state management — through an API. It is designed for enterprises that want to introduce privacy and confidentiality for stablecoin or crypto-asset transactions and balances.

This page describes what is needed to integrate KuraPrivacy into an application or service, and what becomes possible after integration. Detailed SDK usage and sample code are provided separately when you start adopting the product — please reach out.

What integration enables​

By integrating KuraPrivacy through the Service API or SDK, an application gains the ability to:

  • Issue receiving addresses (Kura addresses) per user
  • Display private balances
  • Deposit from regular token balances into private balances
  • Transfer from private balances to other addresses
  • Withdraw from private balances to regular wallet addresses
  • Display deposit / withdrawal / transfer history
  • Track transfer status (in progress, completed, failed)
  • Support multiple approval methods including passkey, EOA, and multisig

Integrating KuraPrivacy can be thought of as adding privacy features as an add-on to an existing wallet experience. The partner application handles UX, authentication, signing, and display, while complex work — proof generation and blockchain synchronization — is handled by the KuraPrivacy service layer.

User signing keys always remain on the partner application or the user's device and are never passed to KuraPrivacy. Users sign transfer payloads with their existing wallets (passkey, EOA, multisig, etc.), and only the signature data is sent to KuraPrivacy. As a result, existing key management and trust models do not need to change to adopt KuraPrivacy.

Transfer flow​

A single private transfer follows these straightforward steps:

  1. The user enters destination and amount on the transfer screen.
  2. The partner application requests transfer preparation and receives the payload to be signed (POST /api/wallets/{wallet_handle}/transfer-preparations).
  3. The user reviews the transfer and signs with their existing wallet key.
  4. The partner application submits the signed payload to the API (POST /api/wallets/{wallet_handle}/transfers/execution-requests); the KuraPrivacy service layer asynchronously generates the proof and broadcasts the transaction.
  5. The partner application polls execution status until completion and presents the result to the user (GET /api/execution-requests/{execution_request_id}).

Because the service layer handles all of the complex work — blockchain integration, proof generation, and so on — the partner application only needs to implement the simple flow of "request, then poll for status."

Component composition​

KuraPrivacy architecture

Applications built on KuraPrivacy combine several components. Partner applications generally use the Service API and SDK, allowing them to proceed without having to be aware of the details of the components below.

Partner application​

The application that owns UX, authentication, signing, and balance/history display. It uses the Kura Service API to access private transfer functionality and can integrate with existing wallet setups such as passkeys, EOAs, and multisig. Signing keys remain entirely on the partner application or the user's device and never reach KuraPrivacy.

Kura Contract​

The smart contract that runs on-chain. It records and verifies deposits, transfers, and withdrawals, and guarantees that the same balance is never spent twice. Partner applications do not interact with the contract directly.

Kura Service API​

The primary API that partner applications connect to. It exposes account registration, balance lookup, transfer preparation and execution, and history retrieval over HTTP.

ZK Prover​

The component that mathematically proves a transfer follows the rules. The KuraPrivacy service layer runs this asynchronously, so partner applications never need to implement it.

Indexer / Sync Worker​

The component that reads transaction history from the blockchain and reflects each account's balance and history into the database. Partner applications can display up-to-date balances and history because this component continuously stays in sync.

Broadcaster / Execution Worker​

The component that broadcasts proven transfers on-chain and tracks completion. After submission, partner applications only need to check status via the request ID.