How We Built Trezor Signing into Orobit’s Bitcoin Settlement Flow

We built Trezor signing into Orobit at the point where approval matters most: the Bitcoin transaction.

The flow begins in the Orobit wallet, where we construct a Bitcoin transaction and the SCL call it commits to. The user reviews and approves that transaction on their Trezor. Once signed, the transaction anchors the contract commitment to Bitcoin, and the linked call moves into SCL for bounded, deterministic execution. Independent nodes can then replay the state transition against the same Bitcoin-derived context.

Lightning remains the transfer rail. SCL does not replace it, and the hardware wallet does not become a Lightning node or contract executor. Each component keeps a precise job.

This is the engineering path we built: a direct line from hardware approval to a Bitcoin commitment, bounded SCL execution and independently replayable state.

We put Trezor at the Bitcoin approval boundary

Orobit’s wallet architecture already separates signing from coordination and execution. The wallet authorises transactions and contract calls. The hub maintains Lightning connectivity and channel state. SCL nodes validate and execute contract operations using Bitcoin-derived context.

We preserved those boundaries.

Trezor handles approval of the Bitcoin transaction carrying the SCL commitment. Orobit assembles that transaction, binds it to the intended call envelope and validates the signed result. Bitcoin provides the common settlement and verification layer. SCL executes the contract logic within explicit bounds. Lightning carries transfers.

That placement matters because a hardware wallet is strongest when it owns a clear signing boundary. It does not need to absorb every responsibility in the stack. The private key controlling the Bitcoin inputs stays on the device; Orobit receives the public account data and signatures required to construct and submit the transaction.

The device owns Bitcoin approval. Orobit owns the developer workflow around it.

We register a device-verified Bitcoin account

The first step is account registration. Orobit requests the public account data for a defined BIP84 derivation policy through Trezor Connect. For the first receiving address in a native-SegWit Bitcoin mainnet account, the path begins at:

m/84'/0'/0'/0/0

We store the derivation policy and the extended public key needed to construct future transactions. The browser never requests or receives the device seed or private keys.

The user then verifies a receiving address on the Trezor display. Orobit compares the address returned by the device with the address derived from the registered public account. This gives the wallet a public account record tied to an address the user has seen on trusted hardware.

The registration record is deliberately precise: account policy, public key material, the device-verified address and the Orobit wallet identity associated with that account. Model, firmware and connector-version coverage are recorded separately in the release matrix.

We bind one Bitcoin transaction to one SCL call

Every operation in this flow has two connected artefacts.

The first is a Bitcoin transaction carrying the contract or call commitment. Orobit places a compact protocol stamp in an OP_RETURN output. That stamp commits to the signed call envelope and the contract it targets.

The second is the SCL call envelope: the contract identifier, method, payload, signing authority and named Bitcoin outpoint that binds the call to its anchor.

We prepare both before the device is asked to sign. The commitment hash is calculated from the intended envelope, and the exact hash is placed in the Bitcoin transaction. If the call changes, the commitment changes. If the Bitcoin outputs or fee change, the transaction changes. Either change creates a new object that requires a fresh approval.

We use a Partially Signed Bitcoin Transaction as the portable transaction record. BIP174 gives us a structured place for the unsigned transaction, UTXO data, scripts, derivation paths and signatures. The adapter maps the relevant data into the structured inputs and outputs expected by Trezor Connect; it does not treat PSBT as a device API.

The result is one reviewable chain of intent: contract call, commitment hash, Bitcoin transaction and device approval.

We make the device approval meaningful

The host initiates the signing request, but Trezor drives the Bitcoin signing exchange. It requests the transaction data it needs and presents the Bitcoin effects that require approval, including the destination, fee and total spend.

At the same time, Orobit shows the SCL context: the contract being deployed or called, the method that will run and the envelope hash carried by the Bitcoin transaction. The wallet view explains the execution request; the Trezor display confirms the transaction that anchors it.

Those views are bound by the unsigned transaction and envelope hash recorded before signing. We do not rebuild the transaction after approval. When Trezor returns the signatures and serialised transaction, Orobit verifies that the commitment output still matches the intended envelope, the destination and change outputs are unchanged, and the fee remains within the approved policy.

Only that approved transaction moves to broadcast. A mutation at any point breaks the match and restarts the approval cycle.

We carry the anchor into bounded SCL execution

After broadcast, the linked call envelope is submitted to an SCL node. The node checks that the envelope targets the expected contract, names the correct Bitcoin outpoint and matches the commitment carried by the anchoring transaction.

SCL then derives the relevant Bitcoin context and executes the call inside its bounded virtual machine. The current architecture defines ceilings of 100,000 instructions per call, a stack depth of 1,024, a call depth of 64 and a 64 KB storage quota per contract.

These are engineering constraints, not marketing language. They make execution finite and reproducible. An independent node can load the same bytecode, payload, prior state and Bitcoin-derived context, replay the transition and compare the result.

Trezor approves the Bitcoin transaction at the edge of the workflow. Bitcoin supplies the common settlement and verification context. SCL supplies bounded, deterministic execution and independent replay.

We keep Lightning focused on transfers

Lightning remains a separate layer in the flow. The Orobit hub coordinates peers, channel state and chain monitoring, while SCL asset allocations can be associated with channel funding outpoints and updated alongside Lightning payments.

The integration puts Trezor at the Bitcoin signing boundary used by the anchored SCL operation. High-frequency channel state and the Lightning signer stay inside the dedicated Lightning flow.

This separation keeps the complete stack legible:

• XRB is the protocol layer.
• SCL provides bounded, deterministic execution and replay.
• Orobit stewards the protocol, developer tooling and wallet workflow.
• Bitcoin is the common settlement and verification layer.
• Lightning carries transfers.
• SQRL is the commercial layer built above the open protocol stack.

Each layer keeps one job, and the hand-offs are explicit.

Developers can verify the complete path

We built each hand-off around a concrete record. A developer reviewing the integration can follow the same sequence:

1. Register the BIP84 public account and verify an address on the device.
2. Build the SCL call envelope and calculate its commitment hash.
3. Construct the Bitcoin transaction carrying the protocol stamp.
4. Present that transaction to Trezor for explicit approval and signing.
5. Validate and broadcast the returned serialised transaction.
6. Submit the linked envelope to an SCL node when the anchor is observable.
7. Replay the resulting state transition against the same Bitcoin-derived context.

The release evidence for this path is equally concrete: derivation fixtures, unsigned and signed transaction records, envelope hashes, Bitcoin transaction IDs, device rejection and cancellation cases, and replay traces. Publishing that evidence alongside the adapter will let developers reproduce the flow rather than relying on a headline.

The shape of the system is simple even when the implementation is detailed: Trezor approves. Bitcoin anchors. SCL executes. Independent nodes replay. Lightning transfers.

That is how we brought hardware approval into Orobit’s model for programmable assets, settled on Bitcoin.

Explore the Orobit Lightning Wallet documentation, SCL Architecture, Trezor Connect, Trezor’s Bitcoin signing flow, BIP84 and BIP174.