# Trust-minimized blockchain connections

TeleportDAO serves as a light-client bridge, facilitating the connection between one blockchain (called source chain) to another (called target chain). This capability empowers applications on the target chain to access data from the source chain in a secure and trust-minimized manner. For instance, a decentralized exchange (DEX) on the target chain could retrieve the latest exchange rates from a DEX operating on the source chain and provide identical rates to its users. TeleportDAO aims to streamline the development of innovative cross-chain applications, enabling seamless communication between smart contracts on different chains or access to each other's state.

## Bridges aren't secure. What can be done?

While many bridges utilize a validator-based approach to connect blockchains, TeleportDAO employs light-client verification due to its significant advantages over the validator-based approach. Light-client verification offers a secure and trust-minimized method for verifying data from one blockchain without requiring access to the whole blockchain data. This verification method mirrors the process used by light client nodes, which lack access to the full blockchain data due to limited computational and storage resources. In TeleportDAO, light client verification is implemented as a smart contract, enabling the contract to verify data from the source chain without requiring heavy computational resources.

## What role does TeleportDAO play in the multi-chain world?

TeleportDAO is the most secure, trust-minimized interoperability protocol between blockchains, facilitating the development of innovative cross-chain applications.

1. **Secure as underlying chains**: In TeleportDAO, the bridge contract (known as the Relay contract) relies on the target chain to verify data belonging to the source chain by ensuring that the data follows to the consensus rules of the source chain. The only way to deceive the bridge is by providing data that passes the consensus checks but doesn't truly belong to the source chain. This implies that the attacker could potentially compromise the security of the source chain itself. Therefore, as long as the source chain remains secure, the TeleportDAO bridge remains secure.
2. **Trust-minimized approach**: In TeleportDAO, the verification of data from the source chain submitted to the Relay contract is conducted by the contract itself. Anyone can provide the data from the source chain, and the bridge contract verifies it based on predetermined rules. If the provided data doesn't follow to the source chain's consensus rules, the bridge contract rejects it. This makes TeleportDAO trust-minimized, as all verification is performed by the smart contract, and the bridge does not depend on any external nodes for data verification.
3. **Access all data of other chains**: Through TeleportDAO, any user or application on the target chain can verify the inclusion of specific data on the source chain. For instance, a smart contract can verify the latest balance of a user on the source chain, or another smart contract can confirm whether funds have been transferred to a particular address on the source chain. This capability enables the development of numerous cross-chain applications where smart contracts reside on multiple blockchains and can verify the state of each other.


# Light-client vs validator-based bridges

There are two main approaches to building blockchain bridges: the light-client approach and the validator-based approach. The primary difference lies in how the bridge, which relies on the target chain, verifies data belonging to the source chain. In Validator-based bridges, this validation is performed by validator nodes, acting as a layer between the source chain and the target chain. However, in Light-client bridges, this verification is conducted by the bridge contract itself. While there are nodes that provide source chain data to the bridge contract, they serve solely as relayers of data, not as verifiers.

## Why TeleportDAO opts for the light-client approach?

TeleportDAO employs light-client verification to connect blockchains. Instead of relying on third parties for cross-chain verification, we utilize predefined smart contract rules for this purpose. The light-client approach provides distinct advantages over validator-based architectures.

### **Security**

Validator-based bridges rely on a set of validators to verify cross-chain data. Flaws in the security of these validators, such as a potential leak of their private keys, could result in million-dollar hacks. However, in light-client solutions, verification of cross-chain data is performed by smart contracts. Network nodes provide input for the bridge contract, and the contract checks data validity based on predefined rules. Therefore, the security of the protocol is not tied to the security of third-party nodes.

### **Capital efficiency**

Ensuring the security of validator-based bridges by holding validator nodes accountable for their services requires locking a significant amount of capital by them. The required capital also increases if the bridge intends to transfer higher value from one chain to another. This is because the security of the bridge is dependent on the locked value. In contrast, in light-client bridges, security doesn’t rely on third-party nodes. Network nodes merely provide input for the smart contract, and any incorrect input would be detected and rejected by the smart contract. Thus, they don’t require locking any collateral. Additionally, the security of the bridge is independent of network nodes, allowing the bridge to transfer any value from one chain to another.

### **Decentralization**

