Licensed to stay yours
Neutron left the GPL on 15 August 2026. Two purpose-built licenses replace it: the Neutron Public License 1.0 for the kernel and control plane, and the Neutron Sovereign Application License 1.0 for apps. A source license protects the code you can read. These also protect the deployment — who may install what on your canister, and on what terms an app reaches a capability.
The upgrade path is a license condition
Anyone who ships a kernel, installer, or provisioner has to leave you able to inspect what is installed, select a complete package set — modified, unsigned, unlisted, private, differently governed — compile it, and install the resulting Wasm without a deployment-specific approval or secret. A provider who cannot hand you that path may not convey the system for a user deployment, or represent it as sovereign.
All apps are equal
A capability is infrastructure, not a favour. Every generally useful app-facing function has to reach independently developed, similarly situated applications on materially equal eligibility, interfaces, review, fees, and admission rules. Identity may carry consent, isolation, routing, and resource ownership — it may not stand in for authorship, publisher, signature source, registry listing, affiliation, or competition.
The kernel cannot sherlock you
Ordinary product functionality stays in a separately identifiable app the owner can remove. The kernel may not absorb a favoured product or a material competing feature, reserve a capability for one, or relabel a product as infrastructure. Where it does hand an app a default or exclusive role, that role must be defined, inspectable, and replaceable by any compatible app — and a kernel author competes through an ordinary app under the rules it wrote.
No daoization
A DAO, a nervous system, a registry, a maintainer, or a signer may publish, vote on, recommend, sell, support, or discontinue whatever it likes. What none of them may do is make your upgrade path depend on a proposal, a vote, a co-signature, an allowlist, a secret, or a continuing service. Governance over packages is not authority over a deployed user's computer.
Copyleft that stops at your app
Modified covered software stays under the NPL, with complete corresponding source and the installation information needed to build and install it — at no charge, for as long as that version is provided and three years after. The assembly exception is the counterweight: compiling your app into the kernel's single actor does not make your app covered software. It keeps its own license.
A community-sovereign ecosystem, one Neutron at a time
Neutron apps ship under the Sovereign Application License: operating one for another person is permitted only on a qualifying sovereign system — a deployment that actually keeps the guarantees above. Your own use of your own Neutron is protected unconditionally. A sovereign user never has to audit a provider, register, publish hashes, or keep records to stay licensed.
The NPL is a reciprocal source-and-sovereignty license. It is deliberately not GPL-compatible and is not represented as OSI-approved: the deployment and kernel-neutrality conditions are precisely the further restrictions those licenses forbid. Releases previously conveyed under GPLv3 keep their GPL rights.
One canister, one owner, many apps
A Neutron instance is a single Internet Computer canister that belongs to exactly one human. It runs the kernel, serves the UI, stores every installed app’s assets and state, and upgrades its own code. There is no account system and no shared server behind it.
Ownership model →Apps compile into your OS
Installing an app is an operating-system upgrade, not a link to someone else’s service. The kernel merges every installed backend into one Motoko actor, compiles it in your browser, and asks the canister to upgrade itself.
Browser compilation →Authority is declared, not assumed
App code cannot construct actors, attach cycles, touch raw stable memory, or forge certified data. Everything an app can reach is a declared capability, checked when it is packaged, when it is compiled, and again at every runtime call.
Capability system →App capabilities
Every one of these is a declared capability: bounded in the manifest, disclosed at install, brokered by the kernel, and revocable from Settings.
Transferable keys the protocol never sees
A quorum of the subnet contributes shares, the key exists only at the instant they combine, and it arrives encrypted to a transport key that only the browser can open — no single node, no kernel relaying it, and no canister state ever learns it. The app that asked does hold it; that is what makes it useful, and nothing outside its own slot can reach it. Derivation is deterministic, so everyone your canister authorises derives the identical key: passing access to another identity is a change of policy, not a handover of key material, with nothing re-encrypted and nobody needing to be online. Today that carries a key between your own identities; the same mechanism reaches anyone you name, and you can encrypt to an identity that has never held a key at all.
vetKeys →One agent, every app’s tools
Apps expose their functions as typed, schema-validated tools. An agent in the browser layer can discover and call tools across every installed app, so one request moves through your notes, your wallet, and your calendar without any of them ever integrating with each other. A backend agent does the same inside the canister, composing other apps’ exported functions as ordinary typed calls. Every reach across an app boundary is the owner’s to approve.
Agent Mode →The subnet signs as one
Your canister can produce ECDSA, BIP340, or Ed25519 signatures without ever holding a private key. The kernel owns the threshold key name, the derivation path, and the digest; your app gets two verbs — look up the public key, sign a bounded assertion. No raw signer, no transaction encoder, no retry.
Chain-key signing →Call any web API from your backend
Your Motoko backend talks to real web services directly — GET and POST, no oracle, no relay, no server of your own in the middle. Which hosts it may reach is fixed at install: URL prefix, method subset, header allowlist, size bounds. At runtime your app supplies a path, a query, and a body — never a different host, and never a cycle amount.
HTTPS outcalls →Assets that trace back to the root key
Every file your app publishes is provable back to a single key. Your canister commits a 32-byte hash-tree root with certified_data_set; each round the subnet’s nodes threshold-sign the state tree holding it, and the NNS chains that subnet key back to the ICP root key fixed at genesis. A response ships the file’s witness alongside that certificate, so a client verifies against one key it already has and knows the bytes came from this exact canister — no CDN, no origin server, nothing in between to trust. Absence is provable too: a missing file cannot be faked into existence.
HTTP and assets →Peer to peer protocols
Senders push, so subscribers never poll — no timer quietly burning cycles asking whether anything happened yet. And the initiator pays: an inter-canister route publishes a static cycle floor, and a call that does not attach it traps before your handler runs. The payment is banked before any later admission check, so admitted work is funded by whoever asked for it. Your app can carry a public protocol without its balance being someone else’s to spend.
Public ingress →What happens when you install an app
Every install is one reviewed, journalled transaction against your own canister. Nothing is staged on someone else’s infrastructure, and nothing is promoted until the new code proves it is running.
- Unpack & validateThe browser decodes the .neutron archive and validates its manifest against a closed schema.
- DiscloseDeclared capabilities become kernel-attested permission facts, shown separately from the app's own unverified prose.
- Assemble & scanKernel plus every installed app plus the new one become a single Motoko actor; dangerous APIs hard-fail the compile.
- CompileA vendored Motoko compiler runs in your browser tab and produces the Wasm and Candid.
- Stage & upgradeAssets stage under a deployment id, a stable journal is written, and the canister upgrades itself.
- Verify & commitOnly after the new actor reports the expected fingerprints does the kernel promote the registry, Candid, and web files.