Expand Sentinel, Don't Migrate it

I. Sovereignty is part of the product

Sentinel is not simply a dApp that happens to use a blockchain

The first question in this debate should be: what exactly has Sentinel built?

Sentinel's own documentation describes it as a Layer-1 peer-to-peer bandwidth marketplace built using the Cosmos SDK.

Its blockchain manages much more than token transfers.

The protocol contains native functionality around:

• nodes;

• providers;

• plans;

• subscriptions;

• leases;

• sessions;

• deposits;

• bandwidth payments;

• staking;

• governance;

• and protocol economics.

Sentinel's blockchain is therefore not merely infrastructure sitting underneath the dVPN product.

It is part of the dVPN protocol itself.

This matters because the Cosmos SDK allows Sentinel to design the blockchain around its own application.
It can create native modules specifically for decentralized bandwidth and modify the state machine as the product evolves.

Sentinel can decide:

• what constitutes a session;

• how node operators register;

• how providers interact with applications;

• how plans and subscriptions work;

• how bandwidth is settled;

• how network revenue is distributed;

• how staking works;

• how governance works;

• which transaction types exist;

• and how all these systems interact.

That degree of control is one of the main reasons application-specific blockchains exist.

Sentinel is approaching what may be the most consequential decision in its history.

The direction currently being discussed goes far beyond bringing P2P liquidity to Solana, supporting Solana wallets or allowing Solana users to purchase decentralized bandwidth.

It involves ending Sentinel as an independent Proof-of-Stake Layer 1 and rebuilding the protocol as an application on top of Solana.

We believe that would be a strategic mistake.

Not because Solana is a bad blockchain. Not because Sentinel should remain confined to Cosmos. And not because Sentinel's current architecture is perfect.

Our position is different:

Sentinel should expand into Solana and other ecosystems without migrating its canonical protocol away from its sovereign Layer 1.

Sentinel should integrate more chains, more payment systems, more wallets and more developers.
But the functions that define the decentralized bandwidth protocol itself should continue to operate on Sentinel.

Expansion increases Sentinel's reach, migration removes Sentinel's sovereignty: those two concepts should not be confused.

II. The security and infrastructure problems are real, but migration is not the only solution

Two arguments have repeatedly been raised in favor of migration:

1. vulnerabilities in the Cosmos SDK / CometBFT stack;

2. the lack of mature enterprise RPC infrastructure for Sentinel.

Both issues deserve serious attention and neither inherently requires shutting down Sentinel L1.

Cosmos SDK and CometBFT vulnerabilities must be patched, not used as a blanket argument against sovereignty

There have been real vulnerabilities in the Cosmos stack.

For example, security advisories have disclosed bugs capable of creating serious disruption, including potential chain halts.

Cosmos SDK disclosed a high-severity integer-overflow vulnerability affecting unpatched versions of its distribution module.

CometBFT has also disclosed vulnerabilities involving malicious peer behavior, malformed data structures and consensus behavior that could result in significant network disruption.

These are legitimate security concerns, but the normal response to vulnerabilities in critical software is:

1. responsible disclosure;

2. patching;

3. validator upgrades;

4. auditing;

5. monitoring;

6. hardening;

7. continuous maintenance.

It is not automatically to abandon the entire software architecture.

This distinction is particularly relevant because current Sentinel development already tracks newer Cosmos SDK and CometBFT releases containing patches for several important recent vulnerabilities.

This demonstrates that the appropriate response to a patchable vulnerability is to upgrade the protocol.

If the team believes there is a specific Cosmos SDK or CometBFT vulnerability that makes the Sentinel architecture fundamentally unsafe even after available fixes, that vulnerability should be clearly identified and explained to the community.

The relevant question is not:

“Has Cosmos software ever contained vulnerabilities?”

Of course it has.

The relevant question is:

“Which concrete vulnerability makes Sentinel's sovereign architecture unacceptably unsafe, and why can it not be solved through a normal software upgrade?”

Without a precise answer, security advisories are not sufficient justification for eliminating the chain.

Moving to Solana changes the level at which Sentinel can innovate

Sentinel could obviously build highly customized programs on Solana.
The point is not that smart contracts are incapable of sophisticated logic.

The difference is that Sentinel would no longer control the underlying execution environment.

Today, if Sentinel needs to change fundamental blockchain behavior, the protocol can evolve its own chain.

On Solana, Sentinel could change its programs, but it would operate inside rules determined by Solana's runtime and network.

