VRP Is Ready for External Validation — One Company Can Be the First to Pilot It

Jumping VPN — Fri, 21 Aug 2026 09:32:38 +0000

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:

jumpingvpn@proton.me

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:

https://tally.so/r/ZjQLN0

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.

DEV Community: Jumping VPN