Private Monetary Infrastructure / Testnet Phase

Building the Financial Privacy
the World Was Promised.

A trustless, private monetary network. Built by one developer. No venture capital. No compromise.

scalar-node — dev environment
$ scalar-node --status
 
Protocol: v11.1-FINAL
Environment: local dev
Spec status: COMPLETE
Supply cap: fixed enforced in protocol
Public testnet: not yet deployed
 
$

What Crypto Got Wrong

Three decades of digital money experiments. Three fundamental failures nobody wanted to admit.

Transparency ≠ Privacy

Making every transaction visible to everyone was called innovation. It was surveillance with a different logo. A public ledger means every employer, government, and stranger can trace exactly where your money came from and where it goes.

Decentralization Theater

When the top 10 wallets control the majority of governance votes, you haven't removed central authority. You've just changed who holds it. Voting on protocol rules is not decentralization — it is politics by another name.

Rules That Can Be Rewritten

A monetary supply that can be changed by a vote is not a supply limit. It's a suggestion. The entire premise of sound money collapses the moment enough stakeholders can agree to change the rules that protect you.

Not What We Added.
What We Refused to Compromise.

Four properties. Each one unbreakable. Not by design preference — by mathematical enforcement.

01 / PRIVACY

Privacy by Default

Every transaction is private — enforced cryptographically at the protocol level. There is no transparent mode, no optional disclosure setting, no "compliance mode" that can be enabled by a future governance vote. Private is the only mode.

02 / ENFORCEMENT

Math Enforces the Rules

No team, no multisig wallet, no governance committee, no emergency council can override the protocol. The rules are expressed in mathematics. Mathematics does not hold meetings or accept pressure.

03 / SUPPLY

Fixed Supply — Immutably

The maximum supply is embedded in the protocol itself. It cannot be changed by vote, by emergency, by upgrade, or by any other mechanism. What is issued is what will ever exist. Full stop.

04 / INDEPENDENCE

No Third Party Required

No oracle feeding external data. No bridge depending on a federation. No sequencer operated by a company. No ceremony. No assumption that someone, somewhere, did the right thing and deleted something they should not have kept

Core Principles
"

Scalar doesn't ask you to trust us. It was designed so that you never have to.

"

Truth by Mathematics, Not by Majority.

"

Governance by Genuine Operation, Not by Stakes.

"

Hardened by Determinism, Secured by Analysis.

Where Things Stand

No public testnet numbers yet — only a complete specification and a functional local implementation. The testnet is not a demo. It is a destruction test. We are actively trying to break the protocol so that no one else can. Nothing ships until this phase produces no surprises.

Protocol Specification
Consolidated — single source of truth, no version
Code Alignment
Complete — 9 discrepancies corrected
Core Implementation
Functional — 1,400+ unit tests passing
Security Audit
Complete — 3 of 4 findings resolved
Wallet — Key Management
Complete
Wallet — Transaction UI
In progress
Hardening & Testing
Active — pre-public testnet
Formal Audit (2 firms)
Not yet scheduled
Public Testnet
Not yet deployed

Live network metrics will be published here when a public testnet is running. Until then, no numbers are shown — because no honest numbers exist yet.

Development Log

One Developer. No Compromise.

Scalar Network
Solo Developer

Why one developer is a feature, not a bug.

Every project that has taken VC money has eventually made decisions in favour of its investors. This is not speculation — it is the mechanical consequence of capital with return expectations. Scalar was built alone because the only way to guarantee no one else's interests can shape the protocol is to ensure no one else has a financial claim on it.

Solo development means slower shipping. It also means no co-founder with a different vision, no investor board applying pressure on timelines, no marketing team adding "features" to make a pitch deck more compelling. Every design decision made on Scalar has been made for one reason: correctness.

I have no intention of introducing a team. When this ships, it will ship because the mathematics holds — not because a funding runway forced a launch.

What Scalar Will Never Do

