The Verification Path Behind XRB

XRB has a verification requirement before it has an economic function.

If XRB is to connect contract resource capacity with validator work, every node needs to agree on the exact call, contract, Bitcoin context, execution limits and resource result. A token balance cannot solve ambiguity in the software that interprets it.

That is why we built the XRB path inside a broader verification stack. The Orobit protocol identifies and validates the instruction. SCL executes the committed program deterministically. XRB accounts for bounded contract resources and validator incentives. Bitcoin gives independent nodes a common commitment and ordering context.

The result is not simply a transaction that succeeded. It is an evidence path another node can reproduce.

1. Identify the instruction before executing it

An Orobit state-changing request is packaged as a signed call envelope. The documented envelope binds:

• the network and target contract;
• the function and arguments;
• the caller's public key and signature;
• a unique call identifier; and
• the exact Bitcoin outpoint used by the transaction.

The corresponding Bitcoin transaction carries a compact protocol stamp committing the envelope hash and contract identifier. Nodes verify the signature, hash and outpoint binding before the call reaches SCL.

This is a protocol-validation step, not a token function. XRB is not the stamp and does not execute the call. The separation matters because the resource result is only meaningful after the network has agreed on which request is valid.

2. Execute one exact SCL artifact

SCL turns a contract into canonical bytecode, an ABI and metadata. That artifact—not a product label or an interface description—is the program independent nodes need to run.

For a reproducible transition, the complete input is:

committed SCL artifact + signed call + prior state + Bitcoin-derived context

SCL runs that input under bounded rules. It excludes the sources of ambient nondeterminism that make two machines quietly produce different answers, and it limits instruction, memory, stack and nested-call use. The execution produces a write-set; the resulting state root provides a compact checkpoint another node can compare.

Bitcoin anchors and orders the commitment. It does not run the virtual machine. SCL performs the execution, while independent validators repeat the work.

3. Make XRB resource results deterministic

The same reproducibility requirement applies to XRB fuel.

Every validator needs to identify the same XRB contract parameters, read the same confirmed stake, select the same contract tier, apply the same limits and calculate the same charge. Otherwise, nodes could agree on the application state while disagreeing on the resources used to produce it.

The node-side architecture we built follows an assess → execute → settle lifecycle:

1. identify the root contract and read its confirmed XRB stake;
2. select the execution tier and create one budget for the complete call tree;
3. run the SCL call and meter computation and storage;
4. produce a deterministic resource receipt; and
5. settle the corresponding result only on the confirmed execution path.

Binding capacity to the root contract matters. A child call cannot escape into a new budget, and a deployer, wallet or individual node cannot privately substitute its own tier. Reorganisation and replay paths reconstruct the result from chain-derived state so the same confirmed history produces the same outcome.

We have implemented that assessment, metering and confirmed-execution settlement path. Production activation remains deliberately gated until the activation height and XRB contract parameters are set. The build is real; active production fuel, burns and validator emissions are separate claims we are not making today.

4. Verify the software that performs the check

Deterministic rules only help when nodes run the intended artifact.

A version string such as v1.2.3 is a convenient label. It is not proof of the source commit, compiler, binary or container digest actually running. For an XRB validator, release provenance applies to the compiler and SCL runtime as well as the node code that assesses stake, selects a tier and creates the resource receipt.

Core Lightning's v26.06.7 security release offered a useful operational example in August 2026. Its maintainers warned that two automatically published container tags did not contain the intended fixes at the time of the notice, even though the software reported the expected version. The warning did not describe a general Docker compromise or a loss of funds. It showed why the label and the artifact must be checked separately.

The same principle applies here: the node cannot be considered reproducible if its call is exact but its software is not.

The evidence bundle we are working toward

For an SCL node, wallet or contract deployment, a strong release record should retain:

• the source repository and exact commit;
• the build recipe, compiler and runtime versions;
• a signed manifest covering distributed artifacts;
• checksums and immutable container digests;
• the canonical SCL bytecode, ABI and contract commitment;
• the XRB contract parameters and activation configuration;
• the resource-tier schedule and expected receipt test vectors;
• a deployment attestation for each environment; and
• the verified rollback artifact and trigger conditions.

These are the controls the full operating system should publish consistently, not a claim that every current Orobit release already exposes the complete bundle. The immediate standard is simpler: do not accept a label where exact bytes and protocol parameters are required.

Why this is the XRB story

XRB exists to make resource capacity and verifier work part of the protocol's deterministic operation. That role only works when every node can show how it reached the same answer.

The layers remain distinct:

• The Orobit protocol identifies and validates the signed call.
• SCL executes the bounded program and produces the state transition.
• XRB supplies contract resource capacity and validator incentives.
• Bitcoin anchors and orders the commitments used for replay.
• Orobit stewards the ecosystem, tooling and documentation.
• SQRL is the commercial layer, while Lightning carries transfers where used.

That is what we have built around XRB: a path from a signed instruction to an exact program, a bounded resource receipt and a state result that another node can independently replay.

Signed. Anchored. Replayed.

Programmable assets, settled on Bitcoin.

Follow the documented settlement path, then review the XRB fuel design.