[RFP] Cross-Chain Bridge Support for Terra / Solana

The Solana Foundation in collaboration with Terra are looking to offer a grant/bounty to a team interested in building a cross-chain integration for Terra.

Individuals or teams interested in undertaking this grant/bounty please email:

Provided below is the specification for the design. The specification was developed by the Terra team.

Specifications - ‘Shuttle Bridge’

The purpose of shuttle is to create a lightweight token and message transfer protocol among an arbitrary set of blockchains.

Let R be the set of relayers in the system and B the set of supported blockchains.

  • A user can transfer a token issued in any member of B to any other member of B.
  • A user can transfer a message signed in any member of B to any other member of B, provided that the message is sufficiently short.

The system guarantees honest delivery insofar as a sufficiently large (e.g. majority) of the voting power in R “validates” the transfer.

Prior Work
There exists three broad categories for moving assets across chains: atomic swaps, synthetics, and tokenized representations. We review the prior work of “tokenized representations” specifically.

Ren Protocol

Cosmos/Althea Peggy

Near Protocol Rainbow bridge

Ren protocol especially comes closest to what we want to build, but it has the following drawbacks:

  1. MPC is too complicated: Replicating consensus state across multiple chains is hard
  2. Token transfers only: Ren only supports token transfers (for now), but this can easily be extended to support generalized messaging
  3. Can charge holding fee: Ren nodes (run entirely by the core team) may elect to charge a “holding fee” for custodying assets. This is destructive, as hold fees could trigger margin calls etc.

We propose a bridging framework similar to Ren, but:

  1. Supports generalized messaging

  2. Only transaction fees, no holding fees 3) Vastly simplified consensus

The system comprises of:

Launchpad contracts: For each of the chains in B, there exists a “launchpad contract” used by the sender to invoke functions on receiving chains. The only supported function is:

  • Send(chain_id,function_id,toll,parameter…),where:
  • chain_id: id of the supported chain
  • function_id: id of the gateway function to call on said chain
  • toll: toll being posted to send the transaction; similar to gas
  • parameter…:arbitrary set of parameters to be sent in

Gateway contracts: For each of the chains in B, there exists a “gateway contract” that defines functions that can only be called by the relayer set. Initially supported functions should be:

  • Mint(amount)-mints tokenized representation
  • Burn(amount)-burns tokenized representation
  • Stake(validator)-stakes tokens to a validator
  • Unstake(validator)-unstakes tokens from a validator
  • Withdraw(address) - withdraws all staking rewards receivable by the gateway contract to a given address

The gateway contract only mints and burns when a multisig signature (controlled by relayers) clearing the preset threshold is correctly submitted.

Relayers: A proof-of-authority relayer set implemented on Terra smart contracts.

  • Each relayer holds a key to the multisig on all the gateway contracts.
  • Relayers post a“toll”, which is the minimum amount of fees they would need to earn before relaying an interchain transaction. If the sender pays less than the toll, then they simply ignore the transaction. The sender’s incentive is to post a high enough toll such that their transaction would be agreed to by the majority of relayers
  • Could migrate to proof-of-stake later with stake denominated in anchor governance token. Althea peggy implementation for reference: https://github.com/cosmos/peggy/blob/althea-peggy/solidity/contracts/Peggy.sol

Oracle: A threshold voting schema. Launchpad contracts submit transactions to be considered, and validators submit votes validating the tx along with their signature. Once a majority of the relayers have submitted signatures, the sender (or a related service) can collect said signatures to execute the desired function on the destination chain. User scenarios Similar to https://github.com/renproject/ren/wiki#cross-chain-transactions

User scenarios
Similar to https://github.com/renproject/ren/wiki#cross-chain-transactions


It’s right about now, that you guys are realising, that the number of people (outside your team) with an IQ of over 170 is very very small.

Is there a pictorial representation for the desired design spec?

Unfortunately not. Just text :smiley:

1 Like

Being a visual person, it is sometimes really hard to understand the requirements and/or design specifications.

At the outset, the scope seems to be too broad.

Even a rough sketch would help get some of us started in understanding the needs of/for both parties Terra and Solana.

Sounds good let me ask the Terra team to see if they have anything floating around.

1 Like

Unfortunately nothing that was floating around at the time. I think we might try to use a different solution here - something that already exists like REN for the initial implementation.