Protocol overview

TeleSwap is a trustless protocol for moving BTC between Bitcoin and other chains (EVM, TON, and Solana), and swapping it along the way. It does this without a centralized custodian by combining a Bitcoin light-client bridge with collateral-backed, permissionless network roles.

Bridging works by minting and burning TeleBTC — a 1:1, collateral-backed wrapped Bitcoin. The two sections below explain exactly how each step is made trustless.

Core components

Component	Role
TeleSwap contract	The on-chain entrypoint — mints/burns TeleBTC, routes swaps, accounts fees, enforces penalties
Light-client bridge	The TeleSwap Bitcoin light client — verifies on-chain that a Bitcoin transaction really happened (SPV proofs)
Lockers	Decentralized custodians that hold BTC and back TeleBTC with collateral → Lockers
Teleporters	Relay user bridge requests + inclusion proofs from Bitcoin to the destination chain → Teleporters
Relayers	Submit Bitcoin block headers to the light-client bridge → Relayers
Fillers	Provide fast, pre-confirmation settlement for fast swaps → Fillers
AMM / DEX	Swaps TeleBTC ↔ target tokens in the same transaction → AMM / DEX

Minting TeleBTC (Bitcoin → EVM/TON/Solana)

To bridge into a destination chain, a user locks BTC with a Locker and proves it on-chain. No TeleBTC exists until that proof is verified.

1. The user picks a Locker and sends BTC to it on Bitcoin, attaching a message
   (OP_RETURN) that names the recipient address and the request details
2. The transaction reaches the required Bitcoin confirmations (~20 min)
3. A proof that the transaction is included in a Bitcoin block is submitted to the
   TeleSwap contract on the destination chain — by a Teleporter, or by the user
4. The light-client bridge verifies the proof against Bitcoin's block headers
5. Only then does the TeleSwap contract mint TeleBTC to the recipient named in the
   message, minus locker + protocol fees (for a swap, it then routes TeleBTC → the
   target token via the AMM)

Why this is trustless: the contract mints TeleBTC only after its own light-client bridge confirms a real, sufficiently-confirmed Bitcoin deposit. No operator can mint unbacked TeleBTC, and the recipient is fixed by the on-chain Bitcoin message — not by whoever relays the proof.

Burning TeleBTC (EVM/TON/Solana → Bitcoin)

To redeem BTC, a user burns TeleBTC, which creates a burn request that a Locker must fulfil on Bitcoin before a deadline — or be slashed.

1. The user calls the TeleSwap contract, burning TeleBTC and naming a BTC recipient
   and a Locker. This creates a burn request with a deadline
2. The contract burns the TeleBTC immediately and deducts fees
3. Before the deadline, the assigned Locker sends native BTC to the recipient on
   Bitcoin and submits proof of that payment to the TeleSwap contract
4. The light-client bridge verifies the proof and the request is marked processed
5. If the Locker misses the deadline (or never pays), anyone can trigger
   slashing — the Locker's collateral compensates the user

Why this is trustless: the TeleBTC is destroyed up front, so supply always matches custodied BTC. The Locker is contractually obligated to pay out before the deadline, and its collateral is slashable if it doesn't — so the user is made whole either in BTC or from collateral, without trusting the Locker's good behaviour.

Swapping

Either direction can be combined with a swap in a single transaction — BTC → any supported token, or any supported token → BTC — routed through the AMM/DEX. For the Bitcoin → other-chains direction, fast swaps deliver tokens in ~10 minutes (one Bitcoin confirmation instead of two).

Why the protocol is trustless

• Bitcoin-anchored — nothing mints or completes a redemption unless the light-client bridge has verified a real Bitcoin transaction on-chain.
• Collateral-backed — TeleBTC is backed by Locker collateral worth more than the BTC held; misbehavior is punished by slashing & liquidation.
• Permissionless — anyone can run a relayer, teleporter, locker, or filler, so no single party can censor or capture the protocol.

See the Security model for the full trust assumptions.