If Sentinel ever required changes involving:

• runtime behavior;

• transaction architecture;

• native fee mechanics;

• account semantics;

• block-level limits;

• protocol-level cryptography;

• consensus behavior;

• or validator-level functionality,

those changes would no longer be under Sentinel's sole governance.

They would depend on the evolution of Solana itself.

That is not a criticism of Solana. It is the natural trade-off of deploying on a shared Layer 1.

But Sentinel should be very careful before voluntarily giving up the ability to shape its underlying protocol around the needs of decentralized bandwidth.

Existing architecture has replacement value, but sunk cost is not a strategy

Sentinel has spent years developing native blockchain logic specifically for its product.

Its current blockchain repository contains well over a thousand commits and years of accumulated engineering.

Migrating means that significant portions of this architecture would need to be redesigned around Solana's program and account model.

That huge engineering effort would compete directly with work on:

• node quality;

• VPN performance;

• censorship resistance;

• developer tooling;

• enterprise adoption;

• bandwidth verification;

• consumer UX;

• payments;

• AI-agent integrations;

• and protocol revenue.

Rebuilding functionality that already works should require a compelling architectural reason.

Greater ecosystem mindshare alone is not enough.

The RPC problem is being framed backwards

Another argument for migration is that Sentinel lacks the mature business and enterprise RPC market available on Solana.

That is true today in a commercial sense, but it should not be confused with a technical limitation of Sentinel.

Sentinel already operates public RPC, gRPC and API endpoints, while independent community operators provide additional reliable infrastructure. More importantly, nothing prevents anyone from running enterprise-grade RPC infrastructure on Sentinel with dedicated endpoints, redundancy, monitoring, DDoS protection, private access and contractual SLAs.

The fact that such a market is still relatively small mainly reflects the current level of demand.
When Sentinel usage grows and applications begin requiring guaranteed capacity and professional support, that demand creates an economic incentive for infrastructure providers to offer those services.

This is how an open infrastructure market should develop: demand attracts providers and competition.

Migrating the entire protocol because this secondary market has not yet matured would therefore confuse the current size of Sentinel's ecosystem with a limitation of its architecture.

There is also an important decentralization advantage in Sentinel's current model.

A Sentinel full node remains relatively accessible to operate: current recommendations are around an 8-core CPU, 32GB RAM, 500GB NVMe storage and a 1Gbps connection. Solana infrastructure is significantly more demanding, with current Agave recommendations calling for at least 256GB RAM for validators and 512GB or more for heavily indexed RPC nodes, alongside multiple high-performance NVMe drives and substantially higher bandwidth requirements.

That higher barrier makes professional infrastructure providers increasingly important and makes independent self-hosting less accessible.

For Sentinel, this matters because it is building privacy and censorship-resistant infrastructure.

A healthy RPC ecosystem should include professional providers when applications need enterprise guarantees, while preserving the possibility for developers, validators and independent operators to run their own infrastructure.

That combination is stronger than dependence on a small number of highly specialized gateways.

Enterprise-grade RPC and permissionless infrastructure are not mutually exclusive. Sentinel can have both.

The real question is therefore not:

“Why doesn't Sentinel already have the same enterprise RPC market as Solana?”

It is:

“How do we grow Sentinel usage so that a competitive professional RPC market emerges, while preserving the low barrier to independent infrastructure?”

III. The migration creates major unanswered questions around P2P and protocol incentives

The most serious unresolved problems are not technical deployment details.

They concern the economic architecture of Sentinel itself.

The liquidity overhang

The main concern around the approximately 19.5 billion P2P currently bonded in staking is not the technical migration process itself.

The issue is what happens if those tokens, which today are structurally locked by Sentinel's Proof-of-Stake system, become potentially liquid once the sovereign chain is discontinued.

This does not mean that 19.5 billion P2P would immediately be sold. But for an asset with relatively limited market depth, turning such a large share of supply from bonded capital into potentially liquid capital creates a significant supply overhang.

The concern is amplified by token concentration. Community and on-chain estimates suggest that more than 8 billion P2P may be held by the team or related entities, although this figure has not been officially confirmed and should therefore be treated as an estimate.

Today, staking gives holders a structural reason to keep P2P locked: it secures Sentinel, provides governance rights, generates staking rewards and participates in protocol revenue.

If PoS disappears, that economic reason disappears with it unless a credible replacement is introduced.

