Who runs BitKuruş

Operating entity

Contact

to be published before the listing application

Security disclosure

security@bitkurush.org

The validator federation, as it actually stands

BitKuruş runs 4 validator nodes. Every node keeps independent storage, signs its own API responses, and converges with its peers through signed replication envelopes. Any node can veto a transaction it considers invalid.

Stated plainly: those nodes are not yet independently operated. They currently run across two physical hosts under one operator, which means the federation's fault tolerance today is operational, not adversarial. Distributing validators across independent providers — and eventually independent operators — is the single most important item on the roadmap below, and a listing team should weigh it accordingly.

What this does and does not change: the ledger remains publicly auditable, every node's state hash is comparable by anyone at any time, and no node can alter history without the divergence becoming visible. What it does not yet provide is protection against a single operator acting maliciously across every node at once. The threat model says so in writing.

GET /api/network

Each node's signed identity card: node id, public key, configured peers, validator keys, commission wallet and supply cap. Pin it and any silent change becomes detectable.

GET /api/state

The live state hash. Two honest nodes always return the same value.

Governance

Who can add or remove a validator?

The operator, through the peer registry in each node's configuration. A new node is admitted only after every existing node has its public key in that registry, so admission requires touching every node — it cannot be done from the outside.

Who controls issuance?

Production allows exactly one issuance source, the public distribution mechanism. The deployment preflight refuses to release a node that leaves any development issuance source enabled. Every issuance, from any source, is bounded by the supply cap.

Who holds the node signing keys?

Each node holds its own Ed25519 signing seed in its own environment; the keys are never shared between nodes and never leave their host. A node that changes its key is flagged by the scheduled cross-check on its peers.

What happens if the operator disappears?

The ledger survives as published data: the canonical export is byte-identical across nodes and can be downloaded and independently re-verified by anyone at any time. The protocol specification is public and complete enough for a third party to run a compatible node. What would be lost is coordinated operation, not the record.

How are protocol changes made?

Changes to the wire format or validation rules are documented in the node protocol specification before deployment, because every peer must agree on canonical serialisation for replication to work at all. A unilateral change would cause visible state divergence rather than a silent rewrite.

Source availability

What is published, and what is not:

• The federation protocol specification is public and complete — wire formats, canonical JSON rules, validation rules, replication envelopes and the onboarding handshake. Anyone can implement a compatible node in any language.
• The offline wallet and the independent ledger verifier are open source under the MIT licence.
• The source code of the node reference implementation is not published.

The reason is operational security rather than secrecy about behaviour: in a permissioned federation with a small validator set, the node implementation is closer to production infrastructure than to a public client. Everything a third party needs in order to verify the ledger, re-implement a node, or audit what the network actually did is public — the state hash, the signed identity cards, the byte-identical ledger export, and the specification itself.

The practical test: you do not need our source code to check our claims. Download the ledger from two nodes, re-verify every signature with the open-source verifier, and compare the hashes.

Security and audit status

Independent audit: BitKuruş has not yet undergone an independent third-party security audit. Saying so is more useful than staying quiet about it, and the report will be published here when one is completed.

What stands in its place today, all of it inspectable:

• A written threat model that separates what the design defends against from what it accepts as risk.
• A continuous integration pipeline running static analysis, the automated test suite, and an integration run against a four-node test network on every change.
• An open-source ledger verifier that anyone can run against any node, independently of us.
• Continuous integrity monitoring: after every committed write, peers' state hashes are compared and mismatches open operator alerts.
• A published vulnerability disclosure policy.

Roadmap

In priority order, and limited to commitments that can be checked from the outside once they are done:

1. Move validator nodes onto distinct providers and networks, then onto independent operators. Verifiable from the signed identity cards and public DNS.
2. Complete an independent third-party security audit and publish the report on this page.
3. Establish and publish the operating legal entity, and finalise the terms and privacy texts with qualified counsel.
4. Give every validator its own commission wallet, so rewards and node identity are not collapsed onto one address.
5. Extend the supply-cap check from per-node enforcement to a federation-wide one, closing the theoretical divergence described in the tokenomics.
6. Mutual TLS between peers, so replication is authenticated at the transport layer as well as in the envelope.

Last reviewed: 2026-08-25