Accept venture capital or enter into funding arrangements that create financial obligations to investors
Build surveillance features, compliance backdoors, or any mechanism that compromises transaction privacy
Alter the maximum supply or introduce inflationary mechanisms through governance or any other means
Launch prematurely because of timeline pressure, funding deadlines, or market conditions
Introduce trusted components, privileged keys, or administrative backdoors into the protocol

How It Got Here.

From a first-principles idea to an audited specification in under 60 days. Every version existed because the previous one had a flaw worth fixing.

Version numbers reflect specification revisions, not software releases. Each one represents a deliberate decision to get something right before moving forward.

Part I — Specification Journey
Origin — 12 April 2026

The Idea: First Principles

Not a feature request. Not an improvement on an existing chain. The starting point was a question asked from scratch: what would a monetary network look like if you refused to inherit the fundamental assumptions that make every current network weak? The answer required building something 180 degrees different from the majority of existing decentralised projects.

Original name Swarm Kinetic Network
V1 — 14 April 2026

The Monetary Foundation

The first version established the core monetary model. The challenge was designing a supply schedule that allowed large participants to accumulate value without monopolising the network against ordinary users. The answer was a psychologically calibrated supply ceiling and a decade-long maturation window to ensure early stability rather than early speculation.

Discarded Standard decentralisation-only framing. Replaced with a high-grade deflationary instrument with structural monopoly resistance.
Code Architecture design phase — balancing network capacity and participant space.
V2 — 19 April 2026

The Liquidity Problem

A serious flaw emerged: if transaction fees were burned, rational participants would stop transacting and simply hold. A network where no one transacts is a dead network. The solution was a two-phase monetary evolution — an initial passive deflation phase followed by a permanent fixed supply phase — keeping the network alive by volume rather than by burning.

Discarded Fee-burning mechanism entirely. All external third-party verification dependencies removed.
Code Autonomous network capacity expansion logic and network defence against adversarial actors.
V3 — 26 April 2026

No Free Lunch, No Founder Advantage

The initial asset distribution model was unfair. Free airdrops at launch reward speculators, not participants. The decision was made to distribute assets purely based on demonstrated participation — earned by doing, not by arriving early. At the same time, the maximum supply was locked permanently. And the founder allocation was eliminated entirely.

Discarded Launch airdrops and all founder token allocations. Both removed without replacement.
Code Core software split into independent modules: cryptography, networking, and wallet — each isolated from the others.
V5 — 1 May 2026

Hardware Should Not Determine Power

The hardware requirements were too high for true decentralisation. But reducing them naively creates a different problem: low-cost attackers. The resolution was elegant — make attacking the network require so much investment that rational attackers have more to lose by attacking than by participating honestly. Power is measured by demonstrated commitment to the network, not by computing power owned.

Discarded Hardware tier classifications. Speed-of-response as a transaction tiebreaker. Both replaced by time-commitment scoring.
Code Node architecture, governance structure, and wallet design fully mapped and completed.
V6 — 3 May 2026

A Synchronisation Flaw That Could Split the Network

A critical vulnerability was discovered: the method by which nodes synchronised their view of the network contained an internal arithmetic contradiction. Under certain conditions, different nodes could reach different conclusions — not from an attack, but from the design itself. The entire synchronisation method was replaced with one that is locally computed, deterministically bounded, and mutually verifiable without any bias.

Discarded The entire previous network synchronisation system and all its fractional calculation logic. Removed completely.
Code Network propagation layer fully rewritten and transitioned to the new synchronisation model.
V7 — 4 May 2026

Applications Must Not Touch the Core

Any future application built on top of Scalar — wallets, tools, integrations — could, if carelessly designed, modify or weaken the core protocol layer. The protocol and the application layer were formally and permanently separated. Third-party developers can build on Scalar without ever being able to touch its foundation.

Discarded Remaining state data from the old synchronisation model permanently purged.
Code Application layer framework successfully added to the system as a fully isolated layer.
V8 — 4 May 2026

Keys Must Resist Industrial Attack

