Acki Nacki decentralization: No Keys, No Kings, No Roadmaps

September 29, 2025 2 weeks ago 8 min read
nokeys-noroadmap

Mitja dropped a X post (tweet), well, few of then and they read like a detonator.

No roadmaps, no promises, no keys held by owners/founders, just code that ships and wallets that are 100% yours (And if you lose it, it’s 100% your loss.).

Pre-launch is boring on purpose, post-launch is where the fun begins. We start in Bitcoin-mode, mine and move, then light up the rest when SHELLs flow.

Licenses are scaffolding, not a throne, time-boxed and capped so power can’t squat. Net result, less drama, more build energy.

Dapp AI says this is how you avoid security theatre and still make something people can actually use. I say it feels like optimism with a checksum.


Decentralization Statement №1 – self-custody wallets

Mitja’s post: At mainnet, wallets are 100% self‑custody. Devs don’t hold user keys, ability to change wallets code, block or move funds. There is no control or custody of user wallet accounts, whatever NACKL or Pop Coin wallets. Full stop.

What it means:
Your wallet is yours. Only you hold the private keys. The devs can’t change your wallet’s code, freeze it, or move your funds. Same rule for both NACKL and Pop Coin wallets. Full stop.

Why it matters:
If someone else can touch your keys, it’s not crypto, it’s a bank app with extra steps. Self-custody is the baseline for decentralization and for most regulations around “not a custodian.”

Reality check:
Acki Nacki’s design separates security and usage into two tokens and emphasizes user-run roles, but “self-custody wallet” is an implementation detail of the wallet software you use. Always verify the wallet is open-source, reproducible, and that you generated and back up the seed yourself. Acki Nacki docs describe non-pooled participation and user-held keys assumptions for validators and verifiers, which is consistent with self-custody culture.


Decentralization Statement №2 – pre-launch isn’t “crypto”

Mitja’s post: Pre‑launch is not “crypto”. Meaning, what happens before the Launch — Node License sale, preps for the launch, tech support, infrastructure agreement etc — do not need to be decentralized, because there is no network and no tokens yet!

What it means:
Before the network launches, there’s no live chain and no live tokens. So things like selling node licenses, renting servers, signing infra contracts, and giving tech support are just normal company ops. They don’t need to be decentralized because the network doesn’t exist yet.

Why it matters:
People often judge centralization too early. Pre-launch logistics can be centralized without affecting how the chain runs after launch.

Reality check:
This matches how many networks spin up. It also aligns with interviews stating test and pre-net phases are handled by a small core team before mainnet.


Decentralization Statement №3 – no roadmaps, no promises

Mitja’s post: No Roadmaps, no future references, no promises on behalf of the network. Why? If you promise = you control =it is not decentralized = it is a Security = Regulation = No Crypto! Get it? Roadmap = Scam

What it means:
They won’t promise future features or dates “on behalf of the network.” Promises imply control. Control implies a common enterprise. That pushes you toward “security” in the legal sense. The claim is simple, roadmap equals marketing promise equals legal risk.

Why it matters:
Decentralized networks work best when no one entity sets the future. Less “we promise X by Y,” more “the protocol runs, participants build.”

Reality check:
Pragmatically, you’ll still see engineering goals and research, just not investor-grade promises. Interviews repeatedly stress timelines are hard and shifting, which is why they avoid promises.


Decentralization Statement №4 – licenses: 10,000 total, ~50% allocated, GOSH <25%, 2-year term

Mitja’s post: Licenses 10,000 total; ~50% allocated. Any future sales, if any, will be public. GOSH holds <25% of licenses and won’t increase share (per the License Agreement). License term: 2 years then any miner with the minimum stake can self‑issue a license

What it means:
There are up to 10,000 validator licenses. About half are already sold or assigned. GOSH holds less than a quarter and says it won’t go over that. Licenses last 2 years, then any miner with the minimum stake can self-issue a license.

Why it matters:
Spreading licenses limits any single party’s power. A finite term plus a path to self-issue reduces lock-in over time.

Reality check:
We don’t have this exact breakdown inside the public tokenomics PDF. Related materials do describe a large validator set via license sale, and that delegation and pools are discouraged, which supports the decentralization intent. Treat the 10k / 50% / <25% / 2-year specifics as Mitja’s claim unless and until the formal License Agreement is published.


Decentralization Statement №5 – start in “Bitcoin mode”

Mitja’s post: at the start of the network it’s impossible to deploy any smart contracts. Why? Because there is no way to buy Shells before any bridge to another network exists. So we start in pure Bitcoin mode: only mining NACKL and transfers are possible

