Senko: Private, Feeless, Lattice-Based Digital Cash

Senko (閃光) is Japanese for "flash of light." The ticker is SEN; coins are written sen (lowercase), as in "I sent you 50 sen."

Bitcoin gave us peer-to-peer electronic cash that needs no trusted intermediary, and it holds up on trustlessness and censorship resistance. It does not hold up on two properties that make physical cash useful:

• Privacy. Every transaction is permanently public: balances, counterparties, amounts. Handing someone a banknote records nothing.
• Cost. Every transaction competes for block space and pays a fee. Cash does not charge a toll per use.

Three later projects each fixed part of this and left part broken:

• Monero made privacy mandatory: ring signatures, stealth addresses, hidden amounts. It kept Bitcoin's linear chain (so it is slow), and its all-or-nothing anonymity made it a regulatory target. By 2025, dozens of major exchanges (reported) had delisted it, and an EU rule effective 2027 restricts anonymity-enhancing coins on licensed platforms. Privacy you cannot access has limited value.
• Nano showed that money does not need one global chain. Its block-lattice gives each account its own chain, settling sub-second with no fee. It has no privacy, no programmability, and its spam defenses have struggled under sustained spam (notably the 2021 spam episode).
• Ethereum added programmability, but state is public and fees are volatile.

No existing system has all of these properties at once. Senko is an attempt to combine them.

The structural choice most privacy coins never revisited: money does not need a single, globally-ordered ledger.

Bitcoin, Monero, and Zcash all funnel every transaction into one chain in a strict global order. That ordering is the source of the latency and the fee market. Nano's block-lattice takes a different route: every account has its own chain. A payment is two independent records, a debit on the sender's chain and a credit on the receiver's. Unrelated accounts can be validated in parallel. There is no global queue and no block-space auction, which is why it is fast and free.

Senko builds on that and adds the parts Nano left out:

1. A privacy layer built into the account model rather than bolted on.
2. Programmability via "smart accounts" that reuse the same primitives as ordinary accounts.
3. A spam defense that holds up: a one-time economic cost plus an always-on, load-scaling proof-of-work, instead of per-transaction fees.

The target is digital cash that is private by default, feeless, fast, programmable, and still accessible on regulated infrastructure.

You do not need the math to follow the design. The technical specification has the constructions.

Every account is its own chain

Each account has its own chain of records. Sending writes a "send" block to your chain; the recipient writes a "receive" block to theirs. Because your chain is yours alone, your payments do not queue behind anyone else's. This is what makes settlement fast and feeless.

Private by default: three layers

Privacy is not an optional mode. It is how the protocol operates.

• Hidden amounts. Balances and transfer amounts are stored as commitments. Validators can check that the arithmetic is consistent (no overspend, no minting) without seeing the values.
• Hidden receivers. Each payment targets a fresh one-time address derived for that transfer. Only the recipient can recognize it. An observer cannot tie it to a person.
• Hidden senders (two levels). Each block is signed with a per-block key derived from the account's master secret, so the long-term spend key is never exposed on chain. On the base transparent layer the account identifier is cleartext, so an observer can group that account's own blocks: the transparent layer is pseudonymous, not unlinkable.

True sender unlinkability comes from the shielded pool, which is built, integrated into consensus, and enabled in the mainnet genesis configuration (mainnet has not yet launched). It is a note-commitment tree and a nullifier set: a spend proves note ownership and value conservation in a succinct STARK proof and reveals only a nullifier and the new output commitments. The witness (input note, value, owner) never appears on the public transcript, so transfers within the pool cannot be linked to one another.

Crossing the boundary between the transparent and shielded layers (shielding value in or unshielding it out) does reveal the amount and the transparent counterparty at that edge, the same cost as any transparent-to-shielded transition. Unlinkability holds for value that stays inside the pool; wallet denomination discipline narrows what the edge reveals. Practical unlinkability also depends on the size of the shielded set: a spend hides among the notes already in the pool, so a small pool offers weaker anonymity than a large one regardless of the cryptography.

