From Contract Code to Bitcoin: Orobit CEO Paul Dando on Building SCL

Paul Dando joined the Paul Barron Network with a clear proposition: programmable assets should be able to execute defined rules while Bitcoin remains the common settlement and verification layer.

That is the architecture Orobit has been building. SCL handles bounded, deterministic execution. Contract definitions and calls are committed to Bitcoin. Nodes can independently replay the resulting state transitions against Bitcoin-derived context. Lightning carries configured transfers.

The interview ranges across Bitcoin, real-world assets, wallets, stablecoin liquidity and Lightning. The most useful thread is the engineering model connecting them.

Programmable assets, settled on Bitcoin.

The build starts with a commitment

An SCL contract begins as source code. The sclc compiler turns that source into deterministic bytecode, an ABI and contract metadata. The bytecode is the program a node executes; the ABI defines the functions and events that wallets, applications and integration services can use.

At deployment, a commitment hash of the compiled contract is embedded in a Bitcoin transaction. Each later contract call carries its own signed envelope, including the contract ID, function, arguments, caller, unique call ID and the Bitcoin outpoint its anchor transaction must spend. A compact protocol stamp in the Bitcoin transaction commits to that envelope and its target contract.

The result is a direct connection between the rules a developer compiled, the instruction a user signed and the record Bitcoin orders.

SCL makes execution predictable

The contract executes inside the SCL virtual machine rather than inside Bitcoin Script. That separation gives developers a dedicated execution environment while keeping Bitcoin as the shared reference for settlement and verification.

SCL is deterministic by design. A contract cannot depend on a local clock, external network request or random value that could make two nodes reach different results from the same input. It also operates under explicit resource ceilings: 100,000 instructions per call, a stack depth of 1,024, a call depth of 64 and 64 KB of persistent storage per contract.

Those limits are part of the execution model, not a marketing promise. A developer can inspect the bytecode, understand the ABI and know the maximum work a call is allowed to perform.

Every state transition can be replayed

An SCL node watches Bitcoin for protocol stamps, validates the anchor binding and processes confirmed calls in Bitcoin block order. It derives the relevant context from Bitcoin, loads the committed bytecode and executes the same payload under the same limits.

The resulting write-set is folded into the state for that block. Another operator can reconstruct the same history from the contract commitment, confirmed calls and Bitcoin-derived context. Verification is therefore something an operator can perform independently, rather than a status supplied by one application.

This is the central point behind the architecture Paul describes: Bitcoin supplies the common ordered record; SCL supplies the bounded execution rules; replay supplies the check.

Lightning carries the transfer

Execution and transfer are separate jobs.

In Orobit's documented SCL-on-Lightning flow, an asset can be bound to a channel funding outpoint. The parties maintain a sequence-numbered, co-signed allocation for that channel. A recipient creates a standard BOLT11 invoice and associates the asset terms with its payment hash. The Lightning payment follows its ordinary route, while release of the HTLC preimage provides the shared trigger for the corresponding asset-allocation update.

Intermediate Lightning nodes route the payment. They do not execute the SCL contract or decide the asset state. SCL defines and accounts for the programmable asset; Lightning carries the transfer; Bitcoin supplies the funding and commitment context.

That division of work is what turns a broad “Bitcoin DeFi” conversation into an inspectable system design.

One stack, four distinct roles

Orobit's hierarchy matters because each layer solves a different problem:

• XRB is the protocol layer.
• SCL is the bounded, deterministic execution framework.
• Orobit stewards the ecosystem, tooling and documentation around the protocol.
• SQRL is the commercial layer through which enterprise products and operating workflows can be packaged.

Bitcoin remains the common settlement and verification layer, while Lightning carries transfers where the implementation calls for it. Keeping those roles distinct makes an integration easier to specify and easier to audit.

What this changes for real-world assets

A real-world asset needs more than an on-chain symbol. It needs a defined issuer, source documents, participant rights, transfer conditions and a clear authority for every rule.

SCL does not replace those legal or commercial foundations. It provides an execution framework for the parts that can be expressed as deterministic rules: who may call a function, which condition must be satisfied, how supply or ownership state changes and which event is emitted.

That creates a practical implementation path:

1. Define the asset and the authoritative terms outside the protocol.
2. Express the executable rules in SCL and compile them into versioned artefacts.
3. Commit the contract and its calls to Bitcoin.
4. Replay state transitions independently against Bitcoin-derived context.
5. Use Lightning for configured transfers.

For an issuer, the value is a clearer boundary between source terms, executable logic, settlement evidence and movement. For a developer, it is a concrete set of artefacts and interfaces to build against.

Built for inspection

The interview is the introduction. The stronger proof is the material developers can inspect after it.

Orobit's documentation publishes the architecture, contract model, execution limits, settlement flow, Lightning design and node interfaces. The August 2026 SCL whitepaper, authored by Paul Dando and Ashif Asharaph, sets out the formal model behind those components.

Watch Paul Dando's full conversation with Paul Barron, then follow the architecture into the documentation:

• Watch the interview
• Read the SCL overview
• Inspect the architecture
• Review settlement and validation
• Explore SCL on Lightning
• Read the SCL whitepaper