# Community Call Recap – High Council

#
## Community Call #8 – Wed., July 12, 2023 / 1pm ET

### Proposal updates:
- Simona is reaching out to infra providers to obtain some quotes (both startup and ongoing ops cost)
- Arjun reached out to Altlayer and set up a tg chat; they are willing to subsidize initial costs
- Timing will need to be revised given: (1) infra providers have not engaged as we were told they would, (2) existing proposals are stretching past the 1-week consultation period, and (3) we need to consider time for a Snapshot vote (recommended by DAO) prior to official onchain vote.

### High Council mission
- First, align on what Council is – launchpad system, full suite of tools to help DAOs get setup, operate, and benefit from the stack which includes cross-chain enablement and critical tooling – ultimately, promote collaborative governance innovation (TBC)
- Next, we need to align on a clear mission statement, core values, etc.

### High Council Gov Framework & DAO setup
- We need a distinction between member DAOs and individual contributors (operational contributions could potentially be empowered to make decisions that don’t require a full DAO vote) and member DAOs
- Voting on things like treasury decisions, sequencer fee distributions, official tools that endorsed and managed by the DAO, upgrades to the Council protocol version being managed by the DAO
- Could Start with Hats implementation for members to vote with designated Hat NFTs, then launch own DAO with dedicated rollup
- Spencer: we don’t need a full governance structure set up right away (Charles suggested gov minimalist approach to start); once governance is launched the member DAOs can ratify the initial group of contributors
- DAO setup – do we need a legal structure?

#
## Community Call #5 – Wed., May 31, 2023 / 1pm ET

### Arbitrum - options:
1. Arbitrum source code has a license that’s required to run the software; the DAO can issue a license to HC to run the software for an L2 which will require going through the Arbitrum DAO and submitting a proposal requesting the license + a budget request to help with paying a team to run infra for HC
- Arbitrum Foundation proposal —> template on the forum (voting process is outlined in the constitution)
- HC might be the first to request a license from the DAO, no one’s done it yet
2. Could deploy it right away as an L3 on top of Arbitrum One in which case don’t have to worry about the license, can just take the code and deploy it
3. Arbitrum Nova (but may not be ideal for HC)

- Can contact one of the rollup as a service companies to run the infra for us; Offchain Labs will be available to us to provide support and make intros
- Can use the Nitro stack as the underlying rollup protocol
- FYI – Nitro is a new prover that does fraud proofs using WebAssembly (WASM) code. Nitro uses WebAssembly instead of AVM for low-level instruction. It compiles the Go code to WASM, implements to the ArbOS, and includes the most widely utilized Ethereum implementation within the Geth.
- Think about our tech requirements, including Data Availability. Patrick from the Foundation suggested AnyTrust for DA layer (or another committee based layer like EigenLayer). Need to think about trust assumptions around safety and liveness.
- **ACTION**: Questions for Arbitrum Foundation (Patrick) to be put in a doc for async Q&A (Simona)

### Optimism
- We should revisit the decision before proceeding with a technical requirements doc to Ben/Justine for review
- having support on running the infra will likely greatly influence our ultimate decision

### Hats Protocol
- If anyone wants to test out the voting vault powered by Hats, provide the Hats team with your Goerli address and org name
- Also thinking about eligibility requirements for DAOs to maintain active membership and their HC vote (and anything else like distribution of sequencer fees); as soon as a DAO doesn’t meet the eligibility requirements, their HC hat will be revoked and they’d be ineligible to vote
- Goerli deployment was a PoC but Hats is now ready to deploy to any chain that HC group chooses

### General Leadership & Organization
- **ACTION**: Ideal to have leaders emerge for each working group (WG)
- This person can help to define the objective for the WG
- They can do a weekly update (cadence tbd) in Discord or tg and ensure things are getting done
- They would help to define what is needed from their WG for the HC MVP
- Need to set a date for launch and then create workback plan with milestones defined —> **July 14**
- This will help us understand where we’re on track or behind and need for resources
- General Project Management & Roadmap – **ACTION** (Alim)
- Setting realistic deadlines around deliverables, acceptance criteria, addressing open questions
- Would like to have a roadmap for MVP launch
- What are the specific things required from each WG for launch, and by when?
- MVP Scope needs to be well defined
- Start each bi-weekly meeting with what is left For MVP completion, and how much time is remaining to get it done
- MVP spec —> **ACTION**: Alim to chat w/Arjun to get started on laying it out in a doc
- WG consolidation / focus
- Rollup WG focused on figuring out the rollup infrastructure and what stack to build on
- Bridges WG focused on everything related to cross-chain communication including cross-chain voting vaults

