Listing and integration

BK$ for exchanges

Everything a listing, compliance or integration team needs, in one place: the asset model, the deposit and withdrawal flow, proof of reserves, the compliance posture, and the full document set.

Listing package Tokenomics

Read this first — five things that differ from a typical listing

BK$ is a UTXO-style ledger, like Bitcoin — not an account/nonce model like Ethereum. A balance is the sum of a wallet's active tokens.
Addresses are 64-character lowercase hex Ed25519 public keys. There is no HD/BIP-32 derivation.
There is no destination tag or memo system. Use a distinct address per user, or a pooled address with your own off-ledger attribution.
Finality is not confirmation-count based. A submission returns 202 accepted; you poll until it is committed. There is no reorg — once committed, a transaction does not revert.
Custody is yours. The protocol is non-custodial and never holds keys, so the exchange is the custodian of any BK$ it holds for its users.

Budget for this: the UTXO merge-then-pay flow needs more integration work than an account-model coin. Plan engineering time for the payment planner and the post-merge quorum wait, and validate end to end against a test node first.

Detecting deposits

Generate an Ed25519 keypair per user, client-side or inside your HSM. The public key is the deposit address; the private key never leaves your custody system.

GET /api/wallet/{public_key}: Current balance and the wallet's active tokens.
GET /api/wallet/{public_key}/activity: Receive and spend history, for reconciliation.
GET /api/tx/{id}: Transaction status. Credit a deposit only once this reports committed.

Real-time notification over websockets is available in addition to polling.

Processing withdrawals

A withdrawal is a client-signed transfer. Transfers consume whole tokens and mint new ones, conserving value, so you typically merge inputs and then pay.

Select tokens covering the amount from your hot wallet's active set.
Plan the merge and split.
Sign the canonical-JSON transaction with the address's Ed25519 key.
Submit to POST /api/tx/submit and expect 202 accepted.
Wait for peer quorum after a merge before spending the merged output — correct signing alone is not sufficient.
Poll until the transaction is committed, then mark the withdrawal complete.

The user-paid fee is burned, so size your change output accordingly. The validator commission is minted network-side and does not come out of your outputs.

Reconciliation and proof of reserves

Every node returns a byte-identical canonical snapshot of the ledger. Pull it from two nodes and compare the hash to confirm the federation agrees:

curl -s https://bitkurush.org/api/ledger/export | sha256sum
curl -s https://<another-node>/api/ledger/export | sha256sum

For an internal reserve figure, sum the active tokens of the addresses you control and cross-check it against the public supply endpoints. The open-source ledger verifier automates the signature re-verification and the cross-node comparison.

Recommended: run your own node. It removes any dependency on our infrastructure for your deposit detection, and the protocol specification is complete enough to implement one from scratch in any language.

Compliance posture

Custody: Non-custodial by construction. Keys are generated and stored in the user's browser under a password-derived key. The server cannot sign, recover or move funds, so there is no server-side custody surface.
KYC / AML: The protocol performs none — it is neutral infrastructure, and addresses are public keys, not identities. KYC and AML are performed by the regulated exchange at its deposit and withdrawal boundary, under its own obligations. This is the standard division of responsibility for a listed asset.
Transaction monitoring: Full deterministic history through the ledger export, plus address-level balance and activity lookups, with signed responses you can pin and re-verify.
Regulatory context: Crypto-asset services in Türkiye are subject to SPK and MASAK regulation. The published compliance document describes the technical posture; it is not legal advice, and the final assessment rests with qualified counsel and the listing exchange's compliance team.

Listing readiness — current status

Stated plainly, including what is not done yet:

Public tokenomics with a code-enforced supply cap and live supply feeds — published.
Public legal pages: terms, privacy and risk disclosure — published.
Explorer, network status page and signed node identity cards — published.
Integration, compliance and threat-model documents — published.
Independent third-party security audit — not yet completed. See the project page for what stands in its place today.
Operating legal entity details — see the project page for current status.

Document set

The reference documents below are the authoritative versions, served directly from this site. They are English-only; the Turkish summaries live on the pages linked beside them.

Exchange listing package: The single index of everything a listing team needs, with the operator checklist.
Tokenomics: Authoritative monetary policy, citing the source files that enforce each figure. Turkish summary: /tokenomics.
Exchange integration guide: Deposit and withdrawal operations, merge-then-pay, finality and reconciliation in full detail.
Compliance and regulatory posture: Custody model, KYC/AML division of responsibility, and operator responsibilities.
Threat model: What the design defends against, and what it explicitly accepts as risk.
Security policy: Vulnerability disclosure process and scope.
Wallet integration: Canonical JSON, signing rules and the quorum wait, for anyone building a client.

Also on this site: the node protocol specification, the architecture and security model, the explorer and the network status page.

Contact

For listing enquiries, due-diligence questions or integration support:

General and listing: to be published before the listing application
Security disclosure: security@bitkurush.org

Note: the operating entity's registered details are being finalised and will be published on the project page before the listing application. Contact us in the meantime through the security address above.