Below is a lightly cleaned-up English version of the transcript. I removed filler words, repetition, and random stumbles, but kept the meaning intact. The interview was conducted and streamed live on the Web3 Voice channel.
Timestamps are included so you can locate the part in the video. The original video is in Russian. Auto-generated subtitles are available.
If that is not enough I made this structured brief.
And if that’s not enough… well, I don’t know, hire an AI or something.
0:00
Hi everyone, this is Web3. Today our guests are the co-authors of the Acki Nacki consensus protocol and tokenomics: Nikita Sattarov and Mitja Goroshevsky.
Mitja, you and I know each other; Nikita, let’s get acquainted. How did you join Acki Nacki, and what did you do before?
1:01
Nikita: Hi everyone. I joined Acki Nacki after meeting Mitja, basically recommended as a strong mathematician. I’ve worked in math all my life, mostly probability theory. For the last 3-4 years I’ve also worked on decentralized protocols, focusing on the mathematics inside protocols.
1:52 — Q: What determines the “block reward”?
Nikita: I wouldn’t call it a block reward; it’s computed per epoch. An epoch lasts some period of time, and over that time Block keepers get paid. The amount depends primarily on a parameter called reward-per-second, which controls current token emission. That parameter is adjusted automatically based on how many tokens are already minted relative to Total Supply.
There’s also the epoch duration. Reward-per-second × epoch length gives the total rewards to be paid for that unit of time, then split among Block keepers. Each validator’s epochs are individual, so at epoch start we freeze the proportions for splitting.
- If there are no stakes yet, it’s split equally among all Block keepers (counted at epoch start for that validator).
- Once tokens exist, it’s split by stake proportion × reputation coefficient (both taken at epoch start: network total stake, the Block keeper’s stake, their proportion × rep-coef).
Mitja: Two notes. (1) Only 67.5% of emission goes to Block keepers. The rest is allocated differently for Block Managers (10%) and Mobile Verifiers (22.5%), calculated via slightly different logic. (2) Practically rewards are computed over time, but if there are no blocks, no rewards can be paid. The protocol ensures blocks are produced (if a producer fails to meet timing, it’s replaced). Philosophically, it’s still “reward per block,” but implementation uses time.
5:44 — Q: Rewards now split per license, not per node, how?
Nikita: At a high level, a Block keeper has a reward pool which is then split equally among all licenses delegated to that Block keeper. Tokenomics parameters are aggregates from licenses: each license stakes; stakes are summed; each license has a rep-coef; we compute the average rep-coef; the Block keeper’s reward is computed from these, then divided equally across that Block keeper’s delegated licenses.
11:39 — Example: two validators
If Validator A has 1 license and Validator B has 20, the total reward to B is ~20× A’s (all else equal), but per license it’s the same.
MinStake differences? Yes, MinStake can differ markedly between nodes based on license distribution.
If a license’s available stake drops below MinStake, licenses currently enjoy a privilege: as long as the license restakes all earned tokens and has not lost its reputation privilege, its effective stake is treated as MinStake, so it keeps earning. This “license privilege” lasts while licenses exist (two-year window).
15:15 — Q: If ~15% of validators exit, do remaining ones get less?
Nikita/Mitja: The curve (emission schedule) doesn’t change; reward per remaining license goes up because the same emission is shared among fewer licenses/nodes (split is proportional to stake and license counts as defined). In short: fewer participants → larger slice for those who remain.
17:55 — Calculator on the site
It reflects the intended math from tokenomics (not every implementation nuance). It’s most exact when each node runs the optimal 20 licenses. Minor deviations can come from the license MinStake privilege.
19:34 — Q: “Cores” are fractions of a license?
Mitja: That’s not tokenomics. “Cores” are a private offering by a company (e.g., TVM Labs) renting validator equipment + license capacity to people who can’t run a node. Anyone with a license could do a similar service. It’s off-protocol, purely private, with no public math behind it.
22:41 — Q: Broader network liquidity design: bridges, DEX, exits
Mitja: We don’t centrally plan liquidity. The bridge we built and handed over is 1:1 (no partial reserves). If you bring USDC in and get wrapped USDC on Acki Nacki, you can always bridge back 1:1. There’s no pool risk like fractional liquidity.
Buying Shell (gas): Users swap USDC → Shell; those USDC go to an Accumulator contract where they are locked.
Who can withdraw from the Accumulator? NACKL (the network token) holders, specifically validators, can exchange NACKL → USDC from the Accumulator pro-rata to their share of current total NACKL supply, burning those NACKL. This establishes a floor (not a “baseline”) for NACKL.
Contracts may be upgradable early for safety; the economic structure (e.g., floor logic) is intended to be stable.
33:03 — Circulating supply on CMC/CG
Mitja: All mined NACKL are circulating. At any time, a validator can exit and do what they want with tokens. So Current Total Supply – burned (e.g., via Accumulator) is the circulating supply.
35:06 — DEX pairs
The DEX will be order-book-based (not AMM pools). Typical base pairs will be NACKL and Shell; stables will be present via bridge.
36:48 — Why 67.5% / 22.5% / 10% splits?
Nikita: It reflects our assessment of contribution to the protocol:
- Block keepers (67.5%) do core work.
- Block Managers (10%) provide network access (fewer are needed vs. Block keepers).
- Mobile Verifiers (22.5%) collectively add security at massive scale. Individually small, but the aggregate improves safety.
41:57 — Why more value to Mobile Verifiers than Block Managers?
Mitja: Block Managers are like RPC infrastructure, important for access but not directly security-critical. You can have access via other gateways. Mobile Verifiers’ value emerges at scale; without enough of them, security suffers. Hence their share.
44:21 — License privilege vs. “burning a license”
There is no concept of “burning a license” for withdrawing coins. If a license doesn’t restake sufficiently, it loses the privileged MinStake treatment and reputation, but the license still exists and may validate again if requirements are met.
48:01 — Q: Shock scenarios & smoothing mechanisms
Nikita: If many Block keepers exit, the protocol lowers MinStake to attract new Block keepers as needed based on network load/capacity (empirically measured by TPS headroom). In crypto winters (low activity), the reverse applies, MinStake adjusts.
51:44 — Consensus security: 51%/Byzantine assumptions
Mitja: Like any protocol, if the assumptions break (e.g., majority collusion), guarantees fail. Early on, the economic/real-world incentives make it irrational for initial validators to attack (they’ve just paid for licenses/hardware). As the network decentralizes, validator count increases.
On “fastest possible”: our message complexity is essentially 2 (two interactive steps; a third “notify” step may happen in parallel). For interactive protocols, you can’t do better than 2.
1:00:00 — Complexity details
Formally it’s ~O(2) with a tiny overhead due to the optional notify; practically it’s two rounds: producer broadcasts block; verifiers attest; sometimes a small set also informs the producer, parallel, not delaying finality.
1:01:53 — Free float vs. reward speed
Nikita: Free float (portion of supply that may be off-stake) and supply each have pre-defined curves. Free float is enforced via MinStake rules; current supply is driven by reward-per-second. If exits push the system, MinStake and privileges handle edge cases; it’s extremely unlikely to exceed planned free-float due to the privilege constraints and how MinStake adapts.
1:10:20 — Is this “like Bitcoin” despite license privilege?
Mitja: Yes, the economics parallel Bitcoin: finite supply, declining issuance, cost to participate, ability to sell hardware/right to validate (here: license + stake). The license privilege exists to allow selling new licenses later without selling tokens upfront (so it’s not a token sale). If you withdraw stake from a running license, you lose privilege/reputation, so you can’t arbitrage the system. Selling a license is akin to selling a miner; market participants replace each other with little systemic effect.
1:15:08 — Transferring a license & stake
You can set the owner public key to transfer control. Sales/escrow/marketplaces can be built by the community (DEX listings for licenses, etc.). It’s not the protocol’s job to host a marketplace.
1:18:04 — Can a newly sold license validate without stake?
Only under the two-year privilege window (for new, unused licenses). If you already validated and then sold/withdrew stake, the privilege is gone; you need MinStake.
1:23:45 — Game-theory stress: big holders exiting
If a big holder sells licenses + stake, buyers likely keep validating (economic incentive), so network capacity remains. If they sell only tokens, MinStake adjusts to draw new validators. The system’s dynamics are designed to re-equilibrate.
1:24:51 — Worst economic scenarios
Nikita: Large validator exits → MinStake drops to recruit others. Free-float is maintained algorithmically via base MinStake targeting. Net: the protocol adapts to keep capacity and planned free-float.
1:28:06 — Binary system: NACKL & Shell; why Shell is “stable-or-less”
Mitja: Two opposing goals:
- NACKL (staking/security) should appreciate (finite supply, declining issuance → higher attack cost).
- Gas should be stable/cheap, even inflationary, to promote usage.
Hence two tokens: NACKL (value accrual) and Shell (gas).
Mechanics: Shell is sold by a “central bank” contract for a fixed USDC rate (e.g., 1 USDC = 100 Shell). Users can also return Shell to the sale queue (FIFO) and reclaim USDC when the next buyer arrives, so Shell price can’t exceed the official rate, and can temporarily trade below it if someone wants instant liquidity.
All USDC paid for Shell is locked in the Accumulator. NACKL holders can burn NACKL to withdraw a pro-rata share of that USDC, this creates a floor for NACKL. Importantly, selling NACKL to the Accumulator rarely makes sense versus the open market (which prices future value), so USDC tends to accumulate, raising the floor over time.
Long-term basket risk (USDC, etc.): initially USDC (benefiting from upcoming regulatory reserve rules). In future, validators could adopt a basket via node software upgrades; there’s no on-chain governance voting, validators choose which client to run.
1:46:33 — Launch plan
Waiting on final validator infra hookups (e.g., bandwidth provisioning). Sequence: finish current refactors → pre-net → test mining + wallet + Popit mini-apps (iOS wallet issue resolved) → fix issues → mainnet. Wallets installed for pre-net will roll over; on day one of mainnet you’ll see the ceremony prompt.
2:04:10 — Mainnet “ceremony” (ZK setup)
It’s a decentralized Powers-of-Tau–style ceremony to produce a CRS (Common Reference String) for Groth16 proofs. The app runs a lottery for slots; if selected, your device downloads a large blob (use Wi-Fi), derives randomness (yes, you’ll be asked to “draw” on screen), computes the contribution, uploads it to IPFS, and the on-chain contract stores the hash.
Security: as long as at least one participant destroys their “toxic waste,” the setup is sound. With hundreds of thousands of contributors, the probability of compromise collapses. (References: Gabizon-Myers “MPC MMO RPG”; work by Ben-Sasson, Chiesa, etc. Acki Nacki’s contribution is randomizing & parallelizing to scale participants massively.)
2:17:00 — Book recommendation
Mitja: The Dao of Capital: Austrian Investing in a Distorted World by Mark Spitznagel.
2:21:26 — Closing
Thanks to Nikita for the math deep-dives. Stream wraps; recording will be on YouTube. Sub to Web3.