## Community Call #4 – Wed., May 17, 2023 / 1pm ET

### OP / Ben & Justine
- **ACTION**: OP needs a doc from us with technical requirements
- OP is focused on building out standards and depending on degree of customization required in the stack, it may be harder to support on the infra side and it may also be harder on OP governance to provide the guarantees that OP is expected to provide for chains that they or others hast
- **ACTION**: Share current OP proposal with Ben and team for feedback on structure, formatting, but also how we can lead with something that will resonate with the OP community; Justine mentioned that she’s open to async’ing on feedback (fyi - a proposal template doesn’t exist yet for allow listing a chain and likely that it will be related to running your own sequencer

## Hats Protocol
- Hats tree structure to help HC from a working group and operations perspective, but also from a member DAO voting flexibility perspective
- HC would wear the ‘top hat’, and membership domain defines who the member DAOs of HC are (they would each wear a ‘member’ hat which is a voting hat) and each member can define additional child hats as needed
- This Hats tree is now on chain with a deployment on Goerli
- Built a voting vaults and wired it up to a test version of council which has also been deployed to Goerli
- Demo’d what it looks like to vote as a member DAO of HC using the Hats voting vault
- **ACTION**: Try it out yourself —> Hats team can create a hat for your org; will need your org name and Goerli address so you can try out the voting

### Connext / Cross-chain
- Update from Arjun needed – he was going to look at current Council Kit and Gyro’s version to make a decision as to which version would be best for the rollup; Gyro has an additional layer between vault and voting contract to get the voting power
- He was going to dive deeper into the the contracts that need to be implemented including their interfaces and functionalities in order to complete the design phase
- **ACTION Items**: (1) take a look at the upgrades being considered for Council in the current and following release, and (2) discuss how to make Gyroscope vaults work in parallel, and (3) complete design phase

### Comms & Media
- **ACTION**: Simona & Charles to chat with Justine and Ben async to gauge interest on officially supporting HC with the announcement
- Justine mentioned that she’ll engage with her partnerships team

#
## Community Call #3 – Wed., May 3, 2023 / 1pm ET

### Cross-chain voting vaults (Arjun/Connext)

- Group had a call a couple of weeks ago to try to unpack the architecture of the voting vaults and figure out from there what it would look like to have that functionality made available across chains
- Currently, you have any number of voting vaults that are deployed on-chain and are tabulated votes using a number of potentially different strategies
- Then there’s the Tally contract which aggregates votes from the voting vaults and potentially applies weights to those votes. And then the DAO reads from the Tally contract to get a final decision. (This is highly simplified)
- So the idea in regards to this process was figuring out how to simplify how voting vaults work without having to deploy Tally contracts across multiple chains and manage them there, or without having to deal with the added complexity of the DAO having to read data across chains
- Conclusion (still needs to be verified) is to split the interface between the Tally contract and the voting vaults, because those do have quite well defined interfaces, creating what's called a mock vault that lives on the High Council rollup
- mock vault is basically just emulating a voting vault; we could just deploy one per connected vault on another chain and have the Tally contract read from the mock vaults on the High Council rollup itself
- And then on the other chains, deploying the actual original voting vaults with a simple adapter that reads the updated voting data from the voting vault and pushes it across chains to the mock vault that lives on High Council
- The above is the most straightforward way to do this in a short time; the ideal way to do this would be using storage proofs from headers that are passed between chains, but this is absolutely technologically prohibitive to do within the next few months.
- this model has a little bit of overhead in that the Tally contract can't continuously read every single vote that comes in, but this would still work in the sense that you could have the voting vault push data to High Council once a day or perhaps even more frequently, and then the Tally contract has a semi updated view of the current state of votes at any time.

**Johannes (Arcade):**
- we have two slightly different versions of Council. We have the vanilla Council version, and then Gyro has a slightly modified version. And specifically, the difference is about this Tally contract.
- For the vanilla version we don't really need the Tally contract. The major difference is that in the vanilla version of Council we have this Core Voting contract where you can pass in the vaults that should be voting on a proposal and the accounting is already done in that step.
- Whereas with the Gyro version there was an additional step beforehand (or even after that?), that goes into the calculation of the actual voting call. I'm not sure if there has been like a decision made on this, but I think we're still contemplating which version to use or if we can find an abstract solution to this, or finding some kind of generic way that works with both architectures

**Mouzayan (Arcade):**
- Arcade’s voting vaults are built on “pure” Council where the voting vaults calculate the voting power of users (or delegatees) and then Core Voting gets that calculate and executes the proposal, there isn’t a separate Tally contract, it goes directly from vault(s) to execution.

**Arjun:**
- We could base HC off this model where we can remove the Tally contract altogether and have the DAO read from multiple mock vaults directly, and have those mock vaults just emulate the exact behaviour of the Council voting vaults so there’s no need for an aggregation step
- Arjun needs to dive deeper into the contracts, need to have more consistent calls just so we can complete the design phase, the contracts that need to be implemented including their interfaces and functionalities
- Bi-weekly call was setup

**Charles (Delv):**
- Delv is releasing a more detailed contribution guide soon and creating a single place for everyone to learn about all of the different versions of Council and what contributors are working on so there’s less information asymmetry
- We also have some updates in Council Kit coming in the next release (June) which might benefit a lot of the High Council members as well

### Tooling:
- Notion or charmverse
- The team voted to use Notion to coordinate work
- We can definitely consider other tools as we complete the MVP phase and potentially expand the number of contributors and working groups in the future.

### Hats protocol to potentially manage membership, roles, voting, workspace access
David Ehrlichman / Hats Protocol
- Protocol for tokenized contributor roles and credentials for DAOs (called “Hats”); Hats are ERC-1155 NFTs which are transferrable by the token holder (“wearer”) and transferable by the DAO (and can be wearable by any address: EOA, multisig, etc.). They can also be claimable and revokable by whatever custom eligibility criteria the DAO wants to set. Hats are connected in a tree structure which enables the creation of different flexible governance structures which are ultimately controllable by the DAO.
- 3 main reasons why this would serve the needs of HC:
1. Revokable access control – rather than manually adding new members and contributors to all of the different workspaces, working groups, and communication channels, can just mint them a Hat which would give them token-gated access to everything they need access to all at once with the specific permissions they need. Access could also be tied to specific eligibility criteria, could integrate Karma data, to say when people are, or are not eligible to continue holding a given role. This can be very powerful for working groups, giving members certain permissions, like access to the right discord channels, the right workspace pages, the ability to vote in snapshot polls, ability to elect working group facilitators and give them certain powers specific to that working group
2. Eligibility and confirmation of DAO membership on-chain via a Hat which is provided and revokable by the DAO
3. Creating a flexible system which allows the members DAOs to vote in High Council in a flexible way which best suits their needs.
- Spencer and team hacked together a simple example of how a voting vault could be created to refer to Hats that allows DAOs to vote in a one DAO one vote way within the High Council
- 1.5-page doc including anticipated challenges for the High Council and how Hats can support (start here): https://docs.google.com/document/d/1i3dJGboD9pv9DyYGzUpr4EVcMSCwdYH3yXLlejRjj-o/edit?usp=sharing
- 2m video that gives a quick overview of a potential Hats tree for the High Council: https://www.loom.com/share/fe75fca1ca58475787214e4c4babc0d0
- Figma file of the potential Hats tree if you want to look more closely at what's shown in the video: https://www.figma.com/file/YZeKhVME0l9KOob
- Voting vault contract that implements the Hats logic for member DAO votes: https://github.com/Hats-Protocol/highcouncil-hats-vault/blob/main/src/HatsHighCouncilVotingVault.sol
- Hats team would love feedback from HC members and if there’s interest, this is something they can build out for HC. They can build this out on testate initially as an MVP with a testnet deployment of High Council and voting vaults to show what this would would work.

### Proposal execution (Arjun)
- As a recap for cross-chain governance, there’s two components: (1) votings vaults, and (2) proposal execution
- Had previously proposed to the group a tool called Zodiac to give DAOs superpowers built on top of a Safe [see recap from last community call for details]
- Onchain infra required to allow a DAO to execute a proposal from High Council but have the proposal outcome actually be executed on other chains, the protocol and mechanism for that was all done pre-High Council inception, so the work has largely been focused on improving the experience of doing this off-chain and for this they’ve been building a widget that can be dropped into any governor UI and can work out of the box for Council; the design of the widget and UI mockups goes through the process of setting up the users Safes and setting them up with Zodiac, verifying a config if they already have one setup, and lastly implementing a tx builder
- Prototype of widget should now be ready; will be getting feedback from High Council members and other DAOs; targeting June 1st production ready and able to be dropped into any governor UI

### OP Proposal
- Proposal for Optimism for OP stack deployment; planning to post to forum but will get some initial feedback from Jing feedback
- 1-pager in progress Ryan, Simona, Bobby
- Charles has a call with Optimism on May 4th and will give them a heads-up about the general proposal + seed the High Council announcement so we can get their marcomms support as well
Announcement:
https://docs.google.com/document/d/1WE0TbcSzFUbyiVV9gOs3pqSwFGEvnYcqnq5JNXc4sN4/edit?usp=sharing
- Charles will invite someone from OP to the next High Council community call

### Council Kit / Ryan
- We’re continuing to add new features + a CLI
- Would like to work with other project implementing new functionality or voting vaults to have that implemented into the tooling

### Action Items:
- Wrap up MVP spec, diagram, and team requirements so we can get building
- Arjun scheduling a call to discuss which version of Council to move forward with and whether or not to use the Tally contract or not
- Hats to get a testnet running with a voting vault for all HC members to test out
- Charles to provide an update on OP stack and OP proposal process
- Join the Discourse! (everyone)

#
## Community Call #2 – Wed., April 12, 2023 / 1pm ET

### Set up Last week:
- Discord was set up, most contributors from the High Council tg group have joined – please go ahead and join working groups if you haven’t already
- Twitter account set up but no announcement posted yet
- Discourse was set up by Ryan. **ACTION Item:** share with the group

### Timing of the official High Council Announcement and Rollup infra (Will)
- Will covered the update he shared in tg/discord regarding the timing of the announcement
- No disagreements with approach to get rollup infra / OP aligned; anyone that disagrees with OP should raise their concerns in Discord
- The way that we should consider announcing this is with everyone co-authoring a proposal to OP and simultaneously work with Jing and the Foundation
- Include diagrams + execution plan in the proposal
- This will allow us to garner very strong support from the community and get people excited
- Then we announce with OP’s support; more concrete and less hypy this way
- Would be good to have a public statement as to why we selected the rollup we did with some technical due diligence and an overview of all the criteria against we evaluated rollup infra options (Unknown speaker)
- Some initial reasons for choosing OP would include (1) modularity, zk could just plug into the architecture, (2) OP’s had a very successful community push, (3) they’re doing account abstraction which could immensely benefit voting and gas efficiency
- Simona: “Is there a minimum stage of build we can have at announcement?”
- Pepo: “We need to define what's within the scope of the MVP to release/announce”
- **ACTION Item:** we need an MVP spec – Rollup/Bridges and SC working groups to collaborate (see high level requirements below)

### Architecture Diagram
- Will and Arjun working with Drew to make updates to first iteration; its currently not reflective of the MVP state
Diagram here: https://discord.com/channels/1093483789507907646/1093483790032179332/1094059134212636672
- Decentralized sequencers is still far out, not an MVP requirement
- MVP requirements (Will)
- Get the rollup launched
- basic governance with Council Kit on the rollup
- bridging and associated contract versions
- The initial diagram we need would show the system with these MVP requirements in mind
- Would be nice to have two diagrams: (1) shows rollup architecture, and (2) how DAOs vote into DAOs (concept of co-op DAOs) – together these would help people grasp the fundamentals of what High Council is
- Would also be great to have a diagram for how bridging would work; this would cover treasury executions as well

### Bridging (Arjun):
- Write as little code as possible so we can ship quickly
- bridging infra already exists
- Use Case 1: Proposal execution (incl. treasury mgmt); DAO lives on one chain but wants to interact with aliases on other chains or interact with a treasury that live on other chains
- Use Case 2: Voting (covered in the voting vault section further below)
- For the first use case, already have something that works in production and is already audited; built into Zodiac which is an existing framework for DAO tooling (its like a DAO modifier/booster pack) that allows you to easily add modules snapshot voting, governance delays, security council, veto option, etc. all deployed through a Gnosis Safe in a no-code way
https://zodiac.wiki/index.php/Introduction:_Zodiac_Standard
- Zodiac Connext Module does something similar by allowing you to deploy aliases (i.e., Safes) on other chains (think an “avatar” on each chain); module attaches itself to a Safe (which is highly secure) and allows you to specify which DAO a message is coming from and then accept messages only from that DAO which lives on High Council
- This general pattern can be used for anything so long as you have a generalized transaction builder for it
- Shared how the Zodiac ConnextModule works (see diagram below)
- Example use case: you have a DAO living on High Council where a governor wants to interact with a lending market contract that lives on another chain to update some parameters of the lending market. Call into Connext which would call into Zodiac (Zodiac would restrict messages to only the ones coming from this specific governor) and then that executes the transaction to the lending market contract.
- This already exists, but the challenge is:
- how do you make this easy for people to deploy this, ideally without writing any code,
- and then how to you make it easy for people to build the transaction for this sort of cross-chain interaction
- Today we have the Safe transaction builder to do this, so we want to do something similar where we have a simple UI where one could drop in the contract ABI (e.g., lending market contract) and similar to etherscan just point and plug in the params, and the output is a pre-built transaction that’s already formatted correctly which you can just give to the governor contract and then the ecosystem can vote on it
**ACTION Item:** architecture & requirements need to be spec'd
- DeFi Wonderland has started the process of figuring out what this UI could look like
- Skeleton Spaceman provided an overview of the crosschain governance flow for DeFi Wonderland (in figma): https://www.figma.com/file/TzpV55mkK4QqMU8PZNyKRB/Crosschain-Governance-Flow?node-id=0-1&t=u7SOgAkzkDpPGKjV-0
- Pepo shared DeFi wonderland’s implementation: https://defi-wonderland.notion.site/Crosschain-DAOs-with-Connext-Zodiac-d4fb747f9760440391f0a135d7ecaf52
- Arjun indicated ways that people can contribute to this effort, please see here for details:
https://discord.com/channels/1093483789507907646/1093584996733812777/1095666983594364938
1. Provide feedback on the flow diagrams
2. UI Design
3. Research on Crosschain Voting

### Smart contracts
- Should there be multiple versions of the core voting contracts on the rollup? Should there be different governance systems offered? (Charles)
- We currently have several versions of the Council voting contracts (i.e., Fiat, Gyroscope, Core version); initially For MVP rather than merging it all we instead deploy each version of the contracts on the rollup and allow projects to choose (Will)
- Each version should be compatible with the Council Kit SDK (Will)
- We should also ensure voting vaults are generally compatible across all versions (Will)
- This is a good process which would entail having a new DAO that wants to deploy first make a selection of the core contracts they want to use and then slot in the Voting Vaults on top of that and have the voting vaults be interchangeable (Ariah)

### Voting Vaults
- Gyroscope (Ariah)
- Outlined a proof-of-personhood vault in the discord previously
- NFT vault tied to proof-of-personhood
- LP shares vault that delegates voting power
- Would like a locking vault that can communicate across a bridge and unlock voting power on the rollup
- More checks and balances that help to align various incentives
- He’ll share more documentation in the discord
- Fiat
- Voting escrow voting vault
- Other ideas
- attestation voting vault (Will)
- ranked choice voting + delegation expiry should be in every DAO’s gov system (Charles)
- Reputation (based on on-chain and off-chain activity) voting vault (Mahesh)
- Crosschain voting vaults (Arjun)
- Not great to port token cross-chain, vote, and bring it back (inefficient and expensive)
- Instead aggregate all votes on single chain, and push to Connext every epoch and post as a single tx on the rollup
- Violet: Why batch and bridge when the purpose of the rollup was to enable cheap transactions?
- Architecture options are still open; Arjun is going to put together a summary with thoughts from Violet and his own + a follow-up call to discuss (**ACTION Item**)
- John Shutt & Kevin Siegler had thoughts and may join
- Shahrukh Rao will share his thoughts in the discord

### Working Groups
- Discord is gated, we can post the output/decisions in Discourse so we can obtain feedback and exchange ideas in a public forum (**ACTION Item for all**)
- Would it be a good idea to group bridges + voting vaults instead of bridges + rollup infra?
- Jonny suggested having a technical general channel
- Alim will prepare a Notion workspace for everyone to have a place (Dave already created it). **ACTION Item:** invite the group to it the week of Apr. 17th once the base structure and pages have been set up.

#
## Community Call #1 – Wed., April 5, 2023 / 1pm ET

### Bridging/Messaging

Arjun / Connext (https://www.connext.network/)
- Utilize rollups for trust minimization and security rather than using 3rd parties
- Connext is a protocol for cross-chain communication
valuable for this group
- Cross-chain proposal execution
- Already have this built out with Zodiac; now working to make this no-code
- Proposal execution should fundamentally be an operational not a technical task
- Cross-chain voting
- Fully compatible with multi-bridge implementation
- Solution is not competitive by any means; bridging solutions can work together

John
- Across Protocol (https://across.to/)
- Also have a Zodiac module
- Bridge assets but also able pass messages to the receiving chains
- Can discuss this further as a bridging option

Greg/ChainSafe
- Sygma (https://buildwithsygma.com/) built on top of Zipline, a trustless Eth bridge
- Zipline can provide the underlying security for Connext
- Stanford discussed a multi-bridge approach that we can look into as well

Kevin Siegler
- Synchronous communication or more relexed?
- Arjun's response: until there’s better sequencer decentralization or overlap, shared sequencing is not there yet; asynchrony is fine for now
- most DAOs 80% start with providing something asynchronous
- Will: I know OP has been working on the shared sequencer side of things, but that won't come for a bit.

### L2/rollup

Will
- Zk rollups need more stability; requires heavy computation which means less decentralization than optimistic rollups
- When there is traction in the zk rollup world, we’ll certainly revisit
- Have been talking to both Optimism and Arbitrum, both want to be involved

?
- Arbitrum’s research team is stellar but Optimism’s tech implementation is better

Arjun Kalsey
- Mantle is incubated by BitDAO
- https://discourse.bitdao.io/c/mantle-proposals/23
- Their team has done a lot of research on zk stacks too
- Their team is focused on making agile decisions wrt to the chain
- They are happy to help build this out

Robin Davids
- Don’t get too focused on what would be cool when comparing rollups


### Attestation
- Charles: How can we use this for identity and reputation
- Reptutational tools are going to be critical for governance; want to avoid plutocracy

Nick (nintynick)/ Hats Protocol
- since Hats are 1155s - they are fundamentally composable with token gates
- and can use reputation primitives, badges, etc. directly in the Eligibility module, programmatic granting and revocation of Hats!
- https://github.com/Hats-Protocol/hats-protocol#eligibility
- A lot of people want to have a top level member or contributor node and then each work stream is its own hat that can create sub streams for members

John / Intuition
- Building identity and attenstation
- Forum where we can pull reputation to off chain platforms
- Trustlessly verify any off chain data points (i.e., creating a proposal on commonwealth or discourse)
- Down to jam on this to discuss what on-chain and off-chain contributions they can port over
- Rhys from commonwealth is going ping John to send over their API docs

Mahesh / Karma
- Surfacing insights of contributors; indexing on-chain and off-chain data
- Talked to Nic about integrating Karma’s data into Hats Protocol

Max Fiege / Fiat
- Not sure if it warrants a whole working group but a task force focused on anonymity solutions a la HeyAnoun would be worthwhile imo

### Sequencers

Greg / ChainSafe
- has some background on why single sequencer approach has been popular
- Most including OP and Arbitrum run single sequencers; its hard to choose people to run that core infra; they are trying to get to progressive decentralization
- Progressive may be the way to go

Will / Delv
- Gryoscope has an implementation
- Recovery mechanism with veto by the DAO (there’s a delay period)
- This model is very interesting
- There are good practices that treasuries can do; proxy contract when an emergency mechanism is triggered to pull funds out
- Challenges around bridges or when sequencer goes down, these are fairly solvable

### Working Groups
- Current working groups: Bridges, rollup infra, gov facilitation / DAO onboarding, comms, voting vaults, gov tooling, Council Kit upgrades, treasury mgmt.
- Gov tooling includes forums, voting, data analysis
- Set up a discord and have general discussion there where people can opt in
- Will: have a spec of what the working group entails and post to discourse
- Gate keep this to people that will contribute
- Create an NFT of contributors with a new DAO and be the first one to migrate over to this High Council rollup
- Charles: @ryan @wouter maybe we just do Gov Smart Contracts & Tooling as separate groups

### Next Steps
- Setup Discord server
- Set up Discourse forum
- poll the group on a knowledge base where we can work on and access all High Council materials in a single place
- Tweet group formation announcement w/members; build traction, excitement, and public support
- Dave offered to help with Discord/Discourse and Twitter
- Call next week and then bi-weekly going forward