Introducing Salvor Labs, Salvor+, and what's next for $SALVOR

When I introduced Salvor a few weeks ago, I spent most of that announcement explaining how a single /clear command cost me three days of accumulated engineering knowledge. The code was fine. What disappeared was the understanding we'd developed around it.

That experience eventually became Salvor: an open-source, repo-native knowledge layer designed to preserve what a project learns, not just what an AI agent happens to remember.

At the time, Salvor was largely a personal project. It had grown out of workflows I was building for myself, and problems that developer friends and I kept running into as we pushed AI-assisted development further. Different models, different tools, different projects, but the same recurring problem: valuable knowledge was being learned, lost, and rediscovered over and over again.

I originally built Salvor to solve that problem for developers. But the more I've worked on it, the clearer it's become that the underlying problem isn't unique to software engineering.

Research, design, product development, business operations, autonomous agents, collaborative teams — all of these involve accumulating knowledge over time. And all of them stand to benefit from AI systems that can carry forward what has already been learned instead of repeatedly starting from scratch.

That's a considerably bigger problem space than the one I set out to address.

It's also not something I want to keep treating as a side project living under my personal GitHub account.

Introducing Salvor Labs

Today I'm formally introducing Salvor Labs, the organization that will steward Salvor's open-source development while building an expanded ecosystem of AI products and services around it. Salvor Labs has an official public telegram channel for users to engage with the team and ask questions more easily. Join today: https://t.me/SalvorLabs, hope to see you there!

As part of that transition, Salvor has officially moved from dwasyluk/Salvor to its new home:

https://github.com/SalvorLabs/Salvor

This is more than moving a repository into an organization.

I want Salvor to grow beyond my own development workflows, beyond a handful of developers, and eventually beyond Git-based software projects altogether. That means building things the original open-source protocol was never intended to provide on its own: hosted infrastructure, managed services, integrations, advanced tooling, and ways for people and agents to benefit from persistent project knowledge without having to manage all of the underlying machinery themselves.

It also means having a sustainable way to fund that work, compensate contributors, and invest in development that may not always make sense as a purely open-source undertaking.

That is what Salvor Labs exists to do; and it brings us to an important distinction in how Salvor will evolve.

Salvor OS and Salvor+: two sides of the same ecosystem

Going forward, there will be two complementary branches of Salvor's development.

• Salvor OS: is the open-source foundation you already know.

The repo-native engineering knowledge protocol remains free, MIT-licensed, and vendor-agnostic. Its knowledge belongs to your project, its decisions and rules are inspectable, and it doesn't require an account, a subscription, or a cryptocurrency token to use.

I believe that foundation should remain open. It's how Salvor started, and I think collaborative development is how the underlying protocol will become considerably better than anything I could design on my own.

• Salvor+: the next step, reveals more of the utility behind the $SALVOR token and its many holder benefits.

Salvor+ will be a privately developed, commercially supported extension of Salvor OS, maintained by Salvor Labs. It will incorporate improvements from the open-source foundation while introducing advanced capabilities, proprietary technology, and managed products and services that won't necessarily be made available in the public repository.

Improvements developed by Labs can still flow back into Salvor OS where appropriate. But not everything Labs builds will be open source, and I want to be upfront about that distinction from the beginning.

What's cooking with Salvor+?

Among the first things we're working toward is a Salvor+ MCP service, extending the value of Salvor's persistent knowledge layer into a much broader range of AI tools, agents, workflows, and eventually environments that don't revolve around Git repositories at all.

One area I'm particularly excited about is what this could mean for multi-agent systems and agentic coding swarms.

We're moving toward workflows where multiple specialized agents operate in parallel, each tackling a different part of a problem. One agent works on the backend, another handles the frontend, others investigate bugs, write tests, review security, or explore competing approaches.

That's powerful. But there's a problem lurking underneath it.

Each of those agents has its own context window. They may be working on the same project, but that doesn't automatically mean they're working from the same understanding of it.

Think about what happens when you have six agents working independently and only one of them knows why a particular architectural decision was made, or that an approach the others are considering was already tested and rejected.

You've scaled up the workforce without necessarily scaling up the knowledge.

More agents shouldn't mean more opportunities to repeat the same mistakes.

Salvor OS already addresses part of that problem by preserving reviewed engineering knowledge in the repository, including the decisions, failed approaches, and constraints that should survive across sessions and branches.

What we're bulding through the Salvor+ MCP is a way to make that governed knowledge more readily accessible to independent agents, across different tools and environments, without each one having to reconstruct the project's history for itself.

Imagine a coding swarm where every agent can consult the same approved architectural decisions, known failure modes, domain knowledge, and project constraints before doing its work. New findings can be captured and reviewed, with the useful knowledge surviving long after the individual agents have finished their assignments.

That's not the same as orchestrating the swarm. Task delegation, live agent-to-agent communication, and resolving conflicting code changes remain separate problems.

Orchestration determines which agent does what. Salvor's job is to help preserve what the project knows, so those agents don't have to keep learning the same lessons independently.

And there's no reason that pattern needs to stop at software development.

Imagine bringing an established body of project knowledge into different AI environments, allowing agents to retrieve the decisions and reasoning they need, and continue building on that knowledge without being tied to one model, tool, or machine.

There's a lot we can do here. Some of it is a fairly natural extension of what Salvor already does. Some of it requires new infrastructure and capabilities that we're now developing through Labs.

And unlike the open-source foundation, access to Salvor+'s premium ecosystem will be built around $SALVOR.

That's where the token starts taking on a much more meaningful role.

$SALVOR: from contributor rewards to ecosystem utility

When I introduced $SALVOR, its role was purely to reward people contributing meaningful work to Salvor OS. Bounties are denominated in USD and paid in $SALVOR at the applicable market price.

That isn't changing. But rewarding contributors is only half an economy. If nobody has a reason to acquire, use, or hold the token, we've created an incentive mechanism without meaningful demand.

I don't think arbitrary token mechanics solve that problem. I'd rather build products people actually want and make $SALVOR useful within them.

**Salvor OS stays free. Salvor+ is where $SALVOR becomes the key to premium services, expanded capabilities, and ecosystem benefits.**

We're developing five initial utility directions:

1. Agent-native payments

Give your AI agents a $SALVOR budget. Let them purchase premium context, retrieval, indexing, and tools as they work.

Through Salvor+ MCP and Solana's x402 payment model, independently running agents — including entire coding swarms — could pay for exactly the services they need, within user-defined spending limits.

2. Community-powered bounties

Want a Salvor feature sooner? Back its bounty with $SALVOR and help fund the contributor who ships it.

Users and organizations could sponsor approved open-source development directly, with potential matching support from Labs.

3. SALVOR capacity locking

Lock $SALVOR, retain your tokens, and unlock ongoing Salvor+ capacity and priority access.

We're exploring recurring premium MCP/API capacity, higher limits, and enhanced access for committed holders — particularly useful for teams running multiple agents in parallel.

4. The SALVOR Advantage

Pay with $SALVOR for preferred pricing, access, and exclusive benefits across Salvor Labs products and services - as much as 50% of of Salvor Labs products and services as compared to paying with any other asset.

From premium MCP capabilities to APIs, plugins, and future offerings, token users will have meaningful advantages tied to services they actually use.

5. Salvor Builder benefits

Build Salvor OS, earn $SALVOR, and keep benefiting from the ecosystem you're helping create.

Verified contributors who retain or commit earned tokens could unlock premium tools, research credits, previews, and additional Labs benefits.

These are development directions, not features I'm claiming are already available. We'll get into the mechanics in a separate article.

The common thread is simple: service usage creates reasons to spend $SALVOR, premium access creates reasons to hold or lock it, and open-source development creates reasons to earn it.

That's the ecosystem we're working toward.

Building an ecosystem that can sustain itself

There's another important piece to this.

Revenue generated by Salvor Labs — whether through conventional payments, $SALVOR, or other commercial arrangements — gives us the flexibility to support different parts of the ecosystem.

That includes operating infrastructure, developing new products, investing in research, replenishing the open-source contributor fund, and potentially acquiring or burning tokens when it makes sense to do so.

I'm deliberately not announcing fixed percentages, burn schedules, or elaborate staking economics today. Those decisions need to be made around actual products, usage, and operating costs, not hypothetical revenue models.

The broader objective is simple.

As Salvor Labs becomes more useful, its products create reasons to acquire and use $SALVOR. Revenue from those products can help fund further development, including improvements to Salvor OS. Contributors build more capabilities, users gain more value, and the ecosystem has a way to continue growing.

That's the kind of economic relationship I want to establish.

One that has a reason to exist because the underlying technology is useful.

What's next

Development of Salvor+ is underway, with the premium MCP service among our first priorities. I'm particularly interested in what a persistent, governed knowledge layer could do for agent swarms: letting independent agents inherit the project's reasoning instead of rediscovering it.

Later this week, I'll have another article going deeper into Salvor+ and the five initial $SALVOR utility directions, including agent-native payments, premium access, and community-funded development.

We're also putting more effort into showing, not just explaining- that means MARKETING. Expect additional AMAs covering Salvor Labs, short videos and visuals on what Salvor OS does today and what's coming in Salvor+, setup and quick-start demos, and simple demonstrations of persistent project knowledge surviving a switch between AI vendors.

Ultimately, I want working products and real usage to test these ideas against. That's what matters.

For anyone who only wants the open-source protocol, nothing about this changes why Salvor exists. You can still use it, improve it, disagree with how I've designed it, and contribute to its development without ever touching the token.

For developers, teams, and AI users who want more advanced capabilities, Salvor Labs will be building a commercial ecosystem where $SALVOR isn't incidental — it's how you participate in and unlock the premium experience.

And for those who have supported Salvor early, whether by writing code, testing it, sharing feedback, or choosing to hold $SALVOR, I want that early participation to have a meaningful role in what we're building next.

A few weeks ago I was announcing a beta that grew out of one very frustrating engineering problem.

Today I'm announcing the organization and direction intended to take that work much further.

There's still a lot to build. I wouldn't be doing this if I didn't think the opportunity was considerably larger than what we have today.

Salvor OS is the foundation. Salvor+ extends what's possible. Salvor Labs is how we're building the ecosystem around them.

And $SALVOR is going to be a much bigger part of that story.

— Dan

• Salvor Labs: https://SalvorLabs.org
• Follow SalvorLabsAI: https://x.com/SalvorLabsAI
• SalvorLabs Telegram: https://t.me/SalvorLabs
• Salvor OS website: https://SalvorKnows.dev
• Salvor OS GitHub: https://github.com/SalvorLabs/Salvor