VM Proof Demo

See what VM proof looks like without uploading source.

This is a sample-only demonstration. It shows the shape of a selected function, representative protected output, report fields, and review checklist. It does not run arbitrary user code through the VM beta.

Open Full Proof Pack Read VM Option Docs View Corporate+

Sample Boundary

No public arbitrary VM playground.

VM protection is paid-tier beta functionality for selected cold functions. This demo is intentionally fixed so visitors can evaluate the proof model without creating a public execution surface.

Representative outputShows VM bootstrap and bytecode shape, not literal output from a customer build.

Source-free evidenceReport fields prove what ran without sharing private source code.

Performance guidanceUse VM protection only for small, rarely called sensitive functions.

Sample Run

A cold sensitive function is the right VM candidate.

License checks, paid-feature gates, anti-tamper routines, and small proprietary checks are good candidates. Render loops, parsers, and frequently called UI code should stay on Maximum mode.

Input Marker

Marked source function

The marker sits directly above a supported synchronous function. The real build report, not this page, is the source of truth for customer releases.

// @virtualize
function validateLicense(userId, licenseKey) {
  let hash = 2166136261;

  for (let i = 0; i < licenseKey.length; i++) {
    hash ^= licenseKey.charCodeAt(i);
    hash = Math.imul(hash, 16777619);
  }

  return (hash >> 0) === expectedLicenseHash(userId);
}

Output Shape

Representative protected output

The readable body is replaced by generated interpreter dispatch and encoded data. Exact names, bytecode, and layout change by build.

var __jsoVm=(function(){
  var seed=492817, tape="61,08,4d,3f,...";
  var ops=decodeTape(tape, seed);
  function run(slot,args){
    var pc=0, stack=[], locals=args.slice(0);
    while(pc<ops.length){
      switch(nextOpcode(ops,pc++)){
        case 17: stack.push(locals[nextOperand(ops,pc++)]); break;
        case 42: stack.push(Math.imul(stack.pop(), nextOperand(ops,pc++))); break;
        case 91: return stack.pop();
      }
    }
  }
  return { call: run };
})();

function validateLicense(userId, licenseKey) {
  return __jsoVm.call(0, arguments);
}

Report

Source-free proof fields

{
  "BuildID": "checkout-2026-07-03",
  "UseVMProtection": true,
  "VMProtectionApplied": true,
  "VMProtectionVirtualizedCount": 1,
  "VMProtectionWarnings": [],
  "ReviewDecision": "ready-for-manual-review"
}

Checklist

Reviewer pass conditions

UseVMProtection=true appears in the config or request.
The account is eligible for Corporate or Enterprise VM beta access.
The report shows a non-zero virtualized count.
The shipped file no longer contains the readable selected body.
The protected login, checkout, or license flow passes smoke tests.

Performance

Use VM protection sparingly

VM protection adds runtime work. Keep hot loops, render ticks, parsers, animation paths, and high-frequency validation on Maximum mode unless a real app benchmark proves the cost is acceptable.

Good: startup, activation, license validation.
Usually acceptable: occasional user action checks.
Avoid: continuous loops and thousands of calls per session.

Next Step

Turn the sample into a real review packet.

For a customer build, save the source-free API report, run the VM proof-pack command, attach smoke-test results, and share only the generated evidence packet with reviewers.

npx jso-protector --config jso.config.json \
  --manifest dist-protected/jso-manifest.json \
  --report dist-protected/jso-report.json

npx jso-protector --verify-vm-proof dist-protected/jso-report.json \
  --min-vm-functions 1

npx jso-protector --vm-proof-pack dist-protected/jso-report.json \
  --vm-proof-output reports/vm-proof-pack.md \
  --min-vm-functions 1

Open Proof Pack Security Evidence Hub Compare VM Options

Frequently asked questions

Does this demo run our source code through the VM?

No. It is a sample-only demonstration, showing the shape of a selected function, representative protected output, the fields a report contains, and the review checklist. Nothing you supply is executed here, and no arbitrary code is put through the beta. The point of the page is to let you see what the evidence looks like before deciding whether to run anything of your own.

What makes a function a good candidate for virtualization?

Being valuable and cold. Virtualization compiles a function to bytecode for an interpreter shipped alongside it, which is meaningfully slower than running native code, so the cost is only worth paying where the logic itself is the asset and the call frequency is low. A licence check, an entitlement decision or a signing routine that runs occasionally is the right shape. A message loop or a render path is the wrong one, and scoping it to a handful of functions rather than a bundle is the whole technique.

What does a proof pack contain?

The evidence that the transformation you paid for actually happened on the build you shipped: which functions were virtualized, the report fields describing the run, and a checklist a reviewer can work through. It exists because the difference between an option being enabled in a configuration file and applied in an artifact is precisely the sort of thing that is assumed rather than checked, and it is checkable.

Can we verify the result in continuous integration?

Yes, and that is the intended use. The verification command reads the report from a build and can require a minimum number of virtualized functions, so a build that silently produced none fails rather than passing quietly. Wire it into the same pipeline stage as your other release checks and the guarantee becomes ongoing rather than a one-off inspection.

How much harder does virtualization make analysis?

Substantially harder than transforming identifiers, because what ships is not your code. A reader faces an interpreter and a stream of opcodes, so understanding the logic means understanding a custom instruction set first, and the usual technique of beautifying and reading does not apply. It is a transformation rather than a guarantee, so the honest framing is a large increase in the effort required rather than a claim about what is possible.

Where should we start if we are evaluating this?

Open the proof pack documentation to see the evidence format, then pick one genuinely cold and genuinely sensitive function in your own codebase as a first candidate. Measure the call frequency before you commit to it, because the single most common disappointment with this option comes from applying it to something on a hot path and then attributing the slowdown to protection in general.