Jack

Self-hosted sovereign deterministic governed AI-OS with decentralized ledger-anchored settlement and deterministically enforced execution.

[Jack @JackKHash]

The hard part was the hardware, the network, the firewalls, the separation, and getting the full network and all the VMs tuned. Once every VM uses the same log server, every setting and every change is documented in local Gitea, and you have an AI to analyze and discuss all of that with, it becomes pleasant, and you make faster progress.

[Jack @JackKHash]

Building, learning, deciding, and testing took months, maybe a year, and I am still not where I want to be. Once it is running, it is not maintenance-heavy. An issue gets reported and needs a decision. Most are easy and take no real time. Now and then something has to be built with AI, and that goes through a security audit before production. Most of the work now is extending it toward what I envisioned.

[Jack @JackKHash]

Can't make it short. This is a large topic for me, and a lot of pieces have to sit together so it is secure.

On a network that is not VLAN separated, without TPM to identify each VM, and without each service on its own VM, I do not know how to do it securely. I would argue it is impossible.

How I do it, as compact as I can:

Security sits on the VM. About 90 services, each on its own VM. Vault, Keycloak, Postgres, Loki. Gitea and the vLLM runtime are some of them.

The split is the VLAN. Every zone is its own network: core, hypervisor, trust, governance, edge and DMZ, backup, monitoring, egress, infrastructure, business, AI runtime, sandbox.

The rules between them are fixed and deterministic. AI runs on its own VMs and has no network access to the VLANs that enforce those rules, so it cannot change them.

It cannot copy itself or start a new agent on another server. That needs a new identity. The TPM key stays in the chip, so it cannot move. A new identity is approved only by a human in Keycloak, and only with a YubiKey. Vault and the CA sit outside its VLAN, so it cannot enroll one itself.

A human can only work from a machine where that YubiKey identifies them. No key, no access, so an AI cannot act as a person.

A lot of the system was built by AI, then heavily tested. What remains is deterministic, and that is what governs the probabilistic AI. A tool is admitted only after it is tested. That gate is code.

Gitea runs locally. Code, infrastructure, and agent changes go through it.

Monitoring logs what happens, with Loki, Prometheus, Grafana, and Wazuh, so it can be analyzed afterward.

The Anthropic agent sits on a devbox VM, and it is governed and limited deterministically.

Risky work, and any autonomous run that lasts for days, stays in the sandbox VLAN. It cannot reach the local network. Internet is a DMZ path, opened from outside by fixed rules.

[Jack @JackKHash]

@CoinDesk @hashdag Game-changer: conditional commitments let small companies scale without merging, while keeping their full sovereignty. Finally a tech that gives power to the smallest — enabling huge groups of them to compete with the industry giants.

[Jack @JackKHash]

@KaspaKii Phenomenal work. I honestly didn't expect Kii to come up with solutions like this. You keep surprising us.

[Jack @JackKHash]

@KaspaKii Really impressive work. I see strong applications for AI governance, where an entire governance execution graph—not just the final state—can be proven to have been executed according to the governing rules. The end-to-end post-quantum verification is particularly compelling.

[Jack @JackKHash]

@LevendiPro I matched the $500

[Jack @JackKHash]

Your composable state machine looks like a very powerful primitive for governance, auditability, and shared trust across organizations.

We're building an Organizational State Machine, and your solution looks like exactly the execution/settlement layer our governance and trust systems need.

Really excited to see this built.

[Jack @JackKHash]

@BankQuote Great article. With the new ZK pipeline + PoW randomness, does Kaspa now have all the primitives needed for shielded/private transactions, or are key components still missing?

[Jack @JackKHash]

Isn’t it true that in GHOSTDAG the block rate is entirely decoupled from safety, which means higher BPS can safely increase decentralization — something that isn’t true in Nakamoto? And in PoS, increasing BPS leads to more centralization. But none of this is new. Why is he now pushing for 100 BPS? Doesn’t that imply they found a way to optimize the code so that even 100 BPS can run on cheap nodes? There must be more to it. For vProgs, isn’t BPS essentially the “clock frequency” of the decentralized computer formed by all vProgs?

[Jack @JackKHash]

What’s the point of paying with crypto if the total cost ends up higher than paying with fiat?

Here’s what you usually pay with Lightning (directly or indirectly):

Routing fees: 0.2%–0.5%
LSP fees: 0.3%–1%
Rate spread: 0.5%–1.5%
Merchant provider fee: 0.5%–2%
Fiat conversion: 0.5%–1.5%

Total practical cost to the user: roughly 2–6%.

Settlement on Lightning is not final — payments can be reverted, and the risk sits with the merchant

Lightning ends up looking like a more complicated, more expensive version of the card system it was meant to replace. And calling it “almost zero fees” while charging 2–6% is completely misleading — especially when true 0% payments are already possible, just not with Lightning.

