[RFP] Cross-Chain Support for BTC/ETH on Solana


The Solana Foundation is looking to provide a grant/bounty to a team to build a cross-chain integration on Solana to the following digital assets:

  • Bitcoin
  • Ethereum

Interested parties can submit their expression of interest to undertake this work here.


There are several ways to implement cross-chain support on Solana for other blockchains, below are several implementations that we’d be interested in seeing:


  • The process of verifying Proof of Work history on one chain within a smart contract on another. Without the need of oracles or trusted third parties.
  • To verify a Bitcoin transaction within an Solana smart contract directly, there needs to be a few standards when dissecting both Bitcoin transactions and blocks. There are some examples of how this can be done (courtesy of Summa One) developed as open source libraries for Bitcoin-SPV and Solidity.

Overview of SPV Design Proposal (Bitcoin to Solana)

  1. Verify the Transaction Inputs & Outputs

  2. Smart Contract verifies all of the inputs and outputs of the Bitcoin transaction to ensure that the caller isn’t attempting to pass in fake outputs

  3. Extract the satoshi value of the first output, find the Solana account associated with the pubkey in the second witness, or pull data from an OP_RETURN to use for contract data calls

  4. Verify the Transaction Is Included in a Block

  5. Smart contract will then verify that the Bitcoin transaction in question has been included in a block

  6. The smart contract can use a Merkle proof of inclusion to validate the path from the root of the Merkle tree to the leaf that holds the transaction

  7. Smart contract only needs to store the header, transaction, and an inclusion proof (a few hundred bytes) to verify inclusion

  8. Verify the Block Headers

  9. Smart contract needs to verify that each block references the previous one

  10. To verify this, the smart contract takes the list of headers that we want to verify and confirms:

1. The headers contain the work that they claim to
2. Each header links to the previous one
3. The accumulated difficulty of the proof is above our security parameter.



The scope for the following would include building the relayer and smart contract from Ethereum to Solana. The design proposal for this bridge is inspired heavily by the Warp design from Solana to Tendermint chains as covered here.

MVP-Bridge v0

The initial implementation of this MVP is to build a mechanism to move tokens between a tendermint chain and Solana for the same owner. The Warp request will contain a proof that the owner of the tokens on Ethereum has control of a valid private key on Solana and vice versa. This extra layer of security reduces the likelihood that tokens are mishandled.

The Ethereum chain runs a relayer that receives transactions on the other chain, and transfers tokens from a Solana token account and vice versa. For the duration that the tokens exist on Solana, the relayer takes custody of the tokens on the Ethereum.

Example #1: Sending tokens from Ethereum to Solana

  • Relayer receives a transaction for N tokens
  • Transaction contains a note, Solana pubkey + signature
  • Relayer transfers N tokens on solana to the pubkey

If Solana signature verification fails, the relayer will transfer the tokens back to the owner on Ethereum .

Example #2: Sending tokens from Solana to Ethereum


Relayer initializes the token program on solana with u64::MAX as its supply. The max supply is under custody of the relayer account. The amount of outstanding tokens on Solana is (u64::MAX - current relayer account balance). This amount should always equal the balance of tokens in the relayer account on the tendermint chain.


  • Relayer receives a transaction for N tokens on Solana
  • Transaction contains a note, Ethereum address + signature
  • Relayer transfers N tokens on Ethereum to the address

MVP-Bridge v1

The goal of this MVP is to ensure that the proof of account ownership is verified or the transaction fails. Solana and Ethereum will use a smart contract to verify the signatures in the “note”. Transaction to move funds will fail if the signature check fails.

MVP-Bridge v2

The goal of this MVP is to reduce the trust assumptions for the relayer. Instead of adding M/N signature verification, or a more sophisticated key management for the relayer, both chains should support Cosmos IBC to move assets between each other. Conceptually, IBC is a light client implementation as a smart contract. With an IBC implementation, the relayer becomes a trustless message passing relayer between validators on both chains. The IBC smart contract verifies the consensus proof that the other chain accepted the transaction.