Bridgeless Protocol: Cross-Chain Bridging

• Bridgeless Protocol is a formally defined framework for secure cross-chain token bridging using explicit state machines and modular subprotocols.
• It employs validator consensus and threshold signatures to ensure asset safety and maintain protocol liveness across diverse blockchain networks.
• The protocol’s chain-agnostic design supports EVM, Zano, and Bitcoin systems, facilitating versatile applications in decentralized finance and asset tokenization.

The Bridgeless Protocol is a formally specified cross-chain token bridging protocol designed for compatibility across a diverse set of blockchains, including EVM-compatible networks, Zano, and Bitcoin. It is governed by a validator set that collectively verifies deposits on a source chain and coordinates withdrawals on a target chain, ensuring chain-agnostic operation and strong safety and liveness guarantees. The protocol’s architecture is based on explicit state machines and modular subprotocols, with rigorously analyzed conditions for correct and secure interchain asset transfer (2506.19730).

1. Protocol Formalization and State Transition Structure

The Bridgeless Protocol is defined through explicit state machines and typed data structures governing cross-chain requests. Validators maintain a mapping from each deposit identifier—comprising the tuple $$(\mathit{txHash}, \mathit{txNonce}, \mathit{chainID})$$—to a structured RequestData entry. Request data is decomposed into:

• DepositData: $$(\mathit{tokenAddr}, \mathit{amount}, \mathit{sourceAddr}, \mathit{targetAddr}, \mathit{targetChain})$$
• WithdrawalData: Stores cryptographic material required for withdrawal (e.g., $\mathit{signHash}$, $\mathit{signature}$, signing participant set)

Each bridging request transitions through a finite state machine:

State	Role
INVALID	Unrecognized/invalid request
PENDING	Deposit detected and verified
PROCESSING	In consensus/signing phase for withdrawal
PROCESSED	Signature generated, ready for submission
FINALIZED	Withdrawal submitted and acknowledged

State transitions are governed by rigorously formalized routines, and algorithmic details are specified via pseudocode for all critical operations (Algorithms 1–7 in the paper). For example, the consensus phase is executed via a reliable broadcast of $(\mathit{depositId}, \mathit{signHash})$, and signing proceeds via threshold signature routines that provide cryptographic assurance.

2. Security Proofs: Safety and Liveness Analysis

Security properties are established through a series of lemmas and theorems, leveraging assumptions from Byzantine consensus and threshold cryptography. The core security criteria are:

• Bridge Liveness: Every properly formed request initiated by an honest party is eventually processed to completion, provided network synchrony and validator honesty thresholds are met. Formally, after $r$ rounds, the probability of finalization is $1 - (1 - P(\text{success}))^r$, where $$P(\text{success}) \geq \prod_{i=1}^t \frac{n-i-t}{n-i}$$ for $t$ faulty validators and $n \geq 3t$.
• Bridge Safety: No withdrawal is ever executed unless a corresponding deposit has been finalized on the source chain, enforced by validator-side agreement on request state and signature validity.

Validator operations are further constrained by explicit timeouts for each protocol phase (CONSENSUSBOUNDARY, SIGNBOUNDARY, FINALIZATIONBOUNDARY), and the system maintains safety and liveness under standard Byzantine assumptions ($n \geq 3t$ with at most $t$ faulty validators), as long as network synchrony is maintained.

3. Validator Responsibilities and Subprotocol Workflow

Validators are the central actors maintaining the protocol's security and correctness. Their principal tasks are:

• Deposit Verification: Each validator, upon receiving a withdrawal request, independently queries the relevant blockchain using a ChainClient abstraction. This module ensures the deposit is finalized (i.e., confirmed and immutable according to chain-specific criteria) before the request is marked as PENDING.
• Consensus Phase: Through a deterministic proposer selection, validators achieve agreement on the withdrawal execution parameters (such as $\mathit{signHash}$) using a reliable broadcast primitive. If sufficient validators (at least $t+1$) respond, a signing committee is formed.
• Signing Phase: The signing committee executes a threshold signature protocol (such as ECDSA TSS), producing a signature over $\mathit{signHash}$ that is verifiable on the target chain.
• Finalization Phase: The final transaction is constructed and broadcast on the target chain, at which point the request is marked FINALIZED by all honest validators.

This workflow ensures atomicity and resistance to equivocation, as a withdrawal can only be submitted upon reaching finality in all phases.

4. Chain-Agnostic Design and Implementation Abstraction

A distinguishing feature of the Bridgeless Protocol is its chain-agnostic compatibility, realized through the ChainClient abstraction:

• EVM Chains: Specialized smart contracts are deployed for deposit and withdrawal events, supporting standard token operations and event-driven deposit detection.
• Zano: Deposits take the form of token burns, with target address and chain encoded in special service entries.
• Bitcoin: Deposits are made using UTXO transactions, with OP_RETURN used for encoding target info; withdrawals are constructed using standard UTXO scripting.

Regardless of underlying blockchain, the ChainClient defines a common interface: getDepositData(), getWithdrawalTx(), getHashOfWithdrawal(), and submitTx(). Each implementation adapts the underlying protocol to comply with the respective blockchain’s semantics, ensuring a uniform bridging logic across highly heterogeneous environments.

5. Safety and Liveness Preconditions

Ensuring protocol integrity requires several critical network and system-level conditions:

• Safety: Relies on synchronous communication for protocol rounds, correct implementation of the ChainClient interface, and at most $t < n/3$ faulty validators.
• Liveness: Guaranteed provided that message delivery in each phase completes within predetermined timeouts and a supermajority of honest validators remain active.
• Validator Agreement: All honest validators independently verify and record consistent status transitions for each request, preventing forks or replay attacks.
• Chain-specific Finality: Deposit validation and withdrawal construction are parameterized by chain-specific mechanisms for finality and event detection, but all are abstracted behind the common protocol structure.

6. Subprotocol Modularization and Algorithms

The protocol is decomposed into two principal subprotocols, each further partitioned into phases:

• A. Deposit Verification Subprotocol
  • Input: Deposit identifier from the client
  • Action: Validators query source chain for finalization, then mark request as PENDING
• B. Withdrawal Generation Subprotocol
  • Consists of:
  • i. Consensus: Coordinator proposes withdrawal execution to validators; upon acceptance, a signing committee is selected.
  • ii. Signing: Threshold signature generation, with validity broadcasted and verified.
  • iii. Finalization: Validators submit and mutually acknowledge the completion on the target chain.

Each subprotocol is justified by a set of correctness lemmas ensuring consensus, termination, and fault tolerance. Algorithmic pseudocode and state-transitions are given for all steps, allowing for formal verification, code generation, or model checking.

7. Implications, Applicability, and Summary

The Bridgeless Protocol provides a modular, formally verified framework for token bridging across multiple blockchain ecosystems. By rigorously defining the validator workflow, relying on threshold cryptography, and supporting chain-agnostic interfaces, it addresses critical issues of asset safety, atomicity, and protocol liveness. Its formalization and set of security proofs offer performance and correctness guarantees relevant to a wide range of interchain applications, including payments, DeFi composability, and asset tokenization.

This approach establishes a reference model for robust cross-chain protocols that must maintain consistent safety and liveness guarantees even in adversarial environments, and its modular abstractions facilitate future extensions to additional chains or more complex asset types (2506.19730).