The key derivation system — how access credentials are generated from a passphrase was vulnerable to brute-force attacks using high-performance hardware at scale. The system was replaced with one where the cost of attacking scales with the attacker's ambition. The more attempts an adversary makes, the more it costs them in a way that cannot be parallelised or accelerated by throwing more hardware at the problem.

Discarded Previous key derivation system, considered obsolete under the updated threat model.
Code 576 system test checkpoints passed with a clean result. Advanced application module development begins.
V9 — 7 May 2026

Time Cannot Be the Arbiter

Using wall-clock time to determine network period transitions created an attack surface: an adversary with control over timestamps could manipulate the network's sense of when one period ends and another begins. Period transitions were redesigned around an internally verifiable reference that cannot be manipulated by any external party. The historical data storage system was also simplified, and a minimal emergency signal was added for nodes that become temporarily disconnected.

Discarded Multi-layer data filtering, duplicate ownership in history records, and rigid percentage-based fee distribution.
Code All utility features and client application layer (phases 1–3) completed.
V10 — 10 May 2026

Consolidation: Smaller, Faster, Cleaner

A large consolidation pass. Communication pathways between nodes were over-engineered and inefficient. The authentication method in use was consuming more space than the security requirements justified. The governance decision process had accumulated unnecessary complexity. Everything was stripped back to the minimum that still satisfies the security requirements — nothing more.

Discarded Over-complex communication routes, previous authentication standard, and convoluted governance rule logic.
Code Public transparency audit module added. Test suite expanded toward 758 checkpoints.
V11.1-FINAL — 13 May 2026

External Audit: Four Findings, All Resolved

An independent cryptographic audit identified four vulnerabilities in the specification. Three were identified, reproduced, and closed at the implementation level before this version was finalised. The fourth requires live network conditions to evaluate and remains open pending public testnet deployment. The specification is now the single authoritative document for all further implementation.

Discarded Unlimited governance rights for the lowest-tier participants. Removed and replaced with capped influence proportional to proven contribution.
Code All audit recommendations implemented. Synchronisation and transaction finalisation testing in progress.
17 May 2026

Specification Consolidated — One Document, No Version

The specification document was stripped of version numbers, release labels, historical change notes, and any language implying a previously active network or existing users. A procedure was established: audit findings are absorbed into the document text rather than appended as amendments, and the implementation follows the document — not the reverse. What remains is one clean document that serves as the genesis reference for the first implementation of Scalar.

Discarded Version numbers, release labels, historical changelogs, and all language implying prior network activity.
Established Single specification document with no version. Findings absorbed into text. Code follows document — always.
18 May 2026

Code Aligned to Specification

A full audit of the repository against the consolidated specification identified nine points where the implementation had drifted from the document. All nine were corrected. Two annotation errors in the specification were also found and fixed. Every constant that the protocol treats as permanent now lives in a single authoritative location — no module may define its own copy. All 1,400+ unit tests pass against the aligned codebase.

Result 9 code discrepancies corrected. 2 specification annotations fixed. 1,400+ unit tests passing. Single authoritative constant source established across all modules.
20 May 2026

Optimisation Blueprint — Efficiency, Finality, and Throughput

A network-wide improvement plan was formalised targeting the three primary performance dimensions without altering the protocol's foundational constraints. Transaction data efficiency can be increased by up to 75%, finality latency reduced by over 99%, and total network throughput lifted by up to 100×. Selected supporting components are now entering a dedicated security‑research phase before integration approval.

Established Comprehensive optimisation blueprint for data efficiency, finality, and throughput. Security research phase initiated for components requiring further analysis
1 JUNE 2026

Integrity Edition — Internal Consistency Achieved

A full-spectrum audit revealed that the specification contained statements it did not enforce and formulas it could not fully define. Principles were declared at the top of the document and silently violated lower down. Some symbols used in critical distribution calculations had never been assigned a definition — meaning two independent implementations could produce divergent results with no way to determine which was correct. The document has now been brought into alignment with itself. Every declared prohibition is enforced. Every symbol is defined. Every procedure handles its edge cases. The specification is no longer a document that mostly means what it says — it means exactly what it says, all the way through.