The key question is therefore not simply how P2P will be migrated to Solana, but:

What will prevent billions of currently bonded tokens from becoming persistent potential sell-side liquidity once Sentinel no longer needs them to secure the network?

P2P currently has native utility because Sentinel is a sovereign PoS blockchain

Today, P2P is deeply embedded in Sentinel's architecture.

It is used for:

• Proof-of-Stake security;

• validator and delegator staking;

• governance;

• transaction fees;

• bandwidth payments;

• protocol incentives;

• and revenue sharing.

Sentinel's current economic design links:

network usage → protocol revenue → staking → security → governance.

That relationship is one of the strongest arguments for P2P having structural rather than purely speculative utility.

On Solana, several of these functions disappear automatically.

SOL, not P2P, would secure the underlying blockchain.

SOL, not P2P, would be the native base-layer fee asset.

Solana validators, not Sentinel validators, would operate consensus.

Sentinel could recreate:

• token staking;

• governance;

• revenue sharing;

• service payments;

• incentives;

• and fee abstraction

through Solana programs.

But those mechanisms would need to be deliberately redesigned.

Today they are native consequences of Sentinel being its own blockchain. After migration, they would become application-level tokenomics.

The community therefore deserves a clear answer to a basic question:

What exactly will require P2P after migration?

Not what P2P can be used for.

What creates structural demand for it?

The entire incentive system needs to be redesigned

Sentinel is not an economic relationship between only token holders and developers.

The network includes:

• node hosts;

• providers;

• validators;

• delegators;

• dVPN applications;

• users;

• developers;

• and governance participants.

The current chain coordinates incentives between them.

A Solana migration changes those relationships, for example:

• If Sentinel validators disappear, what happens to the economic value currently distributed to them?

• If PoS staking disappears, what replaces the incentives received by delegators?

• If P2P staking is recreated as a smart contract, does it actually secure anything or does it simply become a revenue-sharing mechanism?

• Does the current bandwidth revenue distribution remain intact?

• Will node hosts still receive the same percentage?

• If users and applications can avoid P2P completely, what produces persistent token demand?

• How does governance work?

• These questions describe the future economic structure of Sentinel.

• They should be answered before the migration is approved.

IV. Governance and sovereignty: this decision cannot be treated as unilateral

This is not simply a product decision, Sentinel is a governed blockchain.

P2P stakers participate in governance precisely because fundamental protocol decisions are supposed to belong to the network, not solely to the development team.

Halting Sentinel L1 would be one of the most consequential governance decisions the protocol could possibly make.

It would affect:

• validators;

• delegators;

• P2P holders;

• node operators;

• applications;

• developers;

• governance participants;

• and the future architecture of the network.

It would terminate the existing consensus system and fundamentally redefine the function of the native asset.

A decision of that magnitude cannot reasonably be presented as a normal technical migration decided first and explained later.

Governance requires informed consent

On-chain governance is meaningful only if participants have enough information to make an informed decision.

A governance vote cannot simply be:

“Should Sentinel migrate to Solana?”

without a detailed description of what the post-migration Sentinel actually is.

Before asking token holders to approve the end of Sentinel's sovereign chain, the team should publish a complete proposal covering at least the following areas.

Protocol architecture

• Which current native modules become Solana programs?

• Which functions move off-chain?

• How are nodes represented?

• How are providers represented?

• How are subscriptions and sessions represented?

• Which chain or system becomes the canonical source of protocol state?

P2P tokenomics

• What replaces Proof of Stake?

• What happens to the approximately 19.5 billion bonded P2P?

• What remains the structural utility of P2P?

• What happens to inflation?

• What happens to bandwidth revenue sharing?

• What mechanisms create future token demand?

Validators and delegators

• How are existing positions treated?

• What happens to delegations?

• What happens to rewards and commissions?

• Is any equivalent economic role created after migration?

Protocol governance

• How are protocol decisions made on Solana?

• Does P2P governance continue?

• What exactly can token holders vote on?

• Who controls program upgrades?

• Is upgrade authority controlled by a team wallet, a multisig or governance?

• Can governance veto upgrades?

Product incentives

• How are node operators rewarded?

• How are applications incentivized?

• How is protocol revenue distributed?

• Which economic relationships change?

State migration

• At which block is state captured?

• What state is migrated?

• How are staking positions represented?

• How are open sessions or subscriptions treated?

• How can users independently verify the migration?

Business case

