Bridgeless

• Name: Bridgeless
• URL: https://bridgeless.com/
• Category: operator-run bridge stack / Cosmos-settlement-chain committee bridge
• Tags: cosmos-ecosystem bitcoin-ecosystem ethereum-ecosystem solana-ecosystem
• Summary: Bridgeless is a small committee bridge with its own Cosmos settlement chain. Ignore the name. The real subject is validator admission, supported-chain policy, and threshold-key handling around that ledger. Useful specimen, not an interoperability anchor.
• What it does:
  • Bridges assets across Bitcoin, EVM chains, Solana, TON, and Zano through a protocol with its own settlement ledger
  • Records bridge state on a dedicated Cosmos-SDK / Tendermint chain rather than outsourcing coordination to another base layer
  • Uses validator nodes plus threshold-signature participants to verify deposits, coordinate withdrawals, and handle key changes or producer turnover
  • Publishes operator docs for validator setup, staking, and TSS configuration rather than presenting only an app-level transfer surface
  • Exposes chain-specific bridging flows plus supporting operator infrastructure such as RPC, databases, message brokers, and Vault-backed key-share handling
• Key claims:
  • The homepage says Bridgeless moves assets across Bitcoin, EVM, Solana, TON, and privacy chains with No custodians, threshold signatures in which the private key never exists in one place, and formally proven security
  • The docs say deposits and withdrawals are recorded on a dedicated Cosmos-SDK chain with Tendermint BFT consensus, which makes the settlement chain a primary trust and control surface
  • The architecture docs describe validator nodes, threshold-signature producers, RPC providers, databases, message brokers, and blockchain-core services as first-class parts of the system
  • The validator guide says operators must create validator keys, receive tokens from the team, and stake a fixed amount of abridge to participate in consensus
  • The TSS docs say participants must share session parameters and coordinate threshold key generation, with generated key shares optionally stored in Vault
• Whitepaper: Official whitepaper exists and is saved locally as ../whitepapers/bridgeless-whitepaper.pdf. The most useful directly inspected materials in this pass were the homepage, docs hub, architecture overview, validator guide, and TSS key-generation docs; see ../whitepapers/bridgeless-primary-sources-2026-05-01.md.
• Sources:
  • https://bridgeless.com/
  • https://docs.bridgeless.com/
  • https://docs.bridgeless.com/docs/specs/arch/architecture
  • https://docs.bridgeless.com/docs/tutorial/mainnet/become-validator
  • https://docs.bridgeless.com/docs/tutorial/tss/run/keygen
  • https://bridgeless.com/bridgeless-whitepaper.pdf
  • https://arxiv.org/pdf/2506.19730

Internal linkages

• Keep this note on a short leash.
• Best upward reads: axelar for operator-run bridge coordination and hyperbridge for the proof-heavy contrast.

Control surface

• Control sits in validator and TSS admission, threshold settings, supported-chain policy, key rotation, and any emergency powers around the settlement chain.

• No custodians is marketing. The real question is who controls the signer set, settlement chain, and chain-admission policy.

• Read Bridgeless as a small operator-run bridge system, not as a neutral rail.

• Last reviewed: 2026-06-13 UTC