It uses a STARK-native commitment (the proof stack is Plonky3), so range and balance are checked inside the proof and the scheme stays post-quantum. The pool has been built and adversarially reviewed internally across multiple passes; hardening the circuits toward formal verification is an ongoing goal (see §7). So sender privacy at launch ranges from pseudonymous (transparent transfers) to unlinkable (shielded transfers), and a holder chooses per payment.

Selective disclosure

This is the property that keeps Senko off Monero's path. The holder can lift privacy selectively, cryptographically, and only toward a chosen party:

• Prove a specific payment happened, to a specific party, without revealing the amount. This is a Schnorr sigma proof bound to the transaction, checkable by anyone holding your spend public key, with no secret required.
• Prove a payment was under a threshold (for example, under $10,000) without revealing the figure. This reuses the on-chain Bulletproofs range proof.
• Hand an auditor a view key that exposes your own history and nothing about anyone else.

These disclosures are off-chain and point-to-point. Disclosure today uses classical cryptography (Schnorr and Bulletproofs); a quantum-resistant STARK-based disclosure backend is a planned upgrade (§7). (The shielded pool's own spend proofs are already STARK-based and post-quantum; this note is about the transparent-layer disclosure attestations.) The point is operational: an exchange or auditor can get exactly the assurance it needs without the chain being public.

Programmable, privately

A smart account is an account with code attached. An incoming payment is a message; the code runs, updates its state, and may send payments out, using the same primitives as a normal account. There is no separate contract layer, no gas auction, and no shared global state to contend on.

In v1 smart accounts run on the transparent layer: their code and state are public, the same as a normal transparent account. Private smart accounts, where contract logic and state are proven in a succinct STARK proof and would enable a private exchange with hidden trade sizes, private escrow, and private lending, are future work and not part of the launch; they depend on a STARK-based execution layer that is not yet built. Note the trade-off: the lattice favors independent per-account logic over the synchronous, shared-state composability of an EVM, so high-contention DeFi is not the target.

Spam resistance

A feeless system has to answer the obvious attack: if transactions are free, what stops a flood? Senko uses two independent mechanisms.

First, a one-time account-creation cost of 5 SEN (the SEN amount is fixed; its fiat value is not, and SEN has no market price pre-launch, so any dollar figure is only an expectation), paid when you open an account. 75% is burned; the rest accrues to a relay-reward pool designed to pay nodes for serving sync data to new users (implemented but not active at launch; the operator enables it after calibration). Nodes additionally throttle admission when accounts are being created unusually fast, a relay-level back-pressure that raises the effective cost of mass registration during the cheap early-network window. A normal user pays once. An attacker who wants a million accounts pays for each one and gains nothing.

You can open an account either way. The usual path is to have an existing account pay the one-time fee to your new address, the way an exchange, a peer, or a faucet would. But a newcomer with no coins and no benefactor is not stuck: instead of the fee, you can mine your way in, opening your account by doing a small amount of proof-of-work. That makes the on-ramp permissionless, anyone with a CPU can join, and it stays farm-resistant because the cost is per-account compute, the same class of real compute cost, not a claimable giveaway someone can claim a million times. The mined open is calibrated to cost about what the fee costs, so neither path is the cheap way in.

Second, a small proof-of-work on every transaction. It is cheap enough that the wallet precomputes it before you send, so normal use has no felt latency, but every transaction costs some real computation. Every transaction must clear a fixed proof-of-work floor that every node enforces as a consensus rule. Under load, nodes additionally raise the difficulty they will admit locally, so under a flood the attacker is the one paying and the cost rises as they push harder; normal users at human transaction rates do not notice. This is work, not a fee, so the system stays feeless. Because it is a consensus rule, a malicious node cannot waive it to let a spammer through. A per-account rate limit, scaled by bonded stake and not by account age, covers the case of a single account flooding from one identity.

Supply is disinflationary with a perpetual security floor.

Coins are minted on a front-loaded halving schedule, similar to Bitcoin's, with one change: instead of decaying toward zero and creating a security cliff, emission settles into a perpetual constant tail (a fixed number of coins per hour, indefinitely). The emission rate trends toward ~0% while the absolute security budget never reaches zero.

"One billion coins" is a soft reference, not a hard cap. The tail keeps minting, so circulating supply drifts past it slowly. The account-creation burn pulls the other way, so at maturity the system is likely net-flat to mildly deflationary: small constant emission, ongoing burns, and coins lost over time.

The reason for a tail: Senko is feeless, so there are no transaction fees to fund security. The tail funds it through a small, predictable dilution shared across all holders. That is arguably fairer than per-transaction fees, which load the cost onto active users, and it avoids the security cliff a fixed-cap feeless coin hits when emission ends.

Minted coins go to representatives (the accounts running nodes and securing the chain) in proportion to stake bonded to them. Representatives keep a commission and share the rest with delegators, so ordinary holders can earn without running infrastructure. Emission constants are integer-only and deterministic; see the specification.

75% of supply goes to the community through two mechanisms aimed at real participants rather than insiders (the 2026-06-27 tokenomics lock; the planned Monero airdrop was dropped on 2026-06-29 and the capped onboarding pool on 2026-06-30, both folded into front-loaded CPU mining, see the lock-and-vesting design note):

• CPU mining (53%, ~8-year window). An ASIC- and GPU-resistant algorithm (the one Monero uses, so Monero miners are already equipped), emitted over an eight-year window on a two-year reward halving. The schedule is front-loaded: most of the budget is paid in the first four years, and the dropped airdrop's 10% and onboarding's 8% were added by raising the per-epoch rate on that same curve, so the extra coins land early. Mining is the strongest sybil resistance available because it costs real resources and needs no identity. It is bootstrap distribution, not consensus security; staking secures the chain.
• Staking / representative emission (22%, front-loaded + perpetual tail). The security budget: a front-loaded schedule (four-year halving) plus a small constant per-epoch tail that never dies (§4), paid to representatives and delegators in proportion to bonded stake.

Zero-coin newcomers do not need a giveaway to get started: the PoW-to-open cold-start (CANON v17 open_pow_target) lets a fresh account open its on-chain identity by doing a small amount of proof-of-work, a permissionless and farm-resistant on-ramp that costs compute rather than a per-account claim.

Insider allocations sit in two buckets that do not mix: 10% Founder (five-year linear vest, no cliff, enforced on-chain, never spent on operations) and 15% Ecosystem Treasury, itself split so the bulk is not a genesis lump: a 5% genesis seed (multisig, immediate runway) plus a 10% emission STREAM paid out over a five-year sunset and then stopping (a renewable, time-boxed dev fund, not a perpetual tax). The treasury funds audits, bug bounties, liquidity, listings, and grants; contributors are paid as named grants from it.

Scroll the table horizontally to see every column.

Separately from this supply distribution, the relay-reward pool (funded by a share of account-creation fees, §A7) is designed to pay the seed/relay nodes that serve sync data (not active at launch), a fee-recycling reward for infrastructure operators, not a slice of the 100% above.

Three design notes worth stating, since each was a real change. First, an earlier draft put 55% of supply into an "activity faucet" that dripped coins to accounts by on-chain activity. That was removed. A privacy chain cannot verify "genuine" activity without surveillance or KYC, so any activity signal is either privacy-leaking or trivially gamed, and a 55% bucket of gameable rewards is a honeypot. The 2026-06-27 lock raised the community share to 75% (mining 30→35%) and split the old single 16% treasury into a 5% genesis seed plus a 10% sunsetting stream, so the standing insider lump at genesis is only 15% of which just 5% is liquid.

Second, the planned Monero airdrop was dropped on 2026-06-29 and its 10% was folded into CPU mining, front-loaded. The airdrop would have required a committed XMR snapshot and a reviewed ownership verifier to open safely; rather than ship that machinery, the owner moved the allocation into the mechanism that already needs no identity and costs real resources.

Third, the capped onboarding pool was dropped on 2026-06-30 and its 8% was folded into CPU mining (now 53%), front-loaded the same way. The onboarding pool's purpose was to give zero-coin newcomers a way onto a feeless chain, but an open per-account giveaway is a farming surface, and the PoW-to-open cold-start (CANON v17 open_pow_target) now covers that purpose with compute rather than a claim, a permissionless, farm-resistant on-ramp. Distribution therefore runs entirely on resource cost: mining for the bulk of supply, and a small proof-of-work to open a new account. Both the airdrop's 10% and onboarding's 8% were added by raising the mining per-epoch rate on the same front-loaded halving curve, so the extra coins are paid out early rather than held in a genesis pool.

Scroll the table horizontally to see every column.

*Finality is quorum-based and not gated by the block interval, so settlement is sub-second when votes propagate normally. Under a degraded or congested network it takes longer; sub-second is the design target under normal conditions, not a protocol-enforced bound (measured on testnet; not yet demonstrated on mainnet at scale).

Roadmap and open problems. Several items below have moved from "planned" to "built" since the first draft; each states plainly what is implemented versus what remains:

• Full quantum resistance. Signatures already have it on mainnet. Hybrid Ed25519+FALCON-512 block signing is implemented and, under the mainnet launch posture, is required by the mainnet genesis configuration (the require_pq consensus parameter is on): every block carries both an Ed25519 and a FALCON-512 (lattice) signature and both must verify, so the chain stays secure even if one scheme is later broken. (A test or legacy chain can leave the parameter off and run Ed25519-only.) The shielded pool's spend proofs are also already post-quantum, they are STARK-based (Plonky3). The remaining classical pieces are the TRANSPARENT-layer proofs: Bulletproofs range proofs and Schnorr disclosure attestations. The staged path for those is hash-based STARKs, which are quantum-resistant. A 2026 review picked the tooling: Circle STARKs (Stwo) for a post-quantum disclosure backend behind the existing disclosure interface, and recursive folding (Plonky3) for succinct whole-chain proofs. The per-payment transparent range proof can stay Bulletproofs, which are small and fast enough for mobile. The transparent-proof migration is not built yet; the FALCON signature work and the shielded STARK proofs are.
• Trustless light clients. A light wallet currently trusts a server's view of the chain. A recursive proof of the global state root would let a phone verify the whole ledger's validity directly, which is the basis for trustless mobile and web wallets and the in-browser "verify-it-yourself" explorer.
• Network-level privacy. Hiding amounts and recipients does not hide the IP a transaction originates from. The first layer of defense is built: Dandelion-style stem routing relays a new block privately through a short line of peers before it is broadcast, so the first node to publish a block is not its originator. That breaks the simplest network deanonymization, which links an account to the IP that first broadcasts its blocks. The discovery layer is also hardened: a Kademlia-style routing table (the structure behind discv5) makes a node learn peers spread across the identity space instead of trusting whoever floods it, which resists eclipse attacks. Crucially, only peers whose identity is confirmed by a completed handshake enter the routing table, so an attacker cannot poison it by sending fabricated peer records. The third layer is also built: an optional Tor transport routes a node's outbound connections through the Tor network, so neither a peer nor a network observer sees the origin IP. It composes with the stem routing above for origin privacy at both the peer-graph and IP levels, and is opt-in because Tor adds latency. All three slot behind interfaces the node already has, so none of them touch consensus: stem routing runs by default, while the Tor transport and the eclipse-resistant Kademlia discovery are opt-in.
• Private cross-chain bridges. Bridging today leaks everything. A succinct STARK-based bridge would let value move in and out privately.
• Audit and formal verification. Assurance to date is internal: repeated adversarial review with every fix re-audited. Senko has not had an external security audit, and no independent party has reviewed the shielded circuits. An external audit of the consensus rules and the STARK circuits, plus machine-checked formal verification, are prerequisites we consider necessary before mainnet. Until then, treat the shielded pool as unaudited.

Senko is digital cash that settles in about a second, costs nothing to send, and does not publish your balance or your counterparties, while staying usable on exchanges through selective disclosure. Bitcoin proved the concept but is public and fee-bearing. Monero solved privacy but is being regulated off the usable rails. Nano solved speed and cost but not privacy. Senko is an attempt at the combination, with the limitations stated plainly above.

The exact cryptographic constructions, data formats, consensus rules, and parameters are defined in the companion Senko Technical Specification. Parameters are subject to revision based on simulation, formal analysis, and review before mainnet. Nothing here is investment advice.

Version 0.3 · revised July 2, 2026 (honesty/accuracy pass) (first draft May 30, 2026).