• What measurable benefit is expected from Solana?

• How many new developers?

• How many new applications?

• How many new users?

• How much additional bandwidth consumption?

• How much liquidity?

• How much protocol revenue?

Alternatives

Most importantly, the proposal should explain why these objectives cannot be achieved through a less destructive architecture based on interoperability.

The team can propose a migration, but it should not be able to simply declare one.

A development team necessarily has substantial influence over a protocol.

It writes software, proposes upgrades, coordinates infrastructure and so on.

But Sentinel is not supposed to be a conventional SaaS company where management can decide to migrate from one backend to another without asking users.

The PoS system exists partly to distribute ownership over protocol decisions.

If the existing chain can be terminated simply because the development team decides that another ecosystem is strategically preferable, then the community should ask what practical meaning Sentinel governance has.

A legitimate migration process should therefore be:

1. research;

2. publication of a full architecture;

3. publication of tokenomics;

4. publication of migration mechanics;

5. public discussion;

6. comparison with alternatives;

7. sufficient time for validators, delegators and users to evaluate the proposal;

8. and finally a binding governance process.

And that order matters.

The decision should follow the plan. The plan should not follow the decision.

V. The better strategy is expansion, not migration

The strongest case for Solana is not that Sentinel's L1 is useless, is that Solana offers things Sentinel currently lacks:

• developers;

• users;

• liquidity;

• wallets;

• stablecoins;

• infrastructure providers;

• capital;

• and mindshare.

We agree.

Sentinel should aggressively capture those benefits, but there is no reason all of them require abandoning the sovereign protocol.

Architecture should not follow market cycles

Solana currently has one of the strongest combinations of retail attention, liquidity and developer activity in crypto; Sentinel should take advantage of that.

But crypto history also shows how quickly attention moves between ecosystems.

Across different market cycles, retail activity and capital have repeatedly shifted toward new Layer 1s, new execution environments and new narratives. Networks that once appeared to be the inevitable center of the industry later lost significant mindshare as users and developers moved elsewhere.

There is no reason to assume Solana will disappear, and that is not our argument.
The point is that market leadership is cyclical, while protocol architecture is a long-term commitment.

Sentinel may need to make architectural decisions that remain relevant for the next decade. It should therefore be extremely cautious about giving up sovereignty primarily to optimize for where crypto attention happens to be concentrated today.

If another ecosystem becomes dominant five years from now, a sovereign Sentinel can integrate it as well.

A Sentinel that remains independent can follow users wherever they go.
A Sentinel that migrates its core protocol every time market attention shifts would eventually become an architecture driven by hype cycles rather than product requirements.

Distribution should follow the market, but the protocol should not have to.

Sentinel should become chain-agnostic at the edges

Our preferred architecture has two layers.

A sovereign Sentinel core

The canonical Sentinel chain continues handling application-specific functions such as:

• node state;

• provider state;

• plans;

• subscriptions;

• leases;

• sessions;

• protocol incentives;

• P2P staking;

• governance;

• and future bandwidth-specific primitives.

Interoperable external layers

Applications and users can interact with Sentinel from:

• Solana;

• Base;

• Ethereum;

• Cosmos chains;

• stablecoin systems;

• fiat payment providers;

• and AI-agent payment protocols.

Sentinel is already demonstrating this model

Sentinel's x402 integrations are particularly important because they demonstrate that external-chain payments can access Sentinel infrastructure without moving the underlying bandwidth protocol.

Users or agents can pay with assets on another chain while Sentinel remains the canonical infrastructure underneath.

That is the model we believe Sentinel should expand: distribution at the edges and sovereignty at the core.

P2P can also expand without moving the canonical chain

If the goal is better liquidity, P2P can have representations and liquidity on Solana.

If the goal is Solana wallets, build wallet integrations.

If the goal is Solana developers, build SDKs and APIs specifically for them.

If the goal is stablecoin payments, allow Solana USDC and other assets to pay for Sentinel services.

If consumer applications want Solana-native incentives, allow them to use them.

If applications want completely different business models, let them experiment.

None of this requires the core bandwidth protocol to relocate. This architecture also preserves strategic optionality.

Today Solana may be the most attractive ecosystem. Tomorrow another network may become important for AI, payments or consumer applications.

A sovereign Sentinel can integrate all of them. On the other hand, Sentinel designed as an application inside one ecosystem necessarily becomes more dependent on that ecosystem.

