VRP Is Ready for External Validation — Who Will Be the First to Pilot It?
My name is Vitalijus Riabovas.
I am the independent architect and creator of VRP — Veil Routing Protocol.
VRP is a continuity-first networking architecture built around a simple principle:
A logical session should not have to die simply because the network underneath it changed.
Wi-Fi → LTE/5G.
IP mutation.
NAT / CGNAT churn.
Temporary blackout.
Path failure.
Recovery.
Replay attempts.
Stale authority.
Duplicate execution.
For a long time, VRP was primarily architecture, runtime engineering and internal validation.
That stage has changed.
The public validation boundary exists now.
And I am inviting serious engineers and organisations to test it.
DON'T TRUST MY CLAIMS. TEST THEM.
I am not asking the networking industry to believe a presentation.
I built the measurement boundary.
The public VRP Validation Kit provides engineers with an environment for evaluating observable behaviour independently.
You can:
- clone the repository;
- run the Docker scenarios;
- inspect generated evidence;
- verify manifests and hashes;
- attack the evidence;
- delete events;
- duplicate events;
- reorder events;
- attempt replay;
- introduce stale conditions;
- corrupt artifacts;
- run the verifier;
- reproduce PASS / REJECT / INCOMPLETE outcomes.
If you believe something is wrong, try to produce a reproducible contradiction.
Give me:
environment → scenario → commands → evidence → result
That is useful engineering.
WHAT HAS BEEN BUILT?
VRP has moved far beyond an architectural diagram.
The project now includes multiple engineering layers.
Continuity architecture
Logical session identity is designed to survive changes in the underlying network path.
The architecture is being developed around continuity rather than assuming that transport identity and logical session identity must always be the same thing.
Runtime
The protected runtime implements the private VRP mechanisms.
That implementation is not public.
State and transition handling
The architecture includes explicit transition semantics rather than treating network mutation as an undefined external event.
Authority progression
Transition authority is controlled so that stale state cannot simply become authoritative again.
Replay handling
Replay conditions are part of the validation and security model.
Recovery behaviour
Blackouts and path failures are treated as state transitions that can be observed, tested and reasoned about.
Evidence generation
Execution produces evidence describing what happened.
Independent verification
Evidence can be evaluated separately from the runtime that produced it.
Adversarial mutation testing
Evidence can be modified deliberately to determine whether contradictions are accepted or rejected.
Docker continuity laboratory
Repeatable scenarios can be executed without requiring access to the proprietary VRP runtime internals.
Audit artifacts
Hashes, manifests, evidence and verification results provide a reproducible engineering trail.
THE BLACK-BOX BOUNDARY IS INTENTIONAL
There is an important distinction.
PUBLIC
Validation tools.
Scenarios.
Docker laboratory.
Evidence.
Verification.
Audit documentation.
Observable behaviour.
PRIVATE
Protected Runtime.
Proprietary continuity mechanisms.
Internal protocol implementation.
Private engineering logic.
This boundary is deliberate.
An evaluator does not need ownership of my implementation to test whether an externally observable claim survives an experiment.
Think of it this way:
I give you the ruler and the scales.
I do not give you the machine inside the sealed box.
Test the machine from the outside.
Attack its claims.
Measure its behaviour.
WHAT CAN YOU TEST TODAY?
The public validation work covers scenarios including:
- Wi-Fi → mobile transition
- blackout and recovery
- path mutation
- replay attempts
- stale authority
- duplicate execution
- evidence tampering
- event deletion
- event duplication
- event reordering
- sequence rollback
- continuity-reference substitution
- manifest manipulation
- truncated evidence
- malformed evidence
- missing evidence
The objective is not to make everything display PASS.
The objective is to distinguish:
valid execution
from
contradictory or incomplete evidence.
If something has been manipulated, the verifier should not quietly pretend nothing happened.
START HERE
VRP Validation Kit
https://github.com/Endless33/vrp-validation-kit
This is the main public engineering entry point.
Clone it.
Read it.
Run it.
Attack it.
Validation Documentation
https://github.com/Endless33/vrp-validation-kit/tree/main/docs
The documentation describes the validation, evaluation, audit and Pilot boundaries.
Docker Continuity Lab
https://github.com/Endless33/vrp-validation-kit/tree/main/docker/continuity-lab
This is where engineers can begin working with reproducible continuity scenarios.
Pilot Documentation
https://github.com/Endless33/vrp-validation-kit/tree/main/docs/pilot
For organisations considering moving from public evaluation toward a controlled Pilot.
VRP Pilot Kit
https://github.com/Endless33/vrp-pilot-kit
The Pilot material defines the engineering and commercial boundary separately from the protected runtime.
AND NOW COMES THE IMPORTANT PART.
WHO WILL BE FIRST?
VRP does not need twenty companies simultaneously.
It needs one serious first external participant willing to put the architecture against a real problem.
That organisation might be an:
- eSIM provider
- mobile operator
- roaming platform
- telecom company
- cloud provider
- edge infrastructure company
- cybersecurity company
- VPN infrastructure provider
- distributed-systems team
- critical-infrastructure operator
- mobility platform
- research organisation
Company size alone is not the deciding factor.
A smaller organisation capable of moving quickly may be a much better first participant than a global corporation requiring six months to make the first engineering decision.
I care about the problem.
I care about the environment.
I care about whether your engineers can actually test the architecture.
And I care about whether we can produce evidence.
IMAGINE AN eSIM COMPANY BEING FIRST
This is one of the environments I find particularly interesting.
A user moves between networks.
Wi-Fi disappears.
Mobile connectivity becomes authoritative.
IP addressing changes.
NAT state changes.
Roaming introduces additional uncertainty.
The user does not care which infrastructure component caused the transition.
The user cares about one thing:
Did the logical operation survive?
That is exactly the kind of environment where continuity should be evaluated against reality.
If an eSIM or roaming company becomes the first serious VRP participant, the question is no longer theoretical.
We can measure it.
THE FIRST PARTICIPANT WILL NOT RECEIVE MY SOURCE CODE
Let me make this explicit.
Pilot participation does not mean:
“Send us the VRP repository and we'll inspect your secret implementation.”
No.
The Protected Runtime remains protected.
A participant evaluates VRP through an explicitly defined integration and validation boundary.
The objective is to determine whether the behaviour works — not to transfer ownership of the architecture.
You may test.
You may measure.
You may attack the assumptions.
You may attempt to produce failures.
You may verify the evidence.
But proprietary VRP internals remain protected.
HOW TO REQUEST A VRP PRIVATE EVALUATION
The process is intentionally controlled.
Do not start by submitting the Tally form.
The first step is email.
Contact:
Subject:
VRP PRIVATE EVALUATION REQUEST — [LEGAL COMPANY NAME]
Tell me:
- your legal company name;
- official website;
- who you are;
- your role;
- why you are authorised to represent the organisation;
- what infrastructure you operate;
- what continuity problem you want to solve;
- what you want VRP to demonstrate;
- your expected technical and commercial timeline.
Do not send credentials, private keys, production secrets, customer information or sensitive infrastructure data.
If the organisation and request pass the initial qualification stage, the next stage may be authorised.
PRIVATE PILOT APPLICATION
The controlled application form is here:
Important:
This is not an open public application form.
Do not submit it without prior written authorization.
Unauthorized submission does not reserve a Pilot, create priority, or guarantee review.
The correct path is:
EMAIL → VERIFICATION → PRE-QUALIFICATION → AUTHORIZATION → APPLICATION → REVIEW → PILOT DECISION
That boundary exists for a reason.
I am protecting both VRP and the organisations evaluating it.
I AM NOT RESERVING THE FIRST POSITION FOR A GIANT
Google does not automatically get it.
Microsoft does not automatically get it.
A major telecom does not automatically get it.
Neither does a famous cybersecurity company.
Brand recognition is not an engineering qualification.
If a smaller eSIM company arrives with:
a real problem,
a serious engineering team,
a controlled environment,
measurable acceptance criteria,
and the ability to move,
I will take that organisation seriously.
The first meaningful VRP evaluation belongs to the organisation capable of actually doing the work.
WHAT I WANT FROM ENGINEERS
Do not tell me:
“Interesting project.”
That tells us almost nothing.
Instead:
Clone the Validation Kit.
Run the scenarios.
Inspect the evidence.
Attack the verifier.
Try to break an invariant.
Try to produce a reproducible contradiction.
If you succeed, send it to me.
If you cannot reproduce the claim, tell me exactly where.
And if the architecture continues behaving as specified under your tests, then we can have the more interesting conversation:
What happens when VRP meets a real network?
THIS IS WHERE VRP IS NOW
The progression has been:
IDEA
↓
ARCHITECTURE
↓
RUNTIME
↓
STATE MACHINE
↓
FAILURE / RECOVERY MODEL
↓
SECURITY BOUNDARIES
↓
EVIDENCE
↓
VERIFIER
↓
ADVERSARIAL TESTING
↓
DOCKER VALIDATION LAB
↓
PUBLIC VALIDATION BOUNDARY
↓
PRIVATE EXTERNAL EVALUATION
↓
REAL-WORLD PILOT
The next stage cannot be completed by another document.
It requires an external environment.
SO HERE IS MY INVITATION.
If you are an engineer:
test VRP.
If you are a security researcher:
attack the validation boundary.
If you are a protocol architect:
challenge the assumptions.
If you operate mobile, roaming, eSIM, cloud or edge infrastructure:
compare the continuity model against the failures you see in reality.
And if you represent an organisation capable of becoming the first serious external VRP participant:
contact me.
I do not need applause.
I do not need people to trust a claim because I wrote it.
I want something considerably harder to fake:
reproducible behaviour under failure.
Some organisation will eventually be first.
The interesting question is:
who?
Vitalijus Riabovas
Creator & Architect
VRP — Veil Routing Protocol
Engineering
VRP Validation Kit
https://github.com/Endless33/vrp-validation-kit
Validation & Audit Documentation
https://github.com/Endless33/vrp-validation-kit/tree/main/docs
Docker Continuity Lab
https://github.com/Endless33/vrp-validation-kit/tree/main/docker/continuity-lab
Pilot Documentation
https://github.com/Endless33/vrp-validation-kit/tree/main/docs/pilot
VRP Pilot Kit
https://github.com/Endless33/vrp-pilot-kit
Private Evaluation
First contact:
jumpingvpn@proton.me
Authorized Pilot Application:
https://tally.so/r/ZjQLN0
BUILD IT.
BREAK IT.
MEASURE IT.
PROVE IT.
Then let the evidence decide.
Top comments (0)