---
tags: rage-report, cross-chain, safe
---

# Rage Report: Cross-chain DAOs using Hashi

## Team

- Santiago

## Background

While implenting the ProtocolGuild NetworkRegistry contract, we started exploring cross-chain dao interactions & contract state replication using [Connext protocol](https://docs.connext.network/concepts/how-it-works). The team behind the bridge protocol also implemented a [Zodiac module](https://github.com/connext/zodiac-module-connext) that can be plugged into a Safe on a `destination` chain so it can be controlled by an `originSender` that submits a message from the`origin` chain through Connext.

On the other hand, The [Cross-chain Alliance team](https://github.com/crosschain-alliance) has been implementing a [pair of modules](https://github.com/crosschain-alliance/safe-crosschain/) to enable a "main" Safe to control a "secondary" Safe living in another network using [Hashi protocol](https://crosschain-alliance.gitbook.io/hashi/v0.1/readme) for cross-chain communication.

## Scope

The aim for this work is to explore the tech+logic behind `safe-crosschain` modules and `Hashi` EVM Hash Oracle Aggregator so we can make some design decisions to create a solution that enables cross-chain DAO2DAO interactions without relying on a vendor-specific solution. Finally, we could come up with a report with the Pros & Cons of using Connext vs Hashi *additive security for cross-chain messaging*.

## Deliverables

- Smart contracts (TBD)
- Frontend MVP (TBD)

## Known issues

- Cannot do fully e2e tests using hardhat as `eth_getProof` is not supported by neither `hardhat` node while `Anvil` has a bug
- Hardhat [issue](https://github.com/NomicFoundation/hardhat/issues/3345)
- Anvil [issue](https://github.com/foundry-rs/foundry/issues/5004) and [PR](https://github.com/foundry-rs/foundry/pull/6020) that didn't solve the reported error
- I'm planning to do some efforts to review Anvil implementation and use [Ethereum testing framework](https://github.com/ethereum/execution-apis/tree/main/tests/eth_getProof) to validate and fix this method implementation
- EIP1186 [spec](https://eips.ethereum.org/EIPS/eip-1186)
- Hashi is still under development (v0.2 differ from what `safe-crosschain` is using) and its contracts are currently in audit
- Goerli is about to be deprecated. We need to have another testnet setup that has Safe infrastructure (e.g. Sepolia<->GnosisChain but not Sepolia<->Chiado)

## Potential Resources

- Connext: [How it works?](https://docs.connext.network/concepts/how-it-works)
- Connext Zodiac Module [Github repo](https://github.com/connext/zodiac-module-connext)
- Connext Crosschain Widget [Github repo](https://github.com/defi-wonderland/crosschain-widget)
- Safe-crosschain [Github repo](https://github.com/crosschain-alliance/safe-crosschain/)
- Hashi: A principled approach to Bridges. [Proposal @ EthReaseach](https://ethresear.ch/t/hashi-a-principled-approach-to-bridges/14725)
- Hashi [documentation](https://crosschain-alliance.gitbook.io/hashi/v0.1/readme)
- Hashi EVM Oracle Aggreator [contracts repo](https://github.com/gnosis/hashi)

## Experiments

**1. Safe-crosschain + ShoyuBashi on Goerli<->GnosisChain**

Image Source [link](https://crosschain-alliance.gitbook.io/hashi/v0.1/deployment#testnet)

Steps to reproduce the experiment:

* Setup a pair of Safe contracts on [Goerli](https://goerli.etherscan.io/address/0x6dE06De2e70c15e512a4800de7f8eaE54B6e50dE#code) (using [smold.app](https://smold.app/safe)) and [GnosisChain](https://app.safe.global/home?safe=gno:0xf4d2883c8BC70CEfECDEAeEF76Cdb203750c674B)
* Fund Gnosis Safe with 1xDAI
* Use `safe crosschain` to deploy both `Peripheral` and `ControllerModule` contracts

yarn hardhat --network goerli Peripheral:deploy --target-network 100 --verify
yarn hardhat --network gnosis ControllerModule:deploy --source-chain-id 5 --main-safe <goerli-safe-addr> --secondary-safe <gnosis-safe-addr> ==peripheral <peripheral-addr> --giri-giri-bashi <goerli-shoyu-bashi-addr> --verify

* Execute `send native token` sample tx

yarn hardhat --network goerli ControllerModule:execTransaction:sendNativeToken --controller-module <gnosis-controller-module-addr> --target-network gnosis

* use [BlockHeaderReporter](https://goerli.etherscan.io/address/0xedc0b1d3de4496e0d917af42f29cb71eb2982319#writeContract) to report and store the block hash of the tx on origin chain

reportHeaders(
    [<blockNo>],
    "0x32Cd442309cA6E79Db2194aac61024FBD2B14eb9)", // AMB Adapter
    20000000 // max gas allowed by AMB
)

* ShoyuBashi has a threshold of 2/4, so we need to repeat the step above for another Adapter such as [SygmaHeaderReporter](https://goerli.etherscan.io/address/0x2f96d347c932ac73b56e9352ecc0707e25173d88#code) however contract is not verified on Etherscan
* The [Adapters Dashboard] should list the reported block (here's a blocker)
* [ShoyuBashi](https://gnosisscan.io/address/0x31a8e89d6f98454d38c03eca3dc543f6581d607c#readContract) on destination should return the hash when calling `getThresholdHash`

getThresholdHash(
    5, // domain -> origin chain id
    <blockNo>
)

* [AMBAdapter](https://gnosisscan.io/address/0x32Cd442309cA6E79Db2194aac61024FBD2B14eb9#readContract) on destination should return the hash when calling `getHashFromOracle`

getHashFromOracle(
    5, // domain -> origin chain id
    <blockNo>
)

**2. Safe-crosschain + GiriGiriBashi as local e2e tests**

* Deploy an Anvil node
* Run tests spec

yarn hadhat --netowrk anvil test

**NOTE** here we have another blocker as currently local testing fails as devnet note doesn't support or has a bug on the `eth_getProof` RPC method

* If you want to debug storage proofs using `cast`

To calculate slot number for mapping that stores main-safe commitments

// see storage layout docs https://docs.soliditylang.org/en/latest/internals/layout_in_storage.html#mappings-and-dynamic-arrays
utils.keccak256(
    utils.defaultAbiCoder.encode(
        ["address", "uint256"],
        [<safe-address>, 0])) // safe address + mapping slot position

cast proof -r http://127.0.0.1:8545 <contract_address> <storage slot>

**Experiment #2**

## Expectations

## Results/Findings

## Demos

## Pull Requests

## Proposed Next Steps

## Other ideas to explore