Celestia -> EVM bridge



Project Status: WIP – Initial development is in progress, but there has not yet been a stable, usable release suitable for the public. GoDoc Go Report Card Version License: Apache-2.0 Lines Of Code GitHub Super-Linter

Peggo is a Go implementation of the Peggy (Gravity Bridge) Orchestrator originally implemented by Injective Labs. Peggo itself is a fork of the original Gravity Bridge Orchestrator implemented by Althea.

Table of Contents



To install the peggo binary:

$ make install

How to run


First we must register the validator's Ethereum key. This key will be used to sign claims going from Ethereum to Umee and to sign any transactions sent to Ethereum (batches or validator set updates).

$ peggo tx register-eth-key \
  --cosmos-chain-id="..." \
  --cosmos-grpc="tcp://..." \
  --tendermint-rpc="http://..." \
  --cosmos-keyring=... \
  --cosmos-keyring-dir=... \
  --cosmos-from=... \

Run the orchestrator

$ peggo orchestrator \
  --eth-pk=$ETH_PK \
  --eth-rpc=$ETH_RPC \
  --relay-batches=true \
  --relay-valsets=true \
  --eth-chain-id=... \
  --cosmos-chain-id=... \
  --cosmos-grpc="tcp://..." \
  --tendermint-rpc="http://..." \
  --cosmos-keyring=... \
  --cosmos-keyring-dir=... \

Send a transfer from Umee to Ethereum

This is done using the command umeed tx peggy send-to-eth, use the --help flag for more information.

If the coin doesn't have a corresponding ERC20 equivalent on the Ethereum network, the transaction will fail. This is only required for Cosmos originated coins and anyone can call the deployERC20 function on the Peggy contract to fix this (Peggo has a helper command for this, see peggo bridge deploy-erc20 --help for more details).

This process takes longer than transfers the other way around because they get relayed in batches rather than individually. It primarily depends on the amount of transfers of the same token and the fees the senders are paying.

Important notice: if an "unlisted" (with no monetary value) ERC20 token gets sent into Umee it won't be possible to transfer it back to Ethereum, unless a validator is configured to batch and relay transactions of this token.

Send a transfer from Ethereum to Umee

Any ERC20 token can be sent to Umee and it's done using the command peggo bridge send-to-cosmos, use the --help flag for more information. It can also be done by calling the sendToCosmos method on the Peggy contract.

The ERC20 tokens will be locked in the Peggy contract and new coins will be minted on Umee with the denomination peggy{token_address}. This process takes around 3 minutes or 12 Ethereum blocks.

How it works

Peggo allows transfers of assets back and forth between Ethereum and Umee. It supports both assets originating on Umee and assets originating on Ethereum (any ERC20 token).

It works by scanning the events of the contract deployed on Ethereum (Peggy) and relaying them as messages to the Umee chain; and relaying transaction batches and validator sets from Umee to Ethereum.

Events and messages observed/relayed


Deposits (SendToCosmosEvent): emitted when sending tokens from Ethereum to Umee using the sendToCosmos function on Peggy.

Withdraw (TransactionBatchExecutedEvent): emitted when a batch of transactions is sent from Umee to Ethereum using the submitBatch function on the Peggy contract by a validator. This serves as a confirmation to Umee that the batch was sent successfully.

Valset update (ValsetUpdatedEvent): emitted on init of the Peggy contract and on every execution of the updateValset function.

Deployed ERC 20 (ERC20DeployedEvent): emitted when executing the function deployERC20. This event signals Umee that there's a new ERC20 deployed from Peggy, so Umee can map the token contract address to the corresponding native coin. This enables transfers from Umee to Ethereum.


Validator sets: Umee informs the Peggy contract who are the current validators and their power. This results in an execution of the updateValset function.

Request batch: Peggo will check for new transactions in the Outgoing TX Pool and if the transactions' fees are greater than the set minimum batch fee, it will send a message to Umee requesting a new batch.

