Stables × Orobit: Connecting Payments to Bitcoin-Settled Assets

The Stables × Orobit relationship connects two parts of the same user journey: how value enters and leaves an application, and how programmable assets execute and settle once they are inside it.

At the service edge, Stables supplies the account, quote, transfer, compliance and status records behind a supported payment route. The Orobit wallet turns an authorised result into a locally signed asset action. SCL executes the programmed rules. A commitment anchors to Bitcoin. When the workflow uses an asset-bound channel, Lightning carries the transfer.

The result is a payments-to-settlement path in which every material step has a clear owner and a record a developer can follow.

The payment moment is only the beginning

People experience payments through familiar actions: fund an account, use a card, send digital dollars or request a payout. Developers see the state changes underneath those actions.

Stables brings virtual accounts, quote-first transfers, compliance workflows and developer APIs into one service boundary. Each supported route resolves into a precise provider record containing the source currency, amount, quote, fees, beneficiary, checks and current status.

The exact route is set by the approved Stables configuration for that market and product. That keeps the user experience specific: the application can show the available rail, price, limits and expected next step before value moves.

For Orobit, the important output is an authorised provider instruction that can be connected to one defined programmable-asset operation.

One durable instruction joins the systems

The hand-off is a versioned integration envelope rather than a generic success message.

It connects:

• the Stables customer, account, quote or transfer reference;
• the route, source currency, amount and beneficiary;
• the intended Orobit wallet or authorised account;
• the target SCL contract ID and ABI version;
• the permitted contract operation;
• the quote and policy versions applied to the instruction; and
• one durable correlation ID used across the full journey.

The adapter authenticates the provider event, confirms that it belongs to the expected instruction and maps it to the pinned SCL operation. Idempotent processing means a repeated webhook or restarted worker returns the original result instead of creating a second asset transition.

That correlation ID then follows the action from the Stables record to the wallet signature, Bitcoin transaction and resulting SCL state.

Local signing turns approval into user authority

Orobit’s browser wallet keeps the signing decision with the user.

For an SCL asset operation, the wallet prepares the Bitcoin transaction carrying the commitment and the corresponding signed call envelope. The browser signer authorises both locally, then sends the signed package forward for broadcast and execution.

This makes the approval screen part of the integration. The application can present the Stables route, amount and provider status alongside the exact asset operation waiting to be signed. The adapter coordinates the records; the user’s wallet authorises the asset action.

The surrounding services receive the transaction, signature and call material required by the network. The key that produced them stays with the signer.

SCL runs the asset rules under explicit ceilings

SCL is Orobit’s bounded, deterministic execution framework.

A contract compiles into deterministic bytecode with a defined ABI. The current execution environment caps a call at 100,000 instructions, a stack depth of 1,024, a call depth of 64 and 64 KB of storage per contract. Those ceilings make the work required by a call predictable for developers and node operators.

The accepted provider instruction maps to a named ABI operation. SCL validates the call against the committed contract, applies the programmed rules and produces the next state.

Given the same bytecode, payload, prior state and Bitcoin-derived context, an independent node can replay the transition and calculate the same result. Stables remains the authority for the payment-service record; SCL remains the authority for the programmed asset transition.

Bitcoin provides the common record

The contract commitment anchors to Bitcoin when the program is deployed. Each later call is committed through a compact protocol stamp in a Bitcoin transaction, binding the signed call envelope to the target contract and the outpoint named by the call.

Bitcoin confirmation supplies common ordering and verification context. SCL nodes watch for the commitment, validate its anchor binding and replay the execution in Bitcoin block order.

That gives an operator a durable chain of evidence: which instruction was approved, which contract operation was signed, where the call was anchored and which state root resulted from the execution.

Bitcoin is the common settlement and verification layer. SCL supplies bounded execution.

Lightning carries configured transfers

When the workflow uses an SCL asset-bound Lightning channel, the transfer rail and contract layer work together without becoming the same system.

The recipient creates a standard BOLT11 invoice and registers the asset terms against its payment hash. The payer sends an ordinary Lightning payment. Intermediate nodes route the HTLC normally, while the endpoints maintain the SCL asset allocation associated with that channel.

Release of the HTLC preimage supplies the shared trigger for the co-signed allocation update. Lightning carries the payment. SCL defines and records the programmed asset state. Bitcoin supplies the funding outpoint and commitment context.

For a named stablecoin route, the implementation record identifies the authorised asset representation, SCL contract ID, transfer authority and end-to-end test vector. That is the evidence connecting the generic channel mechanism to a specific asset flow.

The return path stays connected

An off-ramp begins from an authorised asset state and follows the same correlation model back to the Stables service edge.

The adapter waits for the agreed SCL and Bitcoin conditions, then creates the corresponding provider instruction. The payout record retains the original journey reference, while retries keep the same idempotency key.

The asset record and payment record remain distinct but reconcilable. A developer can see what happened to the programmable asset, what happened at the service boundary and which event connected the two.

One trace for operators

A complete integration trace connects:

• the funding intent and correlation ID;
• the Stables account, quote, transfer and event references;
• the wallet identity that approved the action;
• the SCL contract ID, ABI version and call-envelope hash;
• the Bitcoin transaction ID, anchoring outpoint and block height;
• the resulting SCL state root;
• the Lightning payment hash and channel-allocation sequence, where used; and
• the off-ramp or payout reference.

This is the practical value of the Stables × Orobit relationship: one user journey with explicit ownership from the first payment instruction to the Bitcoin-anchored asset state.

XRB remains the protocol layer. SCL is the bounded execution framework. Orobit stewards the ecosystem, wallet, nodes and documentation. SQRL packages selected capabilities into commercial institutional workflows. Stables owns the payment-service edge. Lightning carries configured transfers.

CTA: Bring one supported Stables route and one SCL asset contract to the Orobit integration team, and map the complete test vector from payment instruction to Bitcoin anchor.