Validator-based bridges are maintained by a set of validators. These validators could collude together to censor some users and transactions; for example, they may not allow a user to move funds from one chain to another. On the other hand, in light client bridges, anyone can contribute to maintaining the bridge by providing the source chain data to the bridge contract. Also, as there is no collateral requirement here, it makes it very easy for new nodes to join the network. Therefore, it is not possible to prevent a user from moving assets from one chain to another.


# TeleportDAO ecosystem

The TeleportDAO bridge enables building secure cross-chain applications, allowing an application on one chain to verify any data belonging to another chain. It could be used to build basic applications like asset transfers between chains to more complex applications where their smart contracts reside on multiple blockchains. Here, we briefly explain applications powered by the TeleportDAO bridge.

## TeleSwap - decentralized liquidity protocol for Bitcoin and BRC-20s

**Website**: <https://teleswap.xyz/>

**Token**: [TST (Teleport System Token)](https://docs.teleswap.xyz/hello-teleswap/tst-teleport-system-token)

TeleSwap is a decentralized protocol for bridging BTC and BRC-20s (Bitcoin tokens) to EVM blockchains. It enables users to trade Bitcoin assets with ERC-20s in a cost-efficient and fast manner.

TeleSwap utilizes the TeleportDAO bridge to validate Bitcoin transactions on EVM blockchains. This enables it to verify whether users deposit their Bitcoin assets on Bitcoin to receive wrapped assets on the EVM chain. Additionally, it leverages the bridge to ensure that TeleSwap nodes process users' unwrap requests and send them their requested assets on Bitcoin. Moreover, if a TeleSwap node behaves maliciously by moving funds on Bitcoin, anyone can provide evidence of dishonesty, which is checked against the bridge.

## TeleOrdinal - cross-chain marketplace for Ordinals (Bitcoin NFTs)

**Website**: <https://teleordinal.xyz/>

**Token**: [TST (Teleport System Token)](https://docs.teleordinal.xyz/hello-teleordinal/tst-teleport-system-token)

TeleOrdinal is a decentralized marketplace that extends the Ordinals (Bitcoin NFTs) and BRC-20s (Bitcoin tokens) market beyond Bitcoin to EVM chains. It represents the first cross-chain marketplace where users can purchase Ordinals using ERC-20s or sell their Ordinals to EVM users.

TeleOrdinal leverages the TeleportDAO bridge to verify the transfer of Ordinal ownership on Bitcoin. Therefore, when a buyer requests to purchase an Ordinal, the seller must transfer the Ordinal on Bitcoin and provide proof of transfer to receive the buyer's funds on EVM. The proof of transfer is validated by the bridge, as it allows any application on the EVM side to access Bitcoin data.


# Contract addresses

## Mainnet

### BOB

| Name         | Address                                    |
| ------------ | ------------------------------------------ |
| BitcoinRelay | 0xec4A7D93750BbcE2A07fd1bc748507ea645e9d52 |

### BSquared

| Name         | Address                                    |
| ------------ | ------------------------------------------ |
| BitcoinRelay | 0xDd833309e9E9EAd3a7c4520D53e02e685C3751eB |

### Polygon

| Name         | Address                                    |
| ------------ | ------------------------------------------ |
| BitcoinRelay | 0x7DeB66341b1d499D7e699589d0cf665De4132EA3 |

### BNB Chain

| Name         | Address                                    |
| ------------ | ------------------------------------------ |
| BitcoinRelay | 0xFcd688999c25D5493571543137cEeb4fbDb44D02 |

### Celo

| Name          | Address                                    |
| ------------- | ------------------------------------------ |
| EthereumRelay | 0x26AF4946A0509369D763B43b296753d27F973672 |

## Testnet

### Amoy

| Name         | Address                                    |
| ------------ | ------------------------------------------ |
| BitcoinRelay | 0xE0166434A2ad67536B5FdAFCc9a6C1B41CC5e085 |


# Protocol overview

TeleportDAO is a light-client bridge protocol that connects the source chain to the target chain in a secure and trustless manner. The main components of the protocol are the Relay contract and Relayer nodes. Relayer nodes submit source chain data to the Relay contract, which lives on the target chain. The Relay contract then verifies the validity of the submitted data against the consensus rules of the source chain. Invalid data is rejected by the Relay, while valid data is stored by it.

<figure><img src="https://lh7-us.googleusercontent.com/w8QuBvliJSn87CnIA6rLQidcP2rGUuAM9GK4i4BpMZExZxgHpZMObOh6Wo3yOzkh54dK7A8yG-yhijRtF0z5SK1AX4N2YkpUCGXQy9F7LTkSDMTt4ej10m9mpJiXirS1XrcSABbCIypp9mCxytn6iYA" alt=""><figcaption><p>An overview of how Relay and Relayer work together</p></figcaption></figure>

The Relay contract rewards Relayers who submit valid data from the source chain. This incentivizes Relayers to provide valid source chain data promptly after its inclusion on the source chain. Additionally, this discourages Relayers from submitting invalid data, as their data will eventually be rejected by the Relay contract, resulting in no reward and only loss of transaction fees.

Users and applications on the target chain can utilize the Relay to verify the inclusion of certain data on the source chain, such as user balances, smart contract states, included transactions, block timestamps, etc. Furthermore, an application on the source chain can send messages to an application on the target chain. A user can notify the target chain application of this message, where the target application can verify the message's validity using the Relay contract.

To utilize the Relay, users need to pay a bridging fee, which is collected by the bridge. This fee is then distributed among Relayer nodes who provided valid data beforehand. As the number of Relay users increases, the cost of using the Relay decreases for users.


# Relay contract

At the core of TeleportDAO lies the Relay contract. This contract, residing on the target chain, is responsible for verifying the source chain data. Maintained by Relayers who submit the source chain data to it, the Relay contract verifies the data against the consensus rules of the source chain. The Relay contract is essentially the smart contract implementation of the source chain's light-client protocol, a protocol run by light nodes of blockchains.

## Why is it called a light client?

In the blockchain system, there exist two types of nodes: full nodes and light nodes. Full nodes receive the entire blockchain block and verify that it follows the consensus rules, is compatible with previous blocks, and only includes valid transactions. They require significant storage and computational resources to verify the entire blockchain data.

On the other hand, light nodes only receive a portion of the blockchain data, usually the block headers, and verify them against the consensus rules and previous block headers. They don't verify the validity of transactions inside the block. They can use the block header to check the inclusion of some data on the blockchain, eliminating the need to trust others for data inclusion verification. This allows them to check data inclusion with minimal computational and storage resources. Although they cannot contribute to blockchain mining as they don’t access all transactions and cannot verify the validity of new transactions coming, they can efficiently verify data about the blockchain's past.

## What are the verification steps?

Relayers submit source chain block headers to the Relay contract. This block header is verified by Relay and marked as valid if it follows the source chain's consensus rules. However, the block header is still not finalized at this point, meaning there is still a chance that this block header might be excluded from the source blockchain in the future. After a few more valid headers are submitted on top of a valid header, it is marked as a finalized block header. This indicates that this block will not be removed from the source chain in the future. The Relay contract rewards Relayers once their submitted block header becomes finalized.

While it's generally safer for applications to verify data inclusion against finalized block headers, this approach may not be suitable for all applications. It takes time for a valid header to become finalized, which might not be acceptable for certain applications with strict time constraints. In such cases, these applications might opt to accept data included in non-finalized block headers to process requests more rapidly, relying on the likelihood that a valid header will eventually become finalized. This trade-off between speed and security becomes important when speed takes priority over absolute security, and the application can tolerate a certain margin of error.


# Relayer nodes

Relayer nodes maintain the bridge by retrieving data from the source chain and submitting it to the target chain. These nodes provide input for the Relay contract, which verifies the provided input and stores it only if it passes certain checks. In most cases, the data that Relayers provides is the block header of the source blockchain.

Anyone can become a Relayer in TeleportDAO by running the Relayer script. This decentralizes the TeleportDAO protocol. The script is lightweight and can be run on a small server. Relayers who provide valid source chain data faster for the Relay contract would be rewarded.

## How many honest Relayer should be there?

Relayers provide the necessary input for the Relay contract. Without Relayers, the bridge cannot remain synchronized with the source blockchain. In fact, only one honest Relayer is needed for a safe and operational bridge, making this requirement minimal. Other bridging protocols typically require many honest nodes, often with a considerable amount of collateral locked. Here, we only need one honest node, which doesn’t even need to lock any collateral.

### **Liveness**

For the relay to be live, we need at least one honest Relayer to submit the latest data from the source chain to the relay. As the network of Relayers is decentralized and anyone can become a Relayer by running the Relayer script, we expect that at any time, at least one honest Relayer exists. We recommend applications using the relay to run their own Relayer node to increase system reliability.

### **Safety**

Relayers submit data from the source chain to the relay contract. The relay contract then verifies the validity of the submitted data against the consensus rules of the source chain and only accepts valid data. If a Relayer submits invalid data, it would be rejected by the contract, and the Relayer loses funds. Therefore, no one can submit the wrong data to the relay. However, if there is no honest Relayer in the system, a malicious Relayer can generate some source chain data that follows the consensus rules but is not included in the source chain. To avoid this scenario, there is a need for at least one honest Relayer to submit the latest data from the source chain within a reasonable time frame. The protocol can manage a slight delay in Relayer operation, as it is not easy for malicious Relayers to generate valid source chain data that is not part of the source chain.


# Bridge fee & reward

Any user or application on the target chain can query the bridge to verify the inclusion of specific data on the source chain. To obtain the result for their query, they need to pay the bridge fee. This fee compensates the Relayers who provide the Relay contract with the source chain data. As the number of queries increases, the fee for each query decreases. Therefore, the bridge fee decreases in the long term as more users and applications leverage the bridge.

## How the bridge fee is calculated?

Relayers maintain the bridge by continuously submitting source chain data to the Relay contract. They pay a transaction fee on the target chain to submit this data. Therefore, we need to compensate Relayers for their services and costs, including the transaction fees they pay.

TeleportDAO compensates Relayers by charging a fee to users and applications that query the bridge. We estimate the bridge fee in epochs, using the number of users from the previous epoch to determine the fee in the new epoch. Therefore, if there were many users in the previous epoch, the fee for querying the bridge decreases in the current epoch. Conversely, if there were few queries in the previous epoch, the query fee increases in the current epoch.

The bridge fee in the current epoch is calculated as follows:

$BridgeFee = K*SubmissionGas*GasPrice\*EpochBlocks/PrevEpochQueries$

$$
BridgeFee = K*SubmissionGas*GasPrice\*EpochBlocks/PrevEpochQueries
$$

Where:

* *SubmissionGas*: Gas usage for submitting a source block header on the target chain
* *GasPrice*: Gas price at the moment of submitting the block header
* *EpochBlocks*: Number of blocks per epoch
* *PrevEpochQueries*: Number of queries to the bridge in the previous epoch

## What is the reward of Relayers?

Relayers play a crucial role in providing necessary input for the Relay contract by fetching data from the source chain and submitting it to the target chain. Their primary expense is the transaction fee they incur on the target chain. The reward for Relayers compensates them for this expense and provides them with additional earnings.

For each block header, the first Relayer who successfully submits it to the target chain will receive a reward. This creates incentives for Relayers to promptly submit valid source chain data. Additionally, the reward is disbursed to them once their block header is finalized on the Relay. Therefore, not all valid headers submitted by Relayers will be rewarded; only those that eventually become finalized will receive the reward.

The Relayer reward is calculated as follows:

$$
BridgeReward = K*SubmissionGas*GasPrice
$$

Where:

* *SubmissionGas*: Gas usage for submitting a source block header on the target chain
* *GasPrice*: Gas price at the moment of submitting the block header


# Bitcoin bridge

The TeleportDAO Bitcoin bridge establishes connections between Bitcoin and EVM-compatible chains, including Bitcoin L2s, while maintaining Bitcoin-grade security. This bridge facilitates the development of various cross-chain applications for Bitcoin, such as Bitcoin and Ordinal wrapping, BRC-20 trading, Bitcoin lending, and Bitcoin-backed stablecoins, among others.

## **How does the Bitcoin bridge validate data?**

To operate this bridge, Relayer nodes retrieve the latest block headers of Bitcoin and submit them to the Relay contract. Initially, these headers are stored as valid block headers and later transition to finalized block headers.

### **Valid block header**

When a block header is submitted, the bridge validates it against Bitcoin's Proof-of-Work rules. The Relay contract verifies that:

1. The block header correctly references a previously submitted header.
2. The header demonstrates sufficient work has been completed.
3. Difficulty retargeting has been executed correctly.
4. Additional checks ensure the header hasn't been submitted before and the block number isn't too old.

If a block header passes all checks, it is considered valid. However, there is still a chance that a valid header may be excluded from Bitcoin. It remains permanently on Relay if it becomes a finalized header.

### **Finalized block header**

Each time a valid block header is added, the Relay contract verifies whether a previous block header has been finalized. To do so, Relay applies Bitcoin's longest chain rule, meaning a header is finalized if it is buried under 6 consecutive valid block headers. Once a block header is finalized, it remains on Relay indefinitely. At this stage, the Relay contract also rewards the Relayer who submitted the finalized block header.

The Relay contract prohibits Relayers from submitting block headers at a height where a finalized header already exists. Relayers can only submit block headers belonging to a height greater than the last finalized height.


# Build on Bitcoin bridge

Any application or user on the target chain can utilize the bridge to verify the inclusion of a particular transaction on Bitcoin. For instance, a user could demonstrate to a smart contract that a specific amount of BTC has been transferred to a particular address on Bitcoin. Additionally, a user might showcase ownership of a unique Ordinal on Bitcoin to the contract. To initiate a query to the bridge and confirm the inclusion of a specific transaction ID on Bitcoin, the user must pay the bridge fee, which is collected in the native token of the target chain.

## Transaction inclusion query

The Bitcoin Relay has a function called `checkTxProof` that can be used to check the inclusion of a transaction in a block:

```solidity
function checkTxProof(
    bytes32 txid,
    uint blockHeight,
    bytes calldata intermediateNodes,
    uint index
) external payable returns (bool);
```

Where:

* `txid` is the double hash of a Bitcoin transaction.
* `blockHeight` is the height of the block that includes the transaction.
* `intermediateNodes` is the Merkle inclusion proof of `txid` in the block.
* `index` is the index of `txid` in the transactions of the block.


# Ethereum bridge

The TeleportDAO Ethereum bridge functions as an optimistic light client bridge, linking Ethereum to EVM chains. This integration allows any application on the EVM chain to verify Ethereum data inclusion in a trust-minimized manner. Operating as an implementation of the Ethereum Sync protocol through smart contracts, our bridge adopts an optimistic approach, reducing gas consumption by executing checks only during challenges rather than for every block submission.

The Sync protocol was introduced to Ethereum to enhance light client compatibility. Each Sync epoch selects 512 validators as the Sync committee, responsible for signing valid block headers. This setup enables light clients to verify header validity when signed by a majority of the sync committee.

## **Leveraging an optimistic approach to reduce costs**

In our Ethereum bridge, Relayers submit new Ethereum block headers to the Relay contract without immediate verification. Instead, a challenge period is initiated, allowing anyone, including other Relayers, to challenge the validity of the block header.

Both the submitting Relayer and the challenger must lock a certain amount of collateral. The Relayer must then prove the validity of the block header by providing additional information. Failure to do so within the challenge period results in rejection of the block header by Relay, leading to the Relayer losing their collateral. Conversely, if successful, the challenger loses their collateral, and the block header is deemed valid.

## **Validating ethereum block headers**

Relayers submit Ethereum block headers to the Relay contract, consisting of two types:

### **Super blocks**

If a block header is signed by over 90% of the Sync committee, it qualifies as a super block header. The Relayer submits the block header, claiming it as a super block header, initiating a challenge period. During this period, other users can dispute the block. In case of dispute, the Relayer must provide the Sync committee's signature to the contract. If the block header is signed by over 90% of the committee, the challenger's dispute is rejected; otherwise, the Relayer's claim is rejected.

Once a super block is accepted by Relay, it points to a last finalized checkpoint, a block permanently part of the Ethereum chain.

### **Finalized blocks**

Following the acceptance of a new finalized checkpoint, Relayers submit other finalized block headers between the last finalized checkpoint and the previous one. Starting from the last finalized checkpoint and moving backward, Relayers ensure Relay has access to all finalized Ethereum block headers. Applications can utilize finalized headers to confirm data inclusion on Ethereum.

## **Updating Ethereum Sync Committee**

To verify signatures against block headers, the Relay contract requires knowledge of the current Sync committee. Ethereum includes both the current and next Sync committees in each block. When a block header becomes finalized, a Relayer submits the next Sync committee to the Relay contract, proving its inclusion in the finalized block.


# Audit reports

You can find reports of audits performed on the TeleportDAO bridge [here](https://github.com/TeleportDAO/audits/tree/main/reports).

| Name                       | Version | Auditor    |
| -------------------------- | ------- | ---------- |
| TeleportDAO Bitcoin bridge | 1.0.0   | Quantstamp |