Batches: Peggo queries Umee for any batches ready to be relayed and relays them over to Ethereum using the submitBatch function on the Peggy contract.

  • Create a new tag for the latest master

    Create a new tag for the latest master

    Currently, when referring to the QGB repo from a Go project, it gets the v1.0.3 which is too old. We should create a new tag v1.1.0 which refers to the latest master.

    opened by SweeXordious 13
  • Investigate what to commit to

    Investigate what to commit to


    #4 proposed including a tuple root. An alternative would simple be including the data root. Investigate and document final decision.

    Problem Definition


    For Admin Use

    • [ ] Not duplicate issue
    • [ ] Appropriate labels applied
    • [ ] Appropriate contributors tagged
    • [ ] Contributor assigned/self-assigned
    opened by adlerjohn 6
  • fix: Change nonce to height.

    fix: Change nonce to height.

    Fixes #104

    Technically this might not even be necessary from a functional point of view; it's simply adding a constructor field for the initial height, which will be overwritten on the first update anyways. The nonce check was already <= instead of == +1.

    Documentation was updated though to make it clearer.

    opened by adlerjohn 5
  • [tracking] EVM light client bridge vs Gravity Bridge

    [tracking] EVM light client bridge vs Gravity Bridge

    Problem Statement

    Various rollups on EVM L1s may have a need for using Celestia as a DA layer, while keeping fraud/validity proof verification in the EVM. To that end, two concrete possibilities exist: the Gravity bridge and a native EVM light client. This issue summarizes how each will work, any changes necessary for our usecase, and pros and cons.

    Gravity Bridge

    The Gravity bridge is a project initiated in the Cosmos ecosystem: https://github.com/cosmos/gravity-bridge. Various forks (maybe as many as a dozen at this point) exist of this protocol, with minor changes. Non-exhaustively

    1. https://github.com/PeggyJV/gravity-bridge (Rust off-chain code)
    2. https://github.com/InjectiveLabs/peggo (Go off-chain code)

    Method of Operation

    The Gravity bridge has two components: an on-chain component written in Solidity and an off-chain component (the orchestrator) written in Rust (Peggy) or Go (Injective). A high-level explanation of the Solidity contracts can be found here.

    The orchestrator runs alongside a Tendermint node (potentially as an SDK module) that causes validators (i.e. block producers) to, in addition to regular Tendermint votes, also sign EVM-compatible messages that mirror:

    1. validator set changes, and
    2. arbitrary events in blocks.

    Specifically, messages are signed in accordance with ERC-191. These signatures are batched and sent to an on-chain contract. The contract keeps track of the validator set as it changes, and verifies that the arbitrary events are signed off by a supermajority of voting power.

    Updates to the validator set must occur every time

    1. The validator set changes too much (currently, 5% is recommended, though this parameter may be tweaked up to 33% I think), or
    2. No other updates have occurred within the unbonding window. For safety, probably 1/2 the unbonding window should be used here.

    To update the contract's view of the validator set, updateValset is called. The orchestrator will construct an EVM-compatible transaction with batched signatures here. The contract will simply verify that:

    1. The provided previous validator set matches the known hash of the validator set, and
    2. A supermajority of the previous validator set has voted correctly for the new validator set.

    Then update its saved validator set hash.

    I estimate this operation is ~500k gas each time. As an example, Ethereum is an EVM-compatible chain and at its current gas prices this would cost ~$400. It would be prohibitive to update the validator set every block, hence the above threshold of 5%. With only occasional updates, this cost should end up not being too significant.

    Batches of arbitrary messages are submitted to the EVM chain with submitBatch. This requires verification of the current validator set and a supermajority of signatures. Note that arbitrary messages does not necessarily imply single blocks; properly implemented, a single batch of arbitrary messages can be made across as many blocks as can fit in the gas limit.

    Required Changes

    1. Numerous gas optimizations can and should be made. Just as an example of how immature the implementation is: when updating the validator set, the new validator set is provided. But this is actually not needed under an honest majority assumption; a commitment to the new validator set is sufficient.
    2. The submitBatch function only works for transfers of fungible tokens across the bridge. This will have to be modified for our purposes, namely a list of (block height, namespace ID, message commitment) tuples.
    3. The orchestrator exists mostly as a separate module for now. It will have to be fully integrated into either the SDK or the node software directly.
    4. An audit of the contracts will be required.
    5. NMT proof verification and share parsing (but not Celestia tx parsing) is required, since the commitment is identical to the one in the PayForMessage tx. As such, a protobuf codec is not needed.


    1. A majority of the of the code already exists. This will probably be the fastest option.
    2. Potential for Cosmos branding and association.


    1. Realistically, there is 0% chance of being able to upstream changes, barring us owning the canonical implementation of Gravity bridge. This is because there is no specification or reference implemention of the Gravity bridge protocol, so a dozen projects each have their own completely independent fork, with more popping up. This will have to be developed in isolation of the broader Cosmos ecosystem solely for our purposes.
    2. Cost of verifying signatures for each message batch is non-trivial. Verifying 50 signatures would be ~200k gas, while simply posting them would be ~50k.
    3. Requires validators to run a module that introduces a logic dependence on the EVM, and EIP-191. In addition, this will requires computational overhead in the form of each validator needing to run a full node for the EVM chain (or trust a centralized service provider to provide them confirmation of transaction inclusion and effect).
    4. One of the key requirements for PoS is accountability: being able to identify which validators of a dishonest majority were in fact dishonest, and burning their stake with social coordination. Validators that submit a bad batch or validator set update to the EVM chain must be penalized, otherwise the bridge isn't making and honest-but-accountable-majority assumption (good), but an honest-and-unaccountable-majority assumption (bad). To that end, non-validator nodes must also be able to understand the EVM and EIP-191 in order to be able to understand that the validator submitted something they should not have, and penalize them.
    5. A separate instance of the Gravity bridge module is required to handle each chain that is bridged to. This is not yet implemented properly, but even if it were, it would be onerous in a future where potentially many chains would leverage Celestia as a DA service.

    EVM Light Client Bridge

    The EVM light client bridge (this repo) is a Celestia light client written in Solidity. It accepts new blocks headers as they are in Celestia, and follows the chain of block headers under an honest majority assumption.

    Method of Operation

    The EVM light client bridge has two components: an on-chain component written in Solidity and an off-chain component (which we'll call the orchestrator), yet to be written.

    The on-chain contract will accept new Celestia block headers in protobuf, along with addition metadata, such as the validator set (diff). It can then update its view of the validator set similar to the Gravity bridge. Again, the actual updating of the validator set is only required when a threshold of the voting power changes.

    To parse the protobuf-encoded header, the following libraries implement deterministic protobuf:

    1. https://github.com/celestiaorg/protobuf3-solidity
    2. https://github.com/celestiaorg/protobuf3-solidity-lib

    The final piece of the puzzle is that verification of the header and signatures must be done optimistically, by making the header chain an optimistic rollup. This is necessary since parsing protobuf every time would be too expensive. This would significantly reduce gas costs vs the Gravity bridge: verifying 50 signatures would be ~200k gas, while simply posting them would be ~50k. This similarly applies to processing messages. In other words, gas costs can be reduced by somewhere around a factor of 4 with an optimistic EVM light client bridge vs the Gravity bridge.

    Required Changes

    Significant changes are required.

    1. Actually use protobuf to encoding/decode headers, etc. Library is implemented but is unused.
    2. NMT proof verification, transaction and share parsing, etc.
    3. Optimistic verification and rollbacks. This is one of the easier things to implement on this list, since the author is moderately familiar with how optimistic rollups work.
    4. Off-chain orchestrator will have to be implemented, but significant portions of the Gravity bridge can be re-used.
    5. Gas optimizations for the protobuf library.
    6. An audit of the contracts will be required.


    1. Since the contract accepts Celestia block headers directly, there is no need for validators to run any separate module. In addition, validators do not even need to run anything that connects to another chain in any ways. A single relayer can be tasked with posting all updates to the relevant EVM chain(s).
    2. There is no logical dependence on the EVM or EIP-191. The bridge operates under an honest-but-accountable-majority assumption.
    3. With optimistic verification, gas costs can be reduced significantly vs the Gravity bridge.
    4. Potential to maintain potentially widely-used optimistic Tendermint light client bridge and reference implementation of deterministic protobuf codec Solidity library.


    1. Large parts of the Solidity code are missing, including actually using the protobuf codec, NMT proof verification, transaction and share parsing, etc.
    2. An orchestrator will have to be implemented to actually send transactions to Ethereum. The Gravity orchestrator can be re-used mostly.
    3. With optimistic verification, a delay is required to finalize the submitted block headers. This may be unacceptable for zk rollup projects, but is fine for optimistic rollups.


    Don't forget to like, comment, and subscribe 👇

    opened by adlerjohn 5
  • Look into removing the `BRIDGE_ID`

    Look into removing the `BRIDGE_ID`

    Since we're a one way bridge, we might be able to remove the BRIDGE_ID that is normally used to prevent replay attacks. We should further investigate the consequences of removing it.

    good first issue contracts optimization 
    opened by evan-forbes 4
  • feat: Add oracle interface

    feat: Add oracle interface

    Adds a publicly callable interface for downstream contracts to query the QGB contract for attestations.

    Depends on #32

    Tests will be done in a future PR.

    opened by adlerjohn 4
  • Contract not verifying valsets against the right checkpoint

    Contract not verifying valsets against the right checkpoint

    Currently, the QGB contract, when submitting valsets, creates the following checkpoint: https://github.com/celestiaorg/quantum-gravity-bridge/blob/210a1fbb9a9fc3165a038d8cedfba177c67a5726/src/QuantumGravityBridge.sol#L275

    The issue, is that the checkpoint is calculated using the currentNonce which is the latest eventNonce, and will never match the submitted one.

    Example: We relay the following attestations:

    • Nonce 1 : Valset 1
    • Nonce 2 : DC
    • Nonce 3 : DC
    • Nonce 4 : Valset 2

    When submitting the Valset 1 with Nonce = 1, the checkpoint will be calculated using Nonce = 1. However, when submitting Valset 2 with Nonce = 4, the checkpoint, which the contract will check against, will be created using Nonce = 3, resulting in a wrong checkpoint.

    The solution would be to keep a LastValsetNonce variable stored in the contract, so that when submitting the new checkpoint, it can be used to generate the validator set hash correctly.

    @adlerjohn @evan-forbes

    opened by SweeXordious 3
  • Clean up contracts

    Clean up contracts

    Main contract: https://github.com/celestiaorg/quantum-gravity-bridge/blob/adlerjohn/contract_mods/ethereum/solidity/contracts/QuantumGravityBridge.sol

    Original main contract: https://github.com/celestiaorg/quantum-gravity-bridge/blob/b5ba246f23f89c43adf764e2e3f804b4a9f3beb0/solidity/contracts/Peggy.sol

    opened by adlerjohn 3
  • Delete mergify config

    Delete mergify config


    This is an attempt to fix: https://github.com/celestiaorg/quantum-gravity-bridge/pull/124/checks?check_run_id=7962233579

    ~~strict and commit_message aren't supported keys for actions.merge (ref https://docs.mergify.com/actions/merge/). It looks possible to use commit_message_template to achieve something similar to the previous commit_message config if desired.~~

    opened by rootulp 2
  • update the generated wrapper

    update the generated wrapper

    When I regenerate the wrapper, it gives me different BINs. @adlerjohn please take a look when you have time. The compiler that I used is:

    Version: 0.8.4+commit.c7e474f2.Linux.g++
    help wanted 
    opened by SweeXordious 2
  • Orchestrator read pay for message txs from node

    Orchestrator read pay for message txs from node

    #9 will mock what is sent to the contract. PayForMessage txs must be extracted from each Celestia block and replace the mock logic so that real data can be sent to the contract.

    opened by adlerjohn 2
  • NMT multiproof verification

    NMT multiproof verification

    Currently, NMT implementation only verifies NMT proof for a single key: https://github.com/celestiaorg/quantum-gravity-bridge/blob/f38d30b67b8e0ee4df8819809946f4cc0dcada67/src/lib/tree/namespace/NamespaceMerkleTree.sol#L20-L30

    We will need to add support for NMT multiproof to benefit from compact proofs, and be compatible with the NMT proofs generated on Celestia-app side.

    enhancement contracts 
    opened by SweeXordious 0
  • Shares inclusion verification

    Shares inclusion verification

    Currently, the QGB smart contract only provides a verification method to verify a data root inclusion proof in a data root tuple root: https://github.com/celestiaorg/quantum-gravity-bridge/blob/f38d30b67b8e0ee4df8819809946f4cc0dcada67/src/QuantumGravityBridge.sol#L373-L391

    To verify that a share was posted on Celestia on the EVM chain, we will need extra methods to verify the following:

    • [ ] Shares NMT inclusion proof to rows
    • [ ] Rows merkle proof to data root
    enhancement contracts 
    opened by SweeXordious 0
  • Add CI workflow to require labels for PRs

    Add CI workflow to require labels for PRs

    As per the discussion in https://github.com/celestiaorg/quantum-gravity-bridge/pull/106#issuecomment-1087539242 , we need to add the following workflow to require PRs to have a minimum of 1 label.

    good first issue github_actions 
    opened by SweeXordious 2
  • Write ADR for dynamic data commitment block ranges

    Write ADR for dynamic data commitment block ranges

    The QGB relies on validators signing commitments to erasure block data over a range of blocks. For the MVP, we are using an identical block range for each DataCommitment. This range of blocks will likely need to be significantly more dynamic to accommodate different rollups.

    • How can we do this in an efficient way?
    • Does it matter if ranges overlap?
    • How will this affect slashing?
    • Will the rollup batch producers need to ask the celestia validators to sign commitments over custom ranges? If so, what should that look like?
    • Do any changes need to be made to the contracts?
    opened by evan-forbes 0
  • v1.3.0(Nov 28, 2022)

    What's Changed

    • adds check validators docs by @SweeXordious in https://github.com/celestiaorg/quantum-gravity-bridge/pull/123
    • Delete mergify config by @rootulp in https://github.com/celestiaorg/quantum-gravity-bridge/pull/125
    • Remove lint badge by @rootulp in https://github.com/celestiaorg/quantum-gravity-bridge/pull/124
    • docs: remove duplicate word by @rootulp in https://github.com/celestiaorg/quantum-gravity-bridge/pull/126
    • Update foundry manifest file to work with new version. by @adlerjohn in https://github.com/celestiaorg/quantum-gravity-bridge/pull/129
    • chore: remove unnecessary BRIDGE_ID by @SweeXordious in https://github.com/celestiaorg/quantum-gravity-bridge/pull/130

    New Contributors

    • @SweeXordious made their first contribution in https://github.com/celestiaorg/quantum-gravity-bridge/pull/123

    Full Changelog: https://github.com/celestiaorg/quantum-gravity-bridge/compare/v1.2.0...v1.3.0

    Source code(tar.gz)
    Source code(zip)
  • v1.2.0(Jun 22, 2022)

    What's Changed

    • Use old validator set nonce instead of latest nonce. by @adlerjohn in https://github.com/celestiaorg/quantum-gravity-bridge/pull/121

    Full Changelog: https://github.com/celestiaorg/quantum-gravity-bridge/compare/v1.1.0...v1.2.0

    Source code(tar.gz)
    Source code(zip)
  • v1.1.0(Jun 6, 2022)

    What's Changed

    • Merge in umee peggo by @liamsi in https://github.com/celestiaorg/quantum-gravity-bridge/pull/5
    • Clean up contracts by @adlerjohn in https://github.com/celestiaorg/quantum-gravity-bridge/pull/3
    • chore: fix build and wrapper generation & regenerate by @liamsi in https://github.com/celestiaorg/quantum-gravity-bridge/pull/8
    • chore: bump github.com/golangci/golangci-lint from 1.42.1 to 1.43.0 by @dependabot in https://github.com/celestiaorg/quantum-gravity-bridge/pull/10
    • ci: main -> master by @adlerjohn in https://github.com/celestiaorg/quantum-gravity-bridge/pull/15
    • Make readme Celestia- and QGB-specific by @adlerjohn in https://github.com/celestiaorg/quantum-gravity-bridge/pull/38
    • chore: bump actions/cache from 2.1.6 to 2.1.7 by @dependabot in https://github.com/celestiaorg/quantum-gravity-bridge/pull/11
    • chore: bump technote-space/get-diff-action from 5 to 6.0.1 by @dependabot in https://github.com/celestiaorg/quantum-gravity-bridge/pull/29
    • chore: bump amannn/action-semantic-pull-request from 3.4.6 to 4.2.0 by @dependabot in https://github.com/celestiaorg/quantum-gravity-bridge/pull/52
    • chore: bump actions/setup-go from 2.1.4 to 2.2.0 by @dependabot in https://github.com/celestiaorg/quantum-gravity-bridge/pull/53
    • fix: Fix codeowners Solidity dir. by @adlerjohn in https://github.com/celestiaorg/quantum-gravity-bridge/pull/61
    • chore: bump actions/setup-go from 2.2.0 to 3 by @dependabot in https://github.com/celestiaorg/quantum-gravity-bridge/pull/62
    • chore: bump actions/checkout from 2 to 3 by @dependabot in https://github.com/celestiaorg/quantum-gravity-bridge/pull/63
    • feat: Add Merkle tree libraries by @adlerjohn in https://github.com/celestiaorg/quantum-gravity-bridge/pull/32
    • feat: Use Foundry and add Merkle tree tests by @adlerjohn in https://github.com/celestiaorg/quantum-gravity-bridge/pull/51
    • chore: Remove issue templates by @adlerjohn in https://github.com/celestiaorg/quantum-gravity-bridge/pull/69
    • chore: Remove codeowner by @adlerjohn in https://github.com/celestiaorg/quantum-gravity-bridge/pull/68
    • fix: Use minimum solc v0.8.4 by @adlerjohn in https://github.com/celestiaorg/quantum-gravity-bridge/pull/70
    • fix: Allow skipping nil signatures. by @adlerjohn in https://github.com/celestiaorg/quantum-gravity-bridge/pull/72
    • chore: Remove unused contracts and wrappers. by @adlerjohn in https://github.com/celestiaorg/quantum-gravity-bridge/pull/74
    • fix: Fix paths for abigen by @adlerjohn in https://github.com/celestiaorg/quantum-gravity-bridge/pull/75
    • chore: Regenerate contract ABI bindings. by @adlerjohn in https://github.com/celestiaorg/quantum-gravity-bridge/pull/76
    • chore: Clean up readme. by @adlerjohn in https://github.com/celestiaorg/quantum-gravity-bridge/pull/78
    • chore: Remove old contract docs. by @adlerjohn in https://github.com/celestiaorg/quantum-gravity-bridge/pull/77
    • chore: Remove old Ethereum files. by @adlerjohn in https://github.com/celestiaorg/quantum-gravity-bridge/pull/80
    • chore: Remove prettier config files. by @adlerjohn in https://github.com/celestiaorg/quantum-gravity-bridge/pull/81
    • chore: Remove redundant ABIEncoderV2 pragmas. by @adlerjohn in https://github.com/celestiaorg/quantum-gravity-bridge/pull/82
    • feat(ci): run forge test by @rootulp in https://github.com/celestiaorg/quantum-gravity-bridge/pull/83
    • chore: Improve readme. by @adlerjohn in https://github.com/celestiaorg/quantum-gravity-bridge/pull/84
    • chore: Add period at end of comment. by @adlerjohn in https://github.com/celestiaorg/quantum-gravity-bridge/pull/85
    • fix: Add prettierrc for Solidity by @adlerjohn in https://github.com/celestiaorg/quantum-gravity-bridge/pull/88
    • feat: Refactor and add inner node verification logic. by @adlerjohn in https://github.com/celestiaorg/quantum-gravity-bridge/pull/92
    • chore: bump actions/cache from 2.1.7 to 3 by @dependabot in https://github.com/celestiaorg/quantum-gravity-bridge/pull/94
    • chore: remove goreleaser by @rootulp in https://github.com/celestiaorg/quantum-gravity-bridge/pull/95
    • fix: use new nonce instead of current nonce by @adlerjohn in https://github.com/celestiaorg/quantum-gravity-bridge/pull/97
    • chore: add tests for verifyInner by @rootulp in https://github.com/celestiaorg/quantum-gravity-bridge/pull/102
    • chore: Test the main contract by @evan-forbes in https://github.com/celestiaorg/quantum-gravity-bridge/pull/100
    • chore: labels exist; use them by @adlerjohn in https://github.com/celestiaorg/quantum-gravity-bridge/pull/106
    • Remove references to Ethereum specifically. by @adlerjohn in https://github.com/celestiaorg/quantum-gravity-bridge/pull/109
    • fix: Change nonce to height. by @adlerjohn in https://github.com/celestiaorg/quantum-gravity-bridge/pull/105
    • Remove Go code and move Solidity code to root. by @adlerjohn in https://github.com/celestiaorg/quantum-gravity-bridge/pull/113
    • chore: bump actions/checkout from 2 to 3 by @dependabot in https://github.com/celestiaorg/quantum-gravity-bridge/pull/114
    • Improve readme for Forge. by @adlerjohn in https://github.com/celestiaorg/quantum-gravity-bridge/pull/116
    • Universal nonce by @adlerjohn in https://github.com/celestiaorg/quantum-gravity-bridge/pull/119

    New Contributors

    • @liamsi made their first contribution in https://github.com/celestiaorg/quantum-gravity-bridge/pull/5
    • @dependabot made their first contribution in https://github.com/celestiaorg/quantum-gravity-bridge/pull/10
    • @rootulp made their first contribution in https://github.com/celestiaorg/quantum-gravity-bridge/pull/83
    • @evan-forbes made their first contribution in https://github.com/celestiaorg/quantum-gravity-bridge/pull/100

    Full Changelog: https://github.com/celestiaorg/quantum-gravity-bridge/compare/v1.0.3...v1.1.0

    Source code(tar.gz)
    Source code(zip)
Dotcel - Domain name application built on top of celestia

dotcel dotcel is a blockchain built using Cosmos SDK and Tendermint and created

Evan Forbes 1 Feb 7, 2022
EVM-compatible chain secured by the Lachesis consensus algorithm

ICICB galaxy EVM-compatible chain secured by the Lachesis consensus algorithm. Building the source Building galaxy requires both a Go (version 1.14 or

Galaxy developer Team 10 Jan 8, 2022
A Matrix-iMessage puppeting bridge

A Matrix-iMessage puppeting bridge. The bridge runs on a Mac or jailbroken iPhone (soon™). A websocket proxy is required to receive appservice events from the homeserver.

Tulir Asokan 151 Jan 2, 2023
vks is a Vulkan bridge for Go.

vks vks is a Vulkan bridge for Go. The header generator folder contains the code that is used to generate the vulkan bindings. It woks similar to c-fo

Jason Watson 6 Sep 3, 2022
Bridge between mattermost, IRC, gitter, xmpp, slack, discord, telegram, rocketchat, twitch, ssh-chat, zulip, whatsapp, keybase, matrix, microsoft teams, nextcloud, mumble, vk and more with REST API

bridge between mattermost, IRC, gitter, xmpp, slack, discord, telegram, rocketchat, twitch, ssh-chat, zulip, whatsapp, keybase, matrix, microsoft teams, nextcloud, mumble, vk and more with REST API (mattermost not required!)

Wim 5.4k Jan 4, 2023
An inline buildpack for deploying a mattermost-irc bridge

Matterbridge-Heroku An inline buildpack for hosting Matterbridge on Heroku. Heroku is a platform for easily deploying applications. A buildpack provid

Christopher DeCairos 11 Nov 26, 2022
Bridge facebook messenger with any service supported by matterbridge

fbridge fbridge bridges facebook messenger with any service supported by matterbridge trough the API interface. fbridge is using fbchat to connect to

null 28 Oct 30, 2022
Facebook bridge used with matterbridge

fbridge-asyncio This repo is a fork of fbridge. If you log in to your facebook account from a browser, after you do, it's a good idea to restart fbrid

null 8 Aug 7, 2022
Grpc bridge to various mediabank related systems

Mediabank bridge This internal tool enables authenticated gRPC based endpoint for securely communicating with systems like: Telestream Vantage Workflo

BCC Code 0 Jan 7, 2022
Bridge REMOV will allow you to safely transfer NFT from RMRK to MOVR and backwards

remov Inspiration Our aim is to expand the capabilities of blockchain and make a secure way for transferring NFT between RMRK and MOVR blockchain. The

null 1 Dec 5, 2021
A REST API for the DN42 registry, written in Go, to provide a bridge between interactive applications and the registry.

dn42regsrv A REST API for the DN42 registry, written in Go, to provide a bridge between interactive applications and registry data. A public instance

Simon Marsh 0 Apr 21, 2022
The official repository of the Gravity Bridge Blockchain

Gravity bridge is Cosmos <-> Ethereum bridge designed to run on the Cosmos SDK blockchains like the Cosmos Hub focused on maximum design simplicity an

Gravity Bridge Foundation 117 Dec 27, 2022
A bridge from the Stellar network to other blockchains

Creating equitable access to the global financial system Starbridge Starbridge is software that facilitates bridge builders who are connecting the Ste

Stellar 38 Dec 9, 2022
RuuviBridge - Utility to bridge RuuviTag data between various sources and consumers

RuuviBridge RuuviBridge is designed to act as a "data bridge" between various so

Scrin 14 Nov 19, 2022
🧙 High-performance PHP-to-Golang IPC/RPC bridge

High-performance PHP-to-Golang IPC bridge Goridge is high performance PHP-to-Golang codec library which works over native PHP sockets and Golang net/r

RoadRunner 1.1k Dec 28, 2022
Apex-api-bridge - Bridge between apexlegendsapi and ApeStats

apex-api-sync This app updates a mongo instance with the players most recent dat

null 1 Feb 17, 2022
Dotcel - Domain name application built on top of celestia

dotcel dotcel is a blockchain built using Cosmos SDK and Tendermint and created

Evan Forbes 1 Feb 7, 2022
Stress testing and benchmarking tool for the NEAR EVM

evm-bully --- stress testing and benchmarking tool for the NEAR EVM

Project Aurora 28 May 30, 2022
Moeing chain is an EVM&Web3 compatible sidechain for Bitcoin Cash

Full node client of smartBCH This repository contains the code of the full node client of smartBCH, an EVM&Web3 compatible sidechain for Bitcoin Cash.

null 121 Nov 29, 2022
EVM frontrunning tool

CAKE SNIPER FRONTRUNNING BOT =================================================== BEFORE STARTING: This bot require you to run the GETH client + use

Supercycled 1.4k Jan 9, 2023