Deal Box × Orobit: From Asset Terms to Bitcoin-Settled Execution

Deal Box publicly announced its relationship with Orobit in December 2024 around Bitcoin-native programmability and tokenized private-market access.

The practical value sits in the hand-off between two different bodies of work.

Deal Box’s current platform brings together issuer documentation, investor onboarding, data-room material, KYC, subscription documents and e-signature workflows. Its token-advisory work coordinates the asset, launch and vendor specification around an approved instrument.

Orobit’s role starts where that approved specification becomes executable state.

This is the path from private-market terms to programmable assets, settled on Bitcoin.

Start with an issuer-approved asset package

A programmable asset needs a precise definition before a developer writes a contract.

The package should identify:

• the issuer and instrument;
• the rights represented by each unit;
• supply, issuance and redemption rules;
• authorised participant roles;
• eligibility and transfer conditions;
• distributions or other state-changing events;
• the external evidence required for an instruction; and
• the party responsible for each approval.

The first engineering decision is which rules belong in code.

Supply limits, role permissions and deterministic transfer conditions can be expressed as contract behaviour. Identity checks, disclosures, legal approvals and discretionary exceptions remain in the systems and organisations responsible for them.

The contract consumes a defined result from those external processes. It does not need to recreate every commercial, legal or operational decision inside the execution layer.

That boundary gives the issuer, asset team and developer the same specification to review.

Turn each executable rule into a versioned artefact

Orobit’s current documentation describes SCL as a bounded, deterministic execution framework.

The `sclc` compiler turns contract source into three core artefacts:

• deterministic bytecode for the virtual machine;
• an ABI describing callable functions and emitted events; and
• metadata required by the node during execution.

Those artefacts form the technical hand-off.

Each coded rule should point back to an approved source term. The contract package should identify the source-document version, compiler version, bytecode commitment, ABI version and external instruction schema that prepares each call.

For a transfer restriction, the mapping can be explicit:

1. The approved asset package defines the permitted participants and condition.
2. The SCL source expresses the deterministic part of that rule.
3. The ABI names the function, arguments and event.
4. The adapter supplies a validated instruction from the source workflow.
5. The resulting state records whether the transition was accepted or rejected.

If an issuer changes the transfer rule, the release record shows whether the contract, adapter or operating process changed with it.

Anchor the contract to Bitcoin

The compiled contract receives a commitment hash. Orobit’s architecture documentation describes that commitment being embedded in a Bitcoin transaction.

Each subsequent contract call is committed in the same way. A compact protocol stamp binds the signed call envelope to the contract it targets. Bitcoin supplies the common ordered settlement and verification context.

SCL execution remains separate. Nodes load the committed payload, derive the required Bitcoin context and run the call inside the bounded SCL virtual machine. Another node can replay the same transition against the same Bitcoin-derived context and compare the result.

The sequence stays clear:

1. Approved asset terms define the rule.
2. The SCL contract expresses its executable part.
3. Contract and call commitments anchor to Bitcoin.
4. SCL executes the transition under explicit resource limits.
5. Independent operators replay the transition against Bitcoin-derived context.

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

Connect the Deal Box workflow to the ABI

A practical adapter between the Deal Box workflow and SCL should remain small enough to inspect.

The source instruction can carry a stable identifier, asset-package version, approved action, participant references and evidence hash. The adapter validates that schema, selects a pinned contract and ABI version, and maps the complete instruction into a specific contract call.

The integration record should preserve:

• the source instruction ID;
• the asset-package and contract versions;
• the canonical call payload;
• the Bitcoin commitment reference;
• the emitted contract event;
• the resulting state root; and
• a stable success or failure code returned to the source workflow.

An idempotency key tied to the source instruction prevents a retry from applying the same operation twice. Test vectors should cover valid instructions, incomplete evidence, stale package versions, unauthorised callers and repeated requests.

That gives both teams one traceable record from an approved asset instruction to the resulting contract state.

Carry configured transfers over Lightning

Where the workflow calls for movement between participants, Lightning carries the transfer while SCL applies the programmed asset rules.

Orobit’s documentation describes an SCL asset being bound to a channel funding outpoint. The recipient registers the asset contract and amount against a BOLT11 invoice payment hash. When the Lightning payment settles, the channel endpoints use the same payment trigger to update their co-signed asset allocation.

Lightning is the transfer rail. It does not execute the contract or replace the Bitcoin commitment.

The integration trace can connect the source instruction, SCL contract and call, Bitcoin commitment, channel outpoint, payment hash and resulting allocation. Each system keeps its own role while the complete movement remains inspectable.

Build an allocation-ready evidence pack

An allocation-ready programmable asset needs more than a token address.

The release pack should contain:

• the approved asset and participant specification;
• contract source and compiler version;
• deterministic bytecode, ABI and metadata;
• the Bitcoin commitment reference;
• adapter schema and version;
• replay instructions and test vectors;
• current state and state-root evidence; and
• the transfer or channel references used by the workflow.

This gives an issuer, administrator, developer or reviewer a direct route from the source term to the executing rule and resulting state.

Keep the stack explicit

Each layer retains a specific responsibility:

• Deal Box packages the asset, launch requirements and investor workflow.
• XRB is the protocol layer.
• SCL provides bounded deterministic execution.
• Orobit stewards the protocol, tooling and documentation.
• SQRL can provide the commercial operating layer for institutional implementations.
• Bitcoin supplies the shared settlement and verification context.
• Lightning carries configured transfers.

That is the useful Deal Box × Orobit model: approved asset terms moving into executable rules, with each material transition tied back to its source and independently replayable against Bitcoin.

CTA: Bring one approved issuance or transfer workflow and map it from the Deal Box asset package into a versioned SCL contract.

Sources

• Deal Box’s December 2024 Orobit partnership announcement
• Deal Box current platform
• Deal Box current tokenized-securities service
• Orobit SCL architecture
• Orobit SCL Quickstart
• Orobit Lightning architecture