What it means:
At launch, you can mine NACKL and transfer it, but you can’t deploy smart contracts yet. Reason given, you need SHELLs to pay for computation, and before any bridge or faucet exists there’s no way to buy SHELLs, so contracts are off until the system can supply them.

Why it matters:
This lowers attack surface on day one. Bootstrapping simple, then adding complexity later. Bitcoin did the same, no contracts at start.

Reality check:
Acki Nacki splits tokens by role, NACKL for security, SHELL for computation. Docs confirm SHELL is the compute token. The exact “no contracts until bridge” switch-on timing is not in the tokenomics PDF, so treat it as a launch-plan detail from Mitja, consistent with the two-token model.


Decentralization Statement №6 – no exchanges before full decentralization

Mitja’s post: No Exchanges before full decentralization. GOSH is EU Company, we respect the law (MiCA) we do not control user keys (see №1), no tokens listing even on DEX (see №5) . Acki Nacki is fully compliant with both US and EU regulations.

What it means:
No token listings, including on DEXes, until the network is fully decentralized and compliant. GOSH is an EU company, so they say they’ll respect MiCA rules and avoid behaving like a custodian, which ties back to Statement №1.

Why it matters:
Early listings create pressure to centralize, make promises, or intervene. Skipping listings removes those incentives and lowers regulatory risk.

Reality check:
Saying “we’re compliant” doesn’t make you compliant. What helps is the architecture, for example no staking pools at the protocol level, user-held keys, and rewards for participation instead of “fixed staking APR,” all of which are documented and typically viewed as more commodity-like than security-like. Actual legal status depends on regulators, disclosures, and how sales are conducted.


Decentralization Statement №7 – who decides changes?

Mitja’s post: Acki Nacki is a living organism, it will grow and change with time. How those changes will be made? Who decides if the “protocol is the law”? Block Keepers, Block Managers, Mobile Verifiers — they decide. Developers can propose changes to the protocol, software, in a form of software update or configuration changes etc. but any such change will have to be adopted by people running this software. When they adopt it — they simply run that software, produce that block, validate that block or verify it. They choose which software to run, which block to sign, which game to play.

What it means, human-sized:
Acki Nacki evolves like software, not like law. Devs can write updates, propose new settings, or ship a new client. But nothing changes unless the people who run the network choose to run that software and use it to produce, attest, or verify blocks. The deciders are the operators, not the authors. In practice, that means Block Keepers, Block Managers, and Mobile Verifiers adopt or ignore updates by choosing which client to run and which blocks to sign.

Why it matters:
Power flows to whoever signs blocks. If operators dislike an update, they can refuse it. That creates real accountability. Devs propose, the network disposes. Governance by adoption, not by announcement.

Reality check:
The protocol defines clear roles that actually move the chain forward, and they are the ones rewarded for honest participation: Block Keepers attest and may become Verifiers, Mobile Verifiers independently check transactions, Block Managers handle external messages. Rewards are split across these roles, which aligns incentives with “those who run the software decide.” None of this requires delegation to a central team, and participation is permissionless for these roles.

Concrete picture:

  • Developers publish a new client version or config.
  • Block Keepers download it or don’t. If they run it and keep attesting and, when selected, verifying, that version wins ground. If they don’t, it stalls.
  • Mobile Verifiers continue to verify transactions independently. If they flag nonsense, it won’t finalize, even if a few BKs try to push it.
  • Block Managers keep the edge traffic clean and are paid based on processed externals, also by epoch. If a change breaks flow, they can refuse to run it.

Quick glossary

  • Self-custody: you hold your keys, you hold your coins.
  • License: permission to run a validator under launch rules. Not forever.
  • NACKL: the security coin, staked by validators, earns a share of network value.
  • SHELL: the compute token that pays for running code on-chain. Price aims to stay low so apps are cheap to run.
  • “Bitcoin mode”: when a chain only supports minting and transfers, no contracts yet.
  • No roadmap: not playing the promise game, reduces legal and centralization risk.

Dapp AI, the sidekick

  • If someone can flip a switch and change your wallet, it’s not your wallet.
  • If pre-launch ops must be decentralized, you’ll never launch.
  • Roadmaps are vibes with dates. Protocols are code with incentives.
  • License caps and time limits are scaffolding. They should disappear as the network stands on its own.
  • Contracts later is boring, and boring is good for security.
  • “Compliant” is earned through behavior, not tweets. Ship the rules into code, then ship the code.