Introduction
VersoVPN is a privacy-first VPN with an open token economy. It is built on a simple observation: a VPN does not remove the party who can watch you — it replaces one with another. The trade is only worth making if the new party keeps nothing worth taking.
Most providers answer this with a policy. A policy is a promise about future behaviour, and a promise is a setting someone can change — during a migration, after an acquisition, or when a new vendor turns logging back on by default. We would rather there be very little to keep in the first place, because of how the system is built rather than how the company feels about it.
VVPN, the network's utility token on Solana, exists for the same reason. Subscriptions are paid in VVPN and settled on-chain, so no banking record ties a person to an account. Paying operators in the same token lets capacity appear where users actually are, instead of where a hosting budget was approved a year ago.
This document describes what is decided, what is intended, and — explicitly — what is not decided yet. It is a working document, not a prospectus.
The problem
A commercial VPN asks for three things at once: your money, your traffic, and your trust. Each of them leaks something.
- Payment identifies you. A bank payment names the subscriber, the provider and the date. Even a provider who logs nothing is holding a billing record that ties a person to an account.
- Logs exist by default. Servers log unless someone deliberately makes them stop, and "deliberately" has to survive every future migration, vendor and on-call engineer.
- Trust is unverifiable. Audits are snapshots. Between two audits, the only thing standing between a user and a log file is the operator's word.
- Capacity is centrally planned. Coverage follows procurement, not demand. Users in the places that need a VPN most are frequently the ones served worst.
None of this is solved by promising harder.
What VersoVPN is
A VPN service designed so that there is little to hand over, and an economy that does not require users to identify themselves in order to pay.
No account to identify. Access is attached to a subscription, not to a profile about a person. There is no name field because nothing in the system would use it.
Payment separated from usage. How a subscription was paid and what was connected to are kept apart. Payment is settled in VVPN, so there is no banking record to separate in the first place.
Keep less rather than guard more. Data that exists gets copied, leaked, or sold with the company after an acquisition. The only version that survives all three is the version never kept. The concrete retention statement — what is kept, for how long, and how that can be checked — will be published before launch, as specifics rather than as a slogan.
Operator-run capacity. Anyone can run a node and be paid for the traffic it serves. Coverage grows where people connect from.
Modern, inspectable transport. WireGuard-based tunnelling: quick to connect, small enough to audit, undramatic on battery. Any client that shipped would come with public source and protocol details — a privacy claim nobody can inspect is a slogan.
Subscriptions and the VVPN token
The design uses a subscription model. Plans would be priced in USD as the reference unit and paid in VVPN, settled on-chain. Nothing below is running today.
When paying in VVPN, the amount of tokens is derived from the USD price using a moving average of the VVPN/USD rate over a trailing window, rather than the spot price at the moment of payment. This is a deliberate safeguard in both directions: a user does not overpay because of a five-minute spike, and the network does not lose a month of revenue because of a five-minute dip.
Payment in the token is how the design works, not an alternative rail: a bank payment would recreate the record the whole thing exists to avoid. The free tier would require no payment at all, so the service could be tried before holding any token.
Access tiers and staking
In the design, staking VVPN would unlock higher access tiers instead of a higher bill: access would follow the stake rather than a repeated charge, and the network would get a supply of tokens that is committed rather than circulating.
Staking parameters — thresholds, holding periods, and what each tier includes — are not decided, and no staking exists. If it is ever built, it is a mechanism for access, not a yield product: no return is promised, offered, or implied.
Node operators
Operators who provide capacity would be paid in VVPN for the traffic they serve, following measured traffic rather than declared capacity, so the cost of adding a node is borne by whoever benefits from it being there. No node software exists.
The measurement scheme, the reward formula and the anti-abuse rules are not written. They are the part of this design that fails most often in practice — a naive scheme pays the operator who fabricates traffic — and they would have to be published in detail before any reward was paid.
The token
VVPN is a classic SPL token on Solana with Metaplex metadata. Token-2022 extensions are deliberately not used: they cost compatibility with wallets, DEXes and aggregators, and nothing in this design needs them.
| Symbol | VVPN |
| Name | VersoVPN |
| Chain | Solana |
| Standard | SPL Token (classic) |
| Decimals | 9 |
| Total supply | 1,000,000,000 VVPN |
| Mint address | CBt7jmKq3vc7MD2zJDMZhL4jpN53bY3am8uVmvB8ywRz |
The mint address is already fixed and published here, even though the token has not been issued on mainnet yet. This is intentional: the address is derived from a key held by the project and will be the same one on every network. Any other address presented as VVPN — before or after launch — is not ours.
Distribution
Supply is fixed at 1,000,000,000 VVPN and fully minted at issuance. There is no inflation mechanism, so nothing here can be diluted later — the trade-off is that nothing can be staged by issuing gradually either. Staging is done with locks instead.
| Allocation | Share | Tokens | State at launch |
|---|---|---|---|
| Sale (liquidity pool) | 10% | 100,000,000 | Liquid — a single-sided position; this is what buyers buy from |
| Grants, services, contributors | 10% | 100,000,000 | Liquid, one wallet, spent as people are actually paid |
| Team | 15% | 150,000,000 | Locked until 1 March 2027, then monthly over 36 months |
| Treasury and development | 30% | 300,000,000 | Locked until 1 March 2027, then monthly over 36 months |
| Reserve | 35% | 350,000,000 | Locked until 1 March 2027, then monthly over 36 months |
The three locks exist on-chain and can be read by anyone, without taking this document's word
for it. They were created on 8 September 2026 through Jupiter Lock
(LocpQgucEQHbqNABEYvBvwoxCPsSbG91A1QaQhQQqjn), all with the same cliff timestamp and the same
36-month monthly schedule, and none of them can be cancelled or redirected by anybody:
| Lock | Escrow account | Tokens held |
|---|---|---|
| Team | EYMyrgp75JnJPmTJkWYzW7MbC7UdMftbgiHcSdme2eKe |
150,000,000 |
| Treasury | 4Sqe51DwE9iUkaUw6B1FRHQjS4M5VykUsT8rQNm4PCm2 |
300,000,000 |
| Reserve | 5t1T1rNHGTJbYmTgaxuksnxEQdQr79enFFopvE7fSVU1 |
350,000,000 |
The sale position covers a price range of $0.000075 to $0.001 per token — a fully diluted valuation of $75,000 at the first purchase, rising to $1,000,000 if the entire position is bought out. The average sale price across that range is $0.000274, so the position as a whole can absorb about $27,000 before it is exhausted. Those bounds are a decision, published here in advance rather than discovered by whoever buys first.
Free supply outside the pool equals the pool itself: 100,000,000 against 100,000,000. That ratio is the number worth checking before buying anything, here or anywhere else. It says how much can reach the market beside what is on sale. Everything else is locked, and locks are on-chain.
Locking uses an existing lock program rather than a contract written for this project: there is nothing bespoke to trust, and the schedule can be read by anyone from the lock account.
Nothing unlocks until the cliff date, and then it unlocks monthly rather than in chunks. The monthly tranche is about an eighth of the pool's depth — small enough to be absorbed without collapsing the price it is sold into. Twelve-month schedules were considered and rejected for exactly that reason: they would release more than a third of the pool every month.
Unlocked tokens are added to the pool, not sold into it. Each tranche opens a new single-sided position in a range above the current price. That turns an unlock into an offer at a higher price instead of pressure on the current one, and it means the project is paid only when someone actually buys. It also caps the damage a tranche can do: an offer nobody takes simply sits there.
Addresses are published here once they exist. The allocation above is a decision; the wallets, the lock accounts and their schedules become links in this table at issuance. Until then this section describes intent, and the difference is stated rather than blurred.
Mint and freeze authority
Both authorities are held by the project until issuance. Security scanners flag that state, and correctly: an active mint authority means supply can still change.
Both are revoked at issuance, before the pool opens — the whole supply is minted first, then the authorities are given up, so that anyone looking at the token on its first day sees a fixed supply that nobody can extend or freeze. Revocation is irreversible, which is exactly why it is done deliberately and announced with the transaction that does it.
Security and trust
- The token is an ordinary SPL token issued through Metaplex Token Metadata. There is no custom token contract, so there is no bespoke code that could contain a bespoke bug.
- Everything about the token is publicly verifiable on Solana explorers: supply, holders, authorities, and every transfer.
- The service is being designed to be checkable, not merely trusted: published retention specifics, public client source, and inspectable protocol choices.
- Nothing to review yet. There are no contracts and no staking mechanism. If either is ever built, it would need external review before holding anyone's tokens.
Security here is not a feature list. It is the assumption that anything stored will eventually be seen by someone it was not meant for — so the design keeps as little as possible.
Status
At the time of writing:
- The token exists as a design and a fixed mint address; it has not been issued on mainnet.
- The issuance path has been rehearsed end-to-end against real mainnet programs on a local fork.
- The service is a design. There is no client, no node software, and no staking — and no commitment here that any of them will be built.
- Distribution is decided and published above; the addresses appear once they exist.
- Pricing, staking parameters and node reward rules are open questions, listed as such above.
This document will be updated as each of these becomes a fact. Changes that matter will be dated.
Legal notice
VVPN is a utility token intended for use inside a product. It is not a security, not a share, not a deposit, and not an investment product. Holding it does not entitle the holder to profit, dividends, revenue, or any claim on the assets of the project.
Nothing in this document is financial advice, an offer to sell, or a solicitation to buy any asset. Forward-looking statements describe intent and may change. The value of a token can fall to zero.