Now compare that to using Kaspa:

Routing fees: 0% — not needed
LSP fees: 0% — no channels, direct on-chain settlement
Rate spread: 0% — DEXs guarantee the best available price
Merchant provider fee: 0% — merchants can receive directly on-chain
Fiat conversion: ~0.2% — only the DEX swap
Channel-opening fee: 0% — Kaspa does not require channels at all

On Kaspa, settlement is instant on L1, confirmed within seconds, and reaches the same security Bitcoin has after about an hour.

Kaspa Point of Sale doesn’t need any setup at all — it works instantly. No providers, no KYC, pure sovereignty, completely plug-and-play in seconds.

This was once Satoshi’s vision: true Peer-to-Peer Electronic Cash System

Not the current reality of Lightning, where it’s actually peer → provider → peer, with 2–6% in extra fees, added intermediaries, risk of failed payments, and only the hope — not the certainty — that it will eventually settle on Bitcoin.

[Jack @JackKHash]

Lightning is only trustless if you run your own node — which is risky unless you’re a pro, and completely unscalable because it would take 100 years for all humans to open channels.
It only scales when you trust LSPs to manage channels for you.
So Lightning is not trustless or permissionless in practice, because without providers most people can’t use it at all.

[Jack @JackKHash]

You’re wrong — they won’t have the power to block it.
We start with small, local community voting and crypto-project voting.
When people see how reliable it is — no failures, no manipulation, no distrust — the system proves itself.
Then we simply elect leaders who agree to implement it.
It’s not one big jump; it’s many small steps before the final one.
Saying “they won’t allow it” is surrendering your power — and that’s exactly what they want you to believe, that you don’t have real power.
With Kaspa and zk tech, we finally have the tools to unite our strength, restore trust in voting, and change everything.

[Jack @JackKHash]

In GD, red blocks can be seen as “late arrivers”: they are valid but arrive too far outside the main flow, comparable to distant stars in the sky that are visible yet not part of the constellation everyone agrees on. The “candle star” analogy fits the selected parent chain: these are the special, universally visible points the protocol tries to lock onto.

However, in GD the selected parent chain is still structurally vulnerable to reorgs. Because GD is a greedy algorithm, it may pick a chain that is not globally optimal—so an adversary with sufficient luck can force a reorganization even without violating assumptions. That structural greediness means the chosen chain is not maximally stable.

DK changes this. It is not greedy. Instead of picking the first valid chain that fits local rules, DK evaluates all feasible options and chooses the minimax-optimal chain—the one that minimizes the maximum possible disagreement among all honest observers. This property is structural, not statistical. Any honest observer with the same view of the DAG will converge to the same best choice.

As a result, the blocks in the DK-selected chain become the closest thing to “candle stars”: the blocks that all observers will independently agree on after one global round of communication.

DK is still probabilistic—as all permissionless PoW systems are—but the only remaining source of reorg probability is pure luck (Poisson variance), not structural weaknesses in the algorithm. That separation is unique to DK: it removes structural reorg opportunities and leaves only unavoidable probabilistic noise.

[Jack @JackKHash]

Great to hear. So the limitations of the EVM with respect to vProgs — do you have ideas on how to solve them? Would you need to develop an EVM template for vProgs, since the core team is not doing that and is only focusing on ACL-based VM templates? And do you see Igra as the solution that will make it easy to migrate EVM projects, while the future still needs to be ACL-based VMs, right?

[Jack @JackKHash]

As of my humble understanding: Rollup state roots become part of L1 state, in contrast to vProg state commitments which never become part of L1 state; they exist only as utxo anchors and disappear once the next commitment replaces them. In both cases many internal off-chain operations can be rolled into one state root or one state commitment, but the “up” — updating L1 — is only true for rollups. vProgs never update L1’s state root; they only post their state commitment and its ZK proof to L1.

[Jack @JackKHash]

It’s not a computer for heavy complex execution — but for trustless coordination, logic, state, permissions, and real-time decision flow for systems like games, AI agents, and industrial machines. Compared to existing blockchains with programs and smart contracts, vProgs can enable new, more complex applications that other chains can’t, because they’re sovereign, massively parallel, and globally composable. This makes real-time gaming, AI agent coordination, industrial machine control, and other advanced logic possible.

[Jack @JackKHash]

So every non-ACL-based VM can be easily wrapped — that’s really insane. I assume that in the future Kaspa’s native VMs will dominate, since they will probably be superior to any existing VM.

Can we call Kaspa with vProgs computationally the first fully distributed, sovereign, trustless, permissionless computer?

Because execution, state, sovereignty, scheduling, validation, and final ordering are all independently distributed and globally, trustlessly, permissionlessly composed through the DAG.