Auromony: Aurora ⇄ Harmony Bridge

Governance zkDAO
1

Auromony sets out to be a trustless asset bridge between Harmony and Aurora (EVM environment on NEAR Protocol).

Application Type

zkDAO

Proposal Overview

The scope of this proposal covers the research and development of a trustless bridge between Harmony and Aurora ultimately powered by ZK. The current MVP supports bridging of USDC on mainnets with limited initial liquidity ($10 on Aurora and Harmony respectively) powered by HTLCs.

Technical Details

The current MVP is a custom build of Connext that enables trustless briding based on Hash Time Locked Contracts (HTLCs). Given the immaturity of ZK light clients at the time of starting the project, the MVP was deliberately chosen to adopt local verifiactions instead to maintain the trustless status of a usable prototype that can be developed within a limited timeframe.

The architecture of the current MVP involves the components listed below. If you are interested in more details, you may refer to the demonstration video linked in the last section of this proposal or the documentations within the corresponding repositories.

Backend

  • nxtp

    Monorepo containing the source code of Contracts, Subgraphs and Router, as well as Docker Compose configurations for running the Router and NATS messaging server.

  • NATS

    NATS server facilitating off-chain messaging (i.e. auctioning and bidding) between frontend users and backend routers.

  • graph-node

    Local node hosting The Graph subgraphs.

  • subgraph-cache-server

    Subgraphs caching server that provides APIs for the frontend to read subgraphs.

Frontend

  • coinhippo-bridge

    Frontend for user interactions with the bridging service.

  • chaindata

    List of chains and assets. For sourcing cross-chain assets in frontend.

Use Cases

Cross-chain Activities

Starting with one of the most liquid cryptoassets, Auromony will provide users a secure solution when transferring and using their beloved cryptoassets across both chains for payments, trades, bids, etc.

Aurora Gas Funding

As gas on Aurora is denominated in ETH, bridging ETH from other means through Harmony could be an economical solution to fund an Aurora wallet versus e.g. bridging from Ethereum with future support of ETH bridging on Auromony.

Competitive Landscape

Harmony Horizon

Current implementation:
https://bridge.harmony.one/

Light client based version, currently in development:

Harmony’s “official” bridge. Support for bridging to Aurora is neither available nor announced.

Bridging to Aurora using Horizon’s mint-burn model would also create Aurora versions of Ethereum assets on Harmony that could deteriorate users’ experience.

Aurora Rainbow Bridge

Aurora’s light client based “official” bridge. Support for bridging to Harmony is neither available nor announced.

Bridging to Harmony using Rainbow Bridge’s mint-burn model would also create Harmony versions of Ethereum assets on Aurora that could deteriorate users’ experience.

cBridge

cBridge supports trustless bridging between Harmony and Aurora of USDC only at the time of writing this proposal. Accessing the majority of liquidity on cBridge also requires honesty assumption of its State Guardians.

Allbridge

Allbridge supports bridging between Harmony and Aurora of its protocol token ABR only at the time of writing this proposal. The bridging process also requires honesty assumption of its external validators.

Multichain

Multichain supports bridging between Harmony / Aurora and other chains, but not directly between Harmony and Aurora at the time of writing this proposal. The bridging process also requires honesty assumption of its external validators.

Proposal Ask

Further Auromony research and development is anticipated to cover:

  • A Harmony ZK light client in Solidity
  • An Aurora ZK light client in Solidity
  • A ZK bridge MVP between Harmony and Aurora with support of limited assets
  • A production-ready ZK bridge between Harmony and Aurora with support of more assets

As such, a $15k/year stable basic income is requested to take care of initial R&D, welfare and operations costs.

This ask will be lined up with the following milestones:

  1. launching a feature-complete product on our testnet
  2. forming a DAO with 5-out-of-9 multisig with our DAOs
  3. launching on our mainnet with audit
  4. attracting 1k daily active users (with launch video, full PR promotion)
  5. attracting 10k daily active users (with a detailed roadmap, governance process)

Road Map

Given the heavy R&D described above, the anticipated completion dates for objectives up to milestone 3 are very preliminary estimations that could likely vary as time progresses.

Objective Completion Date Status
Testnet Launch 30 Apr 2022 Completed
DAO Initialization 30 Jun 2022 Pending
Harmony ZK light client Testnet Launch 30 Sep 2022 Pending
Aurora ZK Light Client Testnet Launch 30 Nov 2022 Pending
ZK Auromony Testnet Launch 15 Jan 2023 Pending
Beta Testing 28 Feb 2023 Pending
Smart Contract Audit 30 Apr 2023 Pending
Mainnet Launch 30 Jun 2023 Pending

External Links

Demonstration Video (Testnet)

2

From my understanding of the proposal, it seems that the current version of the bridge is not yet ZK. Is that correct?

In that case, I don’t think we can approve the proposal until the ZKLC on Harmony is launched.

3

That’s correct and certainly understandable, as the current version was built partly on the discretion (on graduation only perhaps?) for ZKU c2’s infrastructure track.

4

It will be nice if you can continue to explore and build a ZK version!

1 Like
5

Can you explain the differences and benefits of a ZK bridge vs our existing one for us that do not know or understand the tech!

6

For a bridge to function, the bridge smart contract on one chain needs to be aware of what is happening on the opposite chain in order to lock/release assets according to withdrawals/deposits on the opposite chain. That information is usually relayed by relayers.

The current Horizon bridge smart contract on Ethereum, if I am not mistaken, relies on trusting whitelisted relayers to honestly and reliably relay such information from Harmony. It is, I believe, a design choice to avoid the likely impractical gas costs/limitations that come with verifying and accepting information submitted by arbitrary relayers at the smart contract level.

Meanwhile, one property that ZK offers is succinct verification (i.e. verification of complex and large computations can stay easy and small). Therefore a properly built ZK bridge would be capable of verifying and accepting information from arbitrary relayers at the smart contract level, enhancing the trustlessness and decentralization of the bridging service.

7

Thank you for taking the time to explain that to us! So this is different from what

Multichain - Cross Chain Router Protocol
Synapse Protocol

these offer? I understand that one is a router, but there are already ways to move funds directly from Harmony to Aurora. There is also a grant that has been approved to work on this:

8

Bridging with Multichain / Synapse relies on their respective set of validators to perform the bridging honestly. (Have not studied TheBoringDao Bridge myself.)

Bridging with a proper ZK bridge would work as intended as long as one relayer is relaying honestly. The bridging service would suspend (with no funds at risk) when no one is relaying honestly, and would resume when at least one honest relayer is back up.

1 Like