Part V · 1 — Koder's posture

draft

The most honest conclusion possible: the Koder Stack has no blockchain component in production — and that is an engineering decision, not a gap. This part explains the rigorous why, and closes the arc by applying the question from Part I to the Stack itself.

1.1 Current state: zero on-chain

Verified against the monorepo: no token, wallet, smart contract or integration with a public chain runs in production on the Koder Stack. services/, engines/, infra/, products/ — it is all classic infrastructure (Koder ID, kdb-next, Jet, kodec). Cryptography (Cryptography compendium) is ubiquitous; blockchain is absent.

This is not an oversight — it is the Stack's answer to the right question.

1.2 The Part I question, applied to Koder

Part I gave the test: *is there a trusted party that could simply keep a database?* For almost every Koder case, yes — Koder itself. Where there is a trusted operator (and Koder operates its own self-hosted infra), a database beats a blockchain at nearly everything. The Stack's policies formalize this judgment:

Policy	Why it rules out blockchain (today)
`self-hosted-first`	A public chain is third-party infra (validators, gas in someone else's token, imported regulatory risk).
`multi-tenant-by-default`	State is scoped by `koder_user_id`; a public pseudonymous address is not a Koder identity.
`hyperscale-first`	A public L1 does 7–3000 TPS; kdb-next/Postgres does 1M+ at ~0.01 ms. Blockchain would be a technical regression.
`reuse-first`	A "blockchain SDK" would require ≥3 real consumers. There are none.

The Part I test applied to Koder: almost everything falls into "use a database"

1.3 The performance regression, in numbers

The hyperscale-first argument is the most concrete. For the work Koder actually does (serving apps, persisting user data, running AI), the numbers leave no doubt:

Throughput/latency: public L1 vs. kdb-next/Postgres

Public L1: low throughput, latency of seconds to minutes, non-deterministic
cost per transaction (gas), slow finality.
kdb-next / Postgres: throughput orders of magnitude higher, sub-millisecond
latency, trivial cost, reversible.

Adopting blockchain where a database suffices would be paying dearly — in performance and complexity — for a property (the absence of a root of trust) that Koder, as the operator of its own Stack, does not need in most cases.

1.4 Posture, not prejudice

Importantly: this is not an ideological rejection. It is the same rigor as Kerckhoffs and the adversary models — choosing the tool by the problem, not by the hype. Blockchain solves one specific, expensive problem (consensus without a root of trust); where that problem does not exist, it is the wrong tool. The next section maps exactly where it could exist at Koder — and the filters for deciding.

Dense reference: the verified current state and the per-policy arguments in 15-koder-applied. Next: Where it would make sense — the legitimate cases and the decision filters.