01 DEV NOTE / 001
I am building a new kind of computer system on top of Solana—one where applications, agents, storage, compute, licenses, and other parts of the system can be owned, exchanged, and recombined by the people who use them.
A COMPUTER IS A SET OF PROMISES
Every piece of software makes promises. It promises to open tomorrow, to leave your files where you put them, to ask before reaching into the rest of the machine and to remain useful after the company behind it changes direction.
Most of those promises are informal. They live in product pages, account policies and interfaces that can be rewritten without the software asking you. We are told that we own our tools, but what we usually own is temporary access to somebody else's decision.
I want Kernum to make those promises concrete. A program should arrive with an identity, a verifiable body of code, a visible set of permissions and a clear statement of the right you acquired. The computer should be able to check those facts without trusting the storefront that introduced you to the program.
02 THE IDEA
Kernum is a local computer environment built from software parts that can be verified, exchanged and replaced.
The easiest way to understand Kernum is to imagine that applications are not sealed products. They are components. Each component performs a limited job and declares the capabilities it needs: perhaps reading one directory, writing one kind of document, contacting a specific network service or using a fixed amount of compute.
Kernum sits between the component and the machine. Before anything runs, it checks which code was published, whether the downloaded bytes match that publication, what authority the component requested and whether the user has the right to launch it.
This does not make software harmless. It makes the relationship inspectable. Security begins when the machine can say exactly what it is about to trust.
THE KERNEL, NOT THE KINGDOM
I do not want to build another platform that must own every part of the experience. Kernum should be small at the center and replaceable everywhere else. The runtime enforces a few durable rules; interfaces, stores, agents and tools can compete around it.
If somebody builds a better catalog, you should be able to use it. If a developer disappears, a valid component should not disappear with their website. If Kernum itself stops being the best interface, the records and artifacts should remain usable by another implementation.
A system is genuinely open only when leaving it is possible.
FOUR QUESTIONS FOR EVERY COMPONENT
Before Kernum runs a component, the system should be able to answer four questions without marketing language:
- What is it? A stable component identity and an exact fingerprint of the published code.
- Who is responsible for it? A publisher whose changes can be followed across versions.
- What can it touch? An explicit capability list that the local runtime can enforce.
- Why may this machine run it? A license or grant with visible terms, duration and ownership.
These answers do not need to make the interface complicated. The technical record can remain precise while the user sees a simple decision: this tool wants these abilities, for this reason, under these terms.
03 WHY SOLANA
Some facts need to survive outside a single server: who published a component, which code fingerprint belongs to a version, whether a listing is active and whether an address holds a valid license. Solana gives those facts a shared place to live and a direct way to settle payment.
That is the boundary. Kernum does not put normal computation, private files or a user's daily activity onchain. The chain records the minimum shared state needed for independent parties to agree. The machine keeps the private work local.
This separation matters. A blockchain is useful as common memory. It is a poor substitute for the computer on your desk.
THE MARKET IS NOT THE PRODUCT
Kernum includes prices, listings and licenses because developers need a durable way to distribute work and users need a clear record of what they acquired. But the market is a mechanism, not the reason for the system to exist.
A component with no users is not made useful by trading it. A license is meaningful only when it unlocks software worth keeping. The quality of Kernum should be measured by whether a person can understand a component, trust its boundaries and continue using legitimate software—not by how much activity appears on a ledger.
WHAT MUST REMAIN OUTSIDE THE MARKET
The computer's owner is not inventory. Identity, private keys, personal files, recovery rights and basic access to the machine must never become tradable components. No license should grant hidden control, and no installed tool should be able to quietly expand its own authority.
Ownership without boundaries becomes another form of capture. Kernum is meant to give the user leverage, not create a more elaborate landlord.
04 WHAT EXISTS NOW
Today, Kernum is an implementation rather than a promise deck. The repository contains a local component runtime, manifest validation, cryptographic artifact checks, capability enforcement, installation storage and a browser interface for exploring and acquiring components.
It also contains an Anchor program for Solana. The program can register component code hashes, create SOL-denominated listings, receive purchases and record time-limited licenses. Automated tests cover the local installation path, modified-artifact rejection, license decisions and the construction of marketplace transactions.
The public interface is still a demonstration. Its catalog is made of samples. The onchain program has not been presented as audited production infrastructure. Isolation, recovery, publisher reputation, upgrades and a complete public deployment still require serious work.
THE NEXT USEFUL MILESTONE
The next milestone is not “more features.” It is one honest journey from beginning to end: a developer publishes a real component; a user reads its permissions; the user acquires a license; Kernum verifies the exact artifact; the runtime launches it with only the authority it requested.
When that path works, it becomes a foundation. Until it works, everything larger is only vocabulary.
WHY THE SOURCE IS BESIDE THIS NOTE
I could describe Kernum with diagrams and future scenarios, but the code is a better boundary around the claim. The source browser beside this note is not decoration. It shows the runtime and Solana implementation that exist now, including the unfinished edges.
I am building Kernum in public because the project asks users to inspect software before trusting it. The project itself should accept the same standard.
LOCAL-FIRSTVERIFIABLE SOFTWAREEXPLICIT CAPABILITIESPORTABLE RIGHTSOPEN SOURCE
— Kernum, development note 001 / October 2026