Discarded The last remaining constructions that contradicted the protocol's own stated principles; a security parameter with mathematically trivial breakage; undefined symbols in distribution formulas; procedures without edge-case resolution; circular dependencies in the operational sequence.
Established Thirteen written, justified technical decisions; complete formal symbol definitions for all distribution formulas; deterministic emergency governance eligibility; a circularity-free operational sequence; a zero-byte security hardening that holds against commodity hardware attack.
Part II — What Comes Next

No calendar dates. It ships when it is right.

Current — Hardening

Testing to Destruction

The specification is complete and the local implementation is functional. The current work is hardening: running the system under adversarial conditions, expanding the test suite, validating that every security property holds not just in theory but under real pressure. Nothing ships until this phase produces no surprises.

Planned — Genesis Nodes

Independent Infrastructure

Establishing the parameters for independent participants to operate network nodes. No central operator. No foundation-controlled majority. The network exists when others run it, not before.

Planned — Applications

Wallet and Tooling

User-facing software built on the isolated application layer — the one that cannot touch the core protocol by design. Privacy-first from the interface down.

Target — Mainnet

When It Is Ready

Public launch when all prior phases pass their exit criteria. No date is set. No date will be set until the network has proven it can withstand what the real world will do to it. A premature launch is not a launch — it is a liability.

Keep This Independent

No venture capital means no investor pressure on timelines, no governance rights sold to funds, and no obligation to deliver returns. It also means development depends entirely on people who believe this work matters.

Where Funds Go

Server infrastructure for testnet nodes and development environments
Developer time — the only resource Scalar actually runs on
Security auditing and cryptographic review as the protocol matures
Documentation and tooling to support independent node operators
Nothing else. No marketing spend, no conference presence, no PR campaigns.

Frequently Asked

Direct answers. No spin.

Making the code public before the protocol is finished invites forks that ship broken versions, dilutes the project's identity, and creates a surface for criticism of work-in-progress internals that will change before launch. The code will be open when the protocol is ready to be open. The terminal output shown here is evidence of a working system, not a marketing claim. Development activity is documented above as a standalone record — not linked to any account or repository.
The specification journey above is real and documented with dates. Ten versions in under 60 days, each one fixing a specific flaw in the previous. An independent audit was conducted. The implementation runs in a local development environment. There is no live network yet — and this page says so plainly, because honesty at this stage costs nothing and deception costs everything. If the evidence here is not sufficient for you, do not contribute. That is the correct response.
One developer. I'm not going to publish my identity at this stage. Pseudonymous development is a deliberate choice — the protocol's validity should not depend on who built it. Bitcoin's creator never verified their identity either. The work either holds up mathematically or it does not. When the code is open, anyone can verify it. Until then, the testnet output is the available evidence.
Venture capital is not free money. It is money with strings attached — return expectations, board influence, timeline pressure, and often a requirement to build things investors understand and can exit from. Every VC-backed crypto project has, at some point, made decisions that served investor interests over protocol integrity. Scalar is not available for that deal. No investor will ever have governance influence over this protocol.
No. Donations are development support only. There are no tokens promised, no whitelist positions, no "early supporter" allocations, no equity, and no future claim of any kind. The founder has no initial allocation either — no pre-mine, no reserved stake, no privileged genesis access. This is not a token presale operating with extra steps. Anyone who tells you donating here comes with a token promise is lying — including me, should I ever say that. Contribute because you want the work to exist. For no other reason.
If development stops, the testnet stops. Any donated funds would have already been spent on the development work they supported. There is no treasury to recover, no refund mechanism, and no guarantee of any kind. This is why the donation section warns explicitly that contributions should only be made without expectation of return. If continuity is a requirement for you, this is not the right project to support at this stage.
When it is ready. No date is set, no date is implied. The roadmap shows phases, not timelines. Each phase exits when it meets its criteria, not when a date arrives. Anyone telling you a launch date for Scalar is guessing or making it up. The only honest answer is: when the work is done.