VI. Why regulatory sovereignty matters for a privacy protocol

There is one final issue that should not be ignored.

Solana does not currently require protocol-level KYC.

It is a permissionless network, and it would be inaccurate to suggest otherwise.

But nobody can guarantee that the regulatory environment surrounding major blockchain infrastructure will remain unchanged forever.

KYC and compliance requirements already exist around some economically important parts of the Solana ecosystem. For example, participation in the Solana Foundation Delegation Program involves KYC requirements.

That does not mean independent Solana validators require KYC.

It demonstrates that regulatory requirements can emerge around infrastructure even when the underlying protocol remains permissionless.

For most applications this may be a secondary concern but, for a decentralized VPN protocol, it deserves more weight.

Sentinel exists to provide decentralized privacy and bandwidth infrastructure.

Its long-term architecture should minimize the number of external governance systems capable of affecting its operation.

A sovereign Sentinel blockchain cannot eliminate regulatory risk, validators and developers still operate in real jurisdictions. But it gives the Sentinel community control over its own protocol response.

If Sentinel becomes an application on another Layer 1, it necessarily inherits whatever technical, governance or regulatory decisions that Layer 1 makes in the future.

We are not predicting that Solana will implement mandatory KYC.

The point is precisely that nobody can guarantee that it will never happen.

For privacy infrastructure, preserving the ability to determine its own protocol rules has strategic value.

Conclusion: Sentinel should become bigger than its chain, not abandon it

Sentinel has real weaknesses: its liquidity can improve, its developer ecosystem needs to grow, its RPC infrastructure should become more professional, its underlying software must remain continuously patched and audited, its user experience should abstract more of the blockchain complexity, its integrations outside Cosmos should expand dramatically.

Those problems should be solved directly.

If Cosmos SDK has vulnerabilities:

upgrade and harden Sentinel.

If RPC infrastructure is inadequate:

build enterprise RPC infrastructure.

If P2P lacks liquidity:

bring P2P to Solana and other markets.

If users prefer stablecoins:

let them pay with stablecoins.

If developers are on Solana:

make Sentinel easy for Solana developers to use.

If consumers do not want to interact with Cosmos:

hide Cosmos entirely from the user experience.

None of those objectives inherently requires shutting down Sentinel L1, and before the community is asked to approve such a fundamental change, it deserves clear answers.

• What happens to the approximately 19.5 billion bonded P2P?

• What replaces Proof of Stake?

• What becomes the structural utility of P2P?

• How will protocol revenue be distributed?

• How will node operators be incentivized?

• How will governance work?

• Who controls program upgrades?

• What exactly is migrated?

• What measurable benefits justify the migration?
  

And most importantly:
which of those benefits cannot be achieved while preserving Sentinel's sovereign Layer 1?

Until those questions have credible answers, shutting down the chain would be premature to say the least.

Sentinel should not choose between sovereignty and ecosystem expansion, it can have both.
The better vision is not a Sentinel isolated inside Cosmos, and it is not a Sentinel reduced to another application running on Solana.

It is a sovereign decentralized bandwidth protocol connected to every ecosystem that matters.

Expand Sentinel. Don't migrate it.

TL;DR

Bitveil believes Sentinel should expand into Solana and other ecosystems, not migrate its core protocol away from its sovereign L1.

Sentinel’s blockchain is part of the product itself: it allows native dVPN logic, independent governance, protocol-level customization and an incentive system built around P2P.

The arguments currently used to justify migration - Cosmos SDK security concerns, limited enterprise RPC infrastructure, liquidity and ecosystem reach - are real issues, but none of them inherently requires shutting down Sentinel L1. They can be addressed through upgrades, better infrastructure and interoperability.

A migration would also introduce major unresolved economic questions. Around 19.5B P2P are currently bonded in staking, and removing PoS could turn a very large share of currently locked supply into potentially liquid supply while simultaneously removing several of P2P’s native utilities. The future incentive model, token utility and governance structure therefore need to be clearly defined before any decision is made.

Most importantly, Sentinel already has on-chain governance. The team can propose a migration, but ending the sovereign chain should require a detailed public plan, community review and a legitimate governance decision.

Our preferred model is simple:

Keep Sentinel as the canonical sovereign bandwidth layer. Expand P2P, payments, liquidity and applications across Solana, Base and other ecosystems through interoperability.

Expand Sentinel, don’t migrate it.

Privacy Policy

Terms & Conditions