Neova Foundation: Fueling Innovation
The Neova Foundation is here to accelerate the growth of developers in our ecosystem. This independent organization will provide essential resources, mentorship, and support to help new builders thrive.
By joining the Foundation, developers gain access to cutting-edge tools, expert guidance, and visibility, both within Neova and across the broader blockchain space. We’re committed to fostering innovation and empowering creators to take their projects to the next level.
The Neova Foundation is the key to shaping the future of decentralized technology. and we started it :
Open-source contribution
Private IPFS networks are common, and they are stuck on the same three gaps. Announce is unreliable. The public DHT cannot be used. The swarm key isolates a network and then treats every holder of that key as identical. Nothing in the standard stack makes the read fast once the right node is finally known.
Neova built NeoDrive on those constraints, then published the remedy with the IPFS community. The work is funded by the IPFS Foundation. The code and the specifications are open. The first production user is our own swarm.
Two public threads carry the design:
Private Indexer for swarm-key networks — April 2026
Swarm Accelerator — May 2026
The grant itself, Swarm Keys v2, is the control plane those two components plug into: authenticated membership, key lifecycle, and roles, without a fork of IPFS.
Why this is a foundation project
The public network is well served. Private networks are where companies actually try to run IPFS, and where the current tools run out. Neova needed a swarm that a drive can sit on: nodes you can name, a directory you can query, a read path that meets a consumer latency, and a way to remove one machine without rekeying every other machine.
The foundation needed a real deployment, with users, files, and operators, rather than another sketch of a private network. The grant connects the two. Neova brings the product. The specification, the Go reference implementation, and the operating guides go back to anyone running a swarm key.
Kubo stays Kubo. libp2p stays libp2p. The new pieces are sidecars and HTTP. You can run them, and you can turn them off, without replacing the node.
Three pieces, one swarm
The indexer and the accelerator are in service on the network behind NeoDrive. Swarm Keys v2 is the membership layer specified and implemented so that “holds the swarm key” stops being the only admission rule. Production isolation today is swarm key v1. v2 is how that isolation grows up into governance.
Swarm Keys v2
A v1 swarm key is a shared secret. Present it and you are in, with the same standing as every other node. Lose a laptop that had the key, and the honest options are all bad: leave it trusted, or rotate the secret for the entire network and reconnect everyone.
Swarm Keys v2 replaces that binary with a signed credential and a policy the node enforces locally.
The key is signed, and it carries facts. Network id, expiration, and role travel with the credential. A node can show which swarm it belongs to, and which job it is allowed to perform.
Joining is an authentication step. The sidecar checks the signature, the expiry, and the revocation state when a node comes in. Holding an old copy of a secret is no longer sufficient.
Lifecycle is explicit. Operators can issue, rotate, expire, and revoke. Revocation is a signed list. New connections honor it immediately. Existing sessions follow a defined rule, immediate deny or graceful expiry, chosen by policy. The swarm does not reboot to eject one node.
Roles are visible in behavior. A storage node can exchange blocks and stay out of policy updates. A gateway or accelerator can be limited to the namespaces it serves. An operator node can issue, rotate, and revoke. A zone can be declared on the credential, so a deployment that must keep data in a region has a hook to do it.
v1 keeps working during the move. If v2 policy is absent or deliberately off, the node runs in a defined v1-compatible mode. There is no silent fallback and no surprise cutover.
The sidecar reads signed keys and policy from local state, from an HTTP endpoint, or from decentralized storage. It does not require a service that stays up for the node to keep running. Enable it or disable it independently of the Kubo process.
What the grant delivers
Deliverable
What it is
Specification
Signed keys, admission, rotation, revocation, v1 compatibility
Reference implementation
Go, verification and enforcement at swarm join
CLI
Generate, sign, rotate, expire, revoke, assign a role
Integrations
Private Indexer and Swarm Accelerator, with testable role policies
Documentation
Architecture, threat assumptions, deployment, migration from v1
License: MIT or Apache-2.0. Out of scope, by design: changes to IPFS core, changes to libp2p transport or encryption, and features of the public network. Swarm Keys v2 is an optional control plane. It is supposed to stay optional.
What you can do with it
If you use NeoDrive, this is why the network under the drive has a name, a directory, and a read gateway, all specified in public. The product benefits from the research. The research is not trapped inside the product.
If you run another swarm-key network — an enterprise cluster, a partner storage fabric, a private gateway — the same three pieces are the toolkit. Start from the forum threads, the specification, and the Go reference. Neova’s swarm is the proving deployment. The protocol is for the operators who recognized the same walls.
Last updated