---
# System prepended metadata

title: v3 Blacksmiths Show and Tell (5/27/22)
tags: [' show and tell', ' blacksmiths', v3]

---

---
tags: v3, blacksmiths, show and tell
---

# v3 Blacksmiths Show and Tell (5/27/22)

## Contract and Subgraph Updates

- Subgraph has been updated and redeployed with the events coming in from the ERC20s
    - Tracking shares and loot and DAO shares and loot is from the ERC20s themselves
    - We're on Goerli and right now this is the only network we're supporting since Rinkby isn't going to merge
    - Kovan isn't in the Gnosis Safe API so we should focus on Goerli for our test net
    - We may need to look into options outside of the Gnosis Safe API given this
- Gnosis is on all the networks but the API isn't fully supported on them all
    - We use for token balances and the gas estimation
- If we expand to other networks we may need to look to other sources, but right now in the indexer it's hard to use with multiple data sources already

## Kubernetes Cluster and Infrastructure

- We discussed how we're approaching data processing and had to set up infrastructure to support it
- Set up Kubernetes Cluster on Digital Ocean (we're at this point right now)
    - Kubernetes Dashboard on Digital Ocean provides overview of everything running on the cluster
    - Don't have much up yet -- won't be only deploying but we're also codifying into a Helm Playbook 
        - This is a package manager for Kubernetes
        - Defining our infrastructure as a library to allow others to run DH infrastructure on their own servers
- Check out the K8s docs for understanding of the terms

### Consumer Producer Pattern

- Two jobs right now
- Jobs use this pattern, and leverage Bull library
- Pull data from subgraph -> get all the DAO ids -> push to a queue -> second job pulls from this queue and generates aggregate data (vault data)
- Helm uses Go templates to template out the yaml files that define Kubernetes resources
- Aiming to have the Ceramic node up by next week 
- Will populate from Redis to Ceramic for access by the frontend
- Ceramic document stream id is deterministic and based on specific parameters -- allows us to find specific documents for DAOs
- Helm charts in the `libs` directory in the monorepo
    - Version controlling the Helm packages and push up to a registry for others to use
    - Semantically versioned for others to use as well
    - Document this process and then do videos / docs about how to spin this up

## Typechain

- Do we want to play with this when we get to the Summoner transactions?
- Typechain is a TS package that has the `typechain` command that uses the typechain package to read any contract via the ABI and generates types from it
- Dropped in all the contract ABIs and then ran the `typechain` command
- `nx run baal-contract-service:typechain`
    - Reads the ABIs and then generates the types
    - Spits out generated `.ts` files
    - Has the main type file with all the funtions and types for all the funtion args
    - also has `_factory.ts` files that have commands included for setting up an ethers instance of the contract
    - can then init a `BaalContract` with a provider or RPC endpoint
    - `BaalFactory.connect()` then creates an instance of this
    - Can then wrap this into a contract SDK
- Can play with this during Summoner App build and discover some patterns

### Questions and Considerations

- What can we automate here?
- Pulling down ABIs on the fly like we do in our minion proposals
- Would we be able to generate types from raw data that we get from something like Etherscan?
- Could we use tools to do this locally? What would this mean in a live app?
- Could we provide this for boost devs?
- Do we need the Wrapper class? 
- If we just use Baal Factory it already comes with the types needed so this may be more direct
- Wrapping forces use of keyword arguments instead of positional that provides extra safety

## DAOhaus Project Research Hub

- Looking at different competitors in the DAO space and going through apps and filling out an Airtable research form that aggregates the data
- Started with a comparison chart to give high-level overviews of the tools out there and can identify clear gaps across all of the tools and solutions
- Looks at other info such as UX/features and monetization
- Feature counts across all tools in the ecosystem we looked at
- Will take the highlights from each of these and create an overview report and go through with the devs and designers for things we want to consider adding and identify gaps that we may want to offer solutions for
- Map of all the different UX/features across tools and solutions and how they're used
    - See what features are available and what actions can be taken
    - How do contributors find each other? What are the gaps here? (Contributor Relations)
    - DAO2DAO Relations and user stories
        - Highlight how DAOs can find each other and work together
- Do any of the communities have charters or manifestos?
    - This would be a good data point
    - Licensing?
- DAO platform to DAO platform?
- What would we need to do to share this in the most actionable way?
    - Reports, diagrams, videos? 
    - What can be added to make this as valuable as possible as DAOhaus devs?
    - 