---
# System prepended metadata

title: Multi network / Single deployment Spec
tags: [Product]

---

---
tags: Product
---

# Multi network / Single deployment Spec

## Implementation notes

#### HUB

##### Not connected
- show same screen we have now / ask them to connect

##### Connecting
- w3Connect() - need to detect the location first to intecept the wrong network



##### Connected
- regardless of network, load all their data
- no need for dao service, just multiple graph loads - HubInit.js
- display network they have


#### DAO
- query api for network
- init dao with that network
- if mismatch on user/need to disconnect and message?


## UX

#### HUB
- load last network they were on or mainnet on 1st visit
- if user is on another network after sign-in we can
    1)  reload with the network they have in MM
    2)  tell them to switch the network, i guess? would need a way in the app for them to indicate which network they want to look at...

#### BIG CHALLENGE
- showing multiple network daos in a single hub
- might not be possible as we would need to load multiple web3 versions?

#### Well In DAO'd
- load the network of the dao
- log the user in if they are on the correct MM network ** just like today **
- message to change network otherwise ** just like today **
- some bits of data are necessary, can they be fetched with a read provider or need signer?
    - proposal status
    - current period

#### Summoning/Explore

- _if_ we moved summoning/explore into DAOhaus_v2 how would summoning be affected by multiple networks. need to be certain before start summoning, that network is selected.
- getting all daos call across all networks would be _hefty_


## Dev

api
- single db table to look up a dao by address and get it's network

client
- last network set in local storage for init of web3 in hub
- rework dao init and user/web3 init to use this fetched network
- inits will all need take into account network and probably retrigger on any change from MM?
- how to handle MM network and dao mismatch - maybe will work like we have it today
- handle account change in MM now too?

summon
- rework doahaus summoning/orphan flow to use single table



 ## Canonical API
 
 - single table (airtable)
 - universal endpoint/deploy
 - integrate boosts endpoints
 - public endpoints/router
