Bridgeless primary sources — 2026-05-01

Project status in this pass

• Official whitepaper exists and has been saved locally as bridgeless-whitepaper.pdf.
• The clearest current operational source of truth was the docs corpus, especially the architecture, validator, and TSS setup sections.

Primary-source snapshots

1) Official homepage

• URL: https://bridgeless.com/
• Key excerpts/signals:
  • Says Bridgeless bridges assets across Bitcoin, EVM, Solana, TON, and privacy chains.
  • Says there are “No custodians” and that threshold signatures are used “where the private key never exists.”
  • Says every deposit and withdrawal is recorded on a dedicated Cosmos SDK chain with Tendermint BFT consensus.
• Why it mattered:
  • The homepage quickly establishes that Bridgeless wants to be understood as protocol infrastructure with its own settlement layer, not just as a bridge UI.

2) Docs hub

• URL: https://docs.bridgeless.com/
• Key excerpts/signals:
  • Describes the docs as covering architecture specs, integration guides, validator setup, and threshold-signature configuration.
  • Surfaces chain-specific integration guides for EVM, Bitcoin, Solana, TON, and Zano.
  • Links both an official whitepaper PDF and an external review paper.
• Why it mattered:
  • The docs hub is unusually revealing because it exposes both the user/integration side and the operator side in one place.

3) Architecture overview

• URL: https://docs.bridgeless.com/docs/specs/arch/architecture
• Key excerpts/signals:
  • Lists RPC providers, databases/message brokers, a threshold signature service, and a blockchain core service as key components.
  • Says validator nodes use delegated proof of stake and manage protocol-defined data, staking, distribution, and configuration.
  • Says threshold-signature producers retrieve transaction data, handle deposit verification and withdrawal signing/submission, and manage liquidity migration and key regeneration.
• Why it mattered:
  • This page makes clear that the product is an operating stack with multiple coordinated components, not merely an asset-routing contract.

4) Mainnet validator guide

• URL: https://docs.bridgeless.com/docs/tutorial/mainnet/become-validator
• Key excerpts/signals:
  • Says operators must generate validator keys and back up the keyring.
  • Says aspiring validators should share their bridge... address with the team to receive tokens required for validator creation.
  • Says operators must stake exactly 1280000000000000000000000abridge, described on-page as 1,280,000 BRIDGE, to become a validator.
• Why it mattered:
  • This is strong evidence that Bridgeless runs a real validator/admission process rather than only publishing conceptual bridge docs.

5) TSS key-generation guide

• URL: https://docs.bridgeless.com/docs/tutorial/tss/run/keygen
• Key excerpts/signals:
  • Describes TSS key generation as the crucial first step where key shares are generated and distributed among participants.
  • Says the configuration fields must match across all parties and that at least threshold + 1 parties are required for signing.
  • Shows commands for preparameter generation, keygen startup, and retrieving the resulting TSS public key from Vault.
• Why it mattered:
  • This page is one of the clearest operational clues that the protocol is centered on a threshold-signing coordinator architecture.

6) Official whitepaper PDF

• URL: https://bridgeless.com/bridgeless-whitepaper.pdf
• Notes:
  • Saved locally during this pass as research/crypto/whitepapers/bridgeless-whitepaper.pdf.
  • The docs hub itself labels this as the canonical protocol-design whitepaper.
• Why it mattered:
  • Even without deep PDF extraction in this pass, the presence of a first-party whitepaper materially strengthens Bridgeless as a protocol-level catalog entry.

7) External review paper

• URL: https://arxiv.org/pdf/2506.19730
• Notes:
  • Linked directly from the docs hub as a security/review paper.
• Why it mattered:
  • This is a useful adjacent primary-ish source because the official docs chose to surface it as part of the project’s trust and technical-review story.

Working conclusion

Bridgeless is best cataloged as threshold-signature bridge infrastructure with its own validator-governed settlement chain. The strongest signal in this pass was the combination of homepage claims and highly operational docs: validator admission, TSS keygen, chain-specific bridge flows, and an official whitepaper all point to a full bridge-control-plane stack rather than a lightweight bridge frontend.