Layered Settlement and Bridges

Overview

BTX implements a layered settlement system that enables cross-domain value transfers between the base chain and external domains (L2s, sidechains, application-specific rollups). The bridge protocol exposes batch-oriented commitments and authenticated roots on the base chain. In current production policy, bridge shield ingress is not supported; bridge structures should be read as committed/authenticated surfaces, not as a blanket guarantee that every recovery or exit path is live finality.

BridgeBatchStatement (v5)

A BridgeBatchStatement is the top-level settlement request that encodes a batch of cross-domain transfers. Each statement carries:

The statement hash (ComputeBridgeBatchStatementHash) is the canonical identifier used to bind settlement proofs, receipts, and committed ingress or exit metadata to a specific batch.

BridgeBatchCommitment (v3)

The v3 bridge batch commitment contains five authenticated roots that bind the batch to specific state transitions and policies:

Extension flags (FLAG_HAS_RECOVERY_OR_EXIT_ROOT, FLAG_HAS_POLICY_COMMITMENT, FLAG_CUSTOM_ACTION_ROOT, FLAG_CUSTOM_DATA_AVAILABILITY_ROOT) indicate which optional roots are populated, enabling compact serialization when fields are unused.

Verification Model

Bridge batches can carry two verification paths, both of which produce cryptographically bound receipts where that bridge surface is active:

Signed Receipt Path

An authorized verifier set attests to batch validity by producing signed receipts. The BridgeVerificationBundle contains a signed_receipt_root (Merkle root of all signed attestations) and a proof_receipt_root (for proof-based attestations). Verification checks:

• Each receipt's statement hash matches the batch statement hash.
• Signatures are valid under the committed verifier set.
• The verifier threshold defined by the proof policy is met.

Proof Receipt Path

Alternatively, a cryptographic proof (ZK or otherwise) can attest to batch validity without requiring a trusted verifier set. The proof is verified against the proof policy descriptor, and the result is encoded as a proof receipt.

Inclusion Verification

Verification receipts and commitments are checked at inclusion time for the active bridge surface. Inclusion authenticates the statement and committed roots on-chain, but committed recovery_or_exit data should not be described as a fully active finality guarantee unless the corresponding exit path is enabled.

Settlement Binding

Bridge settlement integrates with the SMILE v2 proof system through settlement binding digests. Current production support is strict shielded-to-transparent exits and recovery, not bridge shield ingress:

• Ingress batches (BRIDGE_IN) remain consensus-visible commitment surfaces, but shielded pool credits and new appends are disabled at height 125000. They are not an active production shield ingress path.
• Egress batches (BRIDGE_OUT) consume shielded notes and produce transparent outputs or cross-domain transfer claims.
• The settlement_binding_digest in each proof envelope binds the shielded proof to the specific bridge batch statement.

Egress and Recovery Surfaces

Recovery / Exit Commitment Surface

The recovery_or_exit_root commits to recovery and exit entries that can be authenticated against the batch commitment. This preserves a verifiable surface for recovery tooling without implying that every committed entry is an immediately spendable production exit. Key properties:

• Recovery and exit claims can reference the recovery_or_exit_root from a valid batch commitment.
• Each committed claim is authenticated by a Merkle inclusion proof and the required user authorization.
• Spendability depends on the active consensus and wallet rules for that exit surface.
• The root is a committed data surface, not a standalone guarantee that all exits bypass external-domain coordination.

Batch Leaf Structure

Individual transfers within a batch are encoded as BatchLeaf entries:

The batch Merkle root is computed over the ordered set of leaf hashes, binding every individual transfer to the batch statement.

Transaction Families

Bridge operations map to specific SMILE v2 transaction families:

• V2_INGRESS_BATCH — inbound commitment surface; production shielded credits and new appends are disabled at height 125000
• V2_EGRESS_BATCH — outbound batch settlement for shielded-to-transparent exit flows
• BATCH_SMILE — direct shielded-pool deposit family retained as a consensus-visible compatibility surface, not active production shield ingress

Each family has its own proof envelope requirements and settlement binding rules, ensuring that cross-family replay is impossible.

Security Properties

• Authenticated inclusion: Active bridge surfaces verify their statements, commitments, and receipts at inclusion time.
• Replay protection: Per-entry nonces and per-batch epoch ordering prevent replay of settlement claims across batches or domains.
• Domain isolation: The domain_id field ensures that batches from different external domains cannot interfere with each other.
• Binding integrity: The statement hash cryptographically binds all components (entries, proofs, receipts, and committed ingress/exit metadata) to a single batch.
• Recovery visibility: The recovery/exit root authenticates committed recovery data, while actual spendability depends on the active exit rules.