BitKuruş
Cüzdan

Reference document

BitKuruş — Compliance & Regulatory Posture

This is the authoritative version, rendered from the project's own source document rather than retyped — so it cannot drift from what the team maintains.

All documents Summary page

Note: Reference documents are maintained in English. A Turkish summary of this material is on the summary page.

This document describes the project's technical and operational posture for exchange and legal due-diligence. It is not legal advice. Türkiye'de kripto varlık hizmetleri SPK ve MASAK düzenlemelerine tabidir; nihai değerlendirme yetkili hukuk müşavirliği ve ilgili borsanın uyum ekibi tarafından yapılır.

1. Custody model — non-custodial by construction

BitKuruş wallets are pure client-side. Ed25519 keypairs are generated and stored in the user's browser, encrypted under a password-derived key. The server:

  • never holds, escrows, or can recover a user's private key;
  • cannot sign or move funds on a user's behalf;
  • has no server-side custody surface to seize or compromise.

Implication for a listing exchange: the exchange is the custodian of any BK$ it holds on behalf of its users (via addresses it controls). BitKuruş the protocol does not custody user funds and does not act as a Crypto-Asset Service Provider on the exchange's behalf.

2. KYC / AML

  • The protocol performs no KYC/AML — it is neutral infrastructure, like any base ledger. Addresses are Ed25519 public keys, not identities.
  • KYC/AML is performed by the regulated exchange at its deposit/withdrawal boundary, under its own MASAK obligations and licensing. This is the standard division of responsibility for a listed asset.
  • BitKuruş provides the technical means to support exchange compliance:
    • Full, deterministic, publicly auditable transaction history (GET /api/ledger/export, GET /api/wallet/{pubkey}/activity).
    • Address-level activity and balance lookups for transaction monitoring.
    • Deterministic, signed responses that can be pinned and re-verified.

3. Transparency & auditability

  • Fixed, code-enforced supply cap (21,000,000 BK$) — see TOKENOMICS.md.
  • Open-source ledger verifier so any third party (regulator, exchange, auditor) can independently confirm node state.
  • Signed node identity cards (GET /api/network) that expose peers, validator keys, commission wallet, and supply cap.

4. Legal entity & disclosures (operator responsibility)

Where these live in the codebase: the entity's registered details are supplied through the entity block in config/bitkurus.php (env keys documented in .env.example). /terms, /privacy, /project and /for-exchanges render from that one block, so filling it publishes the details everywhere at once. Until the name, address and contact address are all set, those pages publish an explicit "to be published before the listing application" notice rather than a placeholder.

For a Turkish exchange listing, the following are required from the project operator:

  • A legal entity (company/foundation) standing behind BitKuruş, with a named responsible team and a contactable address.
  • Terms of Service, Privacy Policy (KVKK-compliant), and a Risk Disclosure — published pages exist at /terms, /privacy, /risk.
  • A clear statement of jurisdiction and governing law.
  • Any token-allocation disclosure (team/treasury/reserve), applied through the capped issuance path described in TOKENOMICS.md.

5. What the protocol explicitly is NOT

  • Not an investment product, security, or promise of return.
  • Not a payment institution or e-money issuer.
  • Not a custodian of user funds.

These positions must be mirrored in the public Risk Disclosure and Terms.