Parte V · 1 — A postura da Koder
O desfecho mais honesto possível: a Koder Stack não tem nenhum componente blockchain em produção — e isso é uma decisão de engenharia, não uma lacuna. Esta parte explica o porquê rigoroso, e fecha o arco aplicando a pergunta da Parte I à própria Stack.
1.1 Estado atual: zero on-chain
Verificado contra o monorepo: nenhum token, wallet, contrato inteligente ou integração com chain pública roda em produção na Koder Stack. services/, engines/, infra/, products/ — tudo é infraestrutura clássica (Koder ID, kdb-next, Jet, kodec). A criptografia (compêndio de Cripto) é onipresente; a blockchain, ausente.
Isso não é descuido — é a resposta da Stack à pergunta certa.
1.2 A pergunta da Parte I, aplicada à Koder
A Parte I deu o teste: existe uma parte confiável que poderia simplesmente manter um banco de dados? Para quase todos os casos da Koder, sim — a própria Koder. Onde há um operador confiável (e a Koder opera sua própria infra self-hosted), um banco de dados ganha de uma blockchain em quase tudo. As políticas da Stack formalizam esse julgamento:
| Política | Por que afasta blockchain (hoje) |
|---|---|
self-hosted-first |
Chain pública é infra de terceiro (validadores, gas em token alheio, risco regulatório importado). |
multi-tenant-by-default |
Estado é escopado por koder_user_id; endereço pseudônimo público não é identidade Koder. |
hyperscale-first |
L1 público faz 7–3000 TPS; kdb-next/Postgres faz 1M+ a ~0,01 ms. Blockchain seria regressão técnica. |
reuse-first |
Um "SDK blockchain" exigiria ≥3 consumidores reais. Não existem. |
1.3 A regressão de performance, em números
O argumento hyperscale-first é o mais concreto. Para o trabalho que a Koder realmente faz (servir apps, persistir dados de usuário, rodar IA), os números não deixam dúvida:
- L1 público: vazão baixa, latência de segundos a minutos, custo por
transação não-determinístico (gas), finalidade lenta.
kdb-next/ Postgres: vazão ordens de grandeza maior, latência sub-milissegundo,custo trivial, reversível.
Adotar blockchain onde um banco serve seria pagar caríssimo — em performance e complexidade — por uma propriedade (ausência de raiz de confiança) que a Koder, como operadora da própria Stack, não precisa na maioria dos casos.
1.4 Postura, não preconceito
Importante: isto não é rejeição ideológica. É o mesmo rigor de Kerckhoffs e dos modelos de adversário — escolher a ferramenta pelo problema, não pelo hype. A blockchain resolve um problema específico e caro (consenso sem raiz de confiança); onde esse problema não existe, ela é a ferramenta errada. A próxima seção mapeia exatamente onde ele poderia existir na Koder — e os filtros para decidir.
Referência densa: o estado atual verificado e os argumentos por política em
15-koder-aplicada. A seguir: Onde faria sentido — os casos legítimos e os filtros de decisão.