---
# System prepended metadata

title: 'Docs Download from Sync with Sam - July 26, 2022'
tags: [V3 Docs]

---

---
###### tags: `V3 Docs`
---

# Docs Download from Sync with Sam - July 26, 2022

---

[Vimeo](https://vimeo.com/733734821/f83c2f3642)

# SDK Overview
The primary motivation of the DAOhaus development kit is to provide a set of tools that make it wasy to read and write the data from our decentralized infrastructure. The contracts write directly to the blockchain, with subgraphs on top of the contracts that make the data more query-able, and a set of additional layers to the infrastructure like Ceramic Nodes that hold data related to addresses, Jobs, and Helm Charts which both cache data from the blockchain to make it easy for our applications to read. Our SDK provides a set of utilities to pull data from this infrastructure and make it beautifully accessible in your applications.

## Utilities
We have provided two groups of utility libraries to help you in your build.

### Common Utilities
Our common utilities are helper utilities, constants, different types, and other data that will be used across all of the different libraries. The blockchain stores time as seconds for each epoch. You might need a quick little function to display this in your app.

We divide our common utilities into Constants, Types, and Utils.

#### Constants
Anything that never changes, including tags, proposal statuses, chain data and ids, etc.

#### Types
Common types used across all the apps.

#### Utils
These are functions you can pull into your app to accomplish all kinds of common actions, such as:
- Dates: timesync
- Encording: data for proposals
- Explorer: generates a link to the block explorer to verify the correct network
- Formatting: truncating or adding addresses
- General: calcultating voting power, the present moment in seconds
- Index: how we organize files so you can easily import them into your app
- Object: helpful JavaScript to create a new object off of another object
- Typeguards: helpers to check if something is an array, a number, a string. Often used for validation on forms, etc.
- Units: helpful for converting from one type of number to another, such as gwei into ETH

### Contract Utilities
A new library we are building to provide ABIs (the json map of a contract) and all their deployed contract addresses. This data tells us about the functions of the contracts, how we can map it, and things of this nature. Contract Utilities also includes TypeScript wrapped versions of the contracts that you can pull into your JavaScript application to make transactions to the contracts.

Contract Utilities are composed of the ABI Utilities and Baal Contract Services.

These utilities are cross-correlated to the Write DAO Data, as these utilities will help you write data to the contracts (make function calls). There is one library called Contract Utilities that will help will writing DAO data needs.

### ABI Utilities
A way to store all the current ABIs and an app to retrieve them. This is very useful in Web3 development. When you are instantiating contracts with various libraries you will need the ABI so the library knows what to do with it.

### Contract Addresses
Helpers that will serve you the deployed contract addresses being used by your network. For example, retrieving the Moloch v3 contract address for the Goerli network.

### Baal Contract Service / Typed Contract Client
A library that wraps your contracts to provide type protection for the arguments you need. This will help you make contract calls from your app. This is one way that our SDK facillitates writing contract data easier. It is combined with Transaction Builder in the form of a React application.

## Data
All the data you would need to access for DAO contracts and their associated proposals, members, etc.

### Read DAO Data
This is our primary DAO data library wrapping the Subgraph, Ceramic queries, and other sources of data to produce nice little data objects that your application can use. We have tried to make querying more simple than directly accessing the Subgraph via GraphQL.

This library is organized as:
- Usage
- Core Features
    - Profile: all the data for a single address, such as ENS, Ceramic profile, and affiliated DAOs
    - Query: explains how to query all the entities of the subgraph, methods for finding lists and single items (proposals, DAOs, members), pagination, filters, and optional parameters
- Utilities: these utilities are very specific to fetching data under the hood for ABI calls. For example:
    - Proposal Filters: what builds a query for making a call to the subgraph for proposal status.
    - Proposal Status: checks the status of a proposal for you

### Write DAO Data
This section will elaborate on some Contract Utilities that will facillitate writing data to the contracts. When we say *writing DAO data* we are referring to function calls to the contract. This section is cross-correlated to a Feature we have provided called Transaction Builder, which demonstrate the power of this stack of utilities.


## UI
There are different kinds of UI building libraries and frameworks built on top of Javascript that developers might choose to use, such as [Vue](https://vuejs.org/) and [Angular](https://angularjs.org/). We are currently only focused on [React](https://reactjs.org/), one of the most popular. The UI package consists of primitive pieces of common web application functionality focused on presentation and consistency across our applications.

### Component Library
We use [Storybook](https://storybook.js.org/docs/react/get-started/introduction) to organize our Component Library according to [Atomic Design principles.](https://bradfrost.com/blog/post/atomic-web-design/)

## Features
Our DAOhaus Features build upon the UI component library to render them as coherent sets of useful functions. The Feature library also relies upon the Data library to read or write data, which is built upon the utilities library. Features are bundled combinations of different functionality provided to make your life much easier.

### DAOhaus Connect

### Transaction Builder
This React-specific feature allows your application to easily make transactions with all the JavaScript app lifecycle functions baked-in to trigger error and success messages, along with other cool features. Transaction Builder demonstrates the power of our Write DAO Data utilities when paired with the React Component Library provided.


## Decentralized Infrastructure

### Subgraphs

- [The Graph has really great documentation!](https://thegraph.com/docs/en/)
- [Check out the DAOhaus Goerli Subgraph](https://thegraph.com/hosted-service/subgraph/hausdao/daohaus-v3-goerli), which also includes a powerful playground feature that will help you understand how data is queried.


Contracts on Ethereum have events that can be written into your contracts. When there is a state change, these events fire off in the contracts. The Graph provides a framework for listening to those events, allowing you to map, rewrite, and transform that data into really sensible entities and databases representing the current state of your contracts. 

Our Subgraph references the Moloch v3 contracts. We have deployed a factory contract for deploying DAO contracts on Moloch v3 and our Subgraph listens to this factory to create templates for each DAO that is launched. We then listen to each DAO contract for the events that they fire off.

The core Moloch v3 contract contains all of the governance and proposal variables. There is also a Gnosis Safe contract comprising the DAO treasury, which we do not listen to (although there may be use cases in the future). A Loot and Share ERC-20 contract is also generated and registered in our Subgraph so we can track every time a token is transferred, created, minted, or burned to display holders and token balances.

Our Subgraph is composed of the following entities (database tables):
- DAO
- Proposal
- Vote
- Record
- Member
- RageQuit
- Shaman
- EventTransaction
- TokenLookup

##### DAO

Displays all the data we track across the DAO contracts. Each DAO has one DAO record.
```
unique identifier and primary key of the entity

id: ID!
timestamp of the block when the dao was summoned

createdAt: String!
address that created the dao

createdBy: Bytes!
transaction hash of the dao contract deployment

txHash: Bytes!
contract address of the loot erc20 token

lootAddress: Bytes!
contract address of the shares erc20 token

sharesAddress: Bytes!
contract address of the gnosis safe treasury

safeAddress: Bytes!
indicates if loot transferability is on/off

lootPaused: Boolean!
indicates if shares transferability is on/off

sharesPaused: Boolean!
length in seconds of the current grace period

gracePeriod: BigInt!
length in seconds of the current voting period

votingPeriod: BigInt!
length in seconds of the current voting period and grace period

votingPlusGraceDuration: BigInt!
amount of network token required as tribute to submit a proposal

proposalOffering: BigInt!
minimum % of shares that must vote yes for it to pass

quorumPercent: BigInt!
amount of shares needed to automatically sponsor a proposal

sponsorThreshold: BigInt!
auto-fails a proposal if more than (1- minRetentionPercent) * total shares exit before processing

minRetentionPercent: BigInt!
name of the erc20 shares token

shareTokenName: String
symbol of the erc20 shares token

shareTokenSymbol: String
name of the erc20 loot token

lootTokenName: String
symbol of the erc20 loot token

lootTokenSymbol: String
total circulating shares tokens

totalShares: BigInt!
total circulating loot tokens

totalLoot: BigInt!
ID of the last sponsored proposal

latestSponsoredProposalId: BigInt!
count of proposal submitted

proposalCount: BigInt!
count of share or loot holding members

activeMemberCount: BigInt!
name of the DAO

name: String
was Dao summoned by an existing safe or did it create a new safe.

existingSafe: Boolean!
proposals scoped to this dao

proposals: [Proposal!]
members scoped to this dao

members: [Member!]!
rage quits scoped to this dao

rageQuits: [RageQuit!]
shaman scoped to this dao

shaman: [Shaman!]
records: [Record!]
eventTransactions: EventTransactio
```

##### Proposal
Every time a proposal is made, we create a proposal entity that is related to the DAO. Most of the logic in our apps are related to proposal state changes: cancellation, sponsorship, voting periods, grace periods, pass, fail, and process. Each of these events updates the state of the proposal.
```
unique identifier and primary key of the entity

id: ID!
block timestamp when the proposal was submitted

createdAt: String!
address that submitted the proposal

createdBy: Bytes!
related DAO entity

dao: Dao!
id of the proposal

proposalId: BigInt!
id of the previous proposal, set at sponsorship

prevProposalId: BigInt!
transaction hash of the proposal

txHash: Bytes!
hash of raw transaction data that will be executed if the proposal passes

proposalDataHash: Bytes!
raw transaction data that will be executed if the proposal passes

proposalData: Bytes!
duration of the voting period for this proposal in seconds

votingPeriod: BigInt!
unix timestamp of when the voting period starts

votingStarts: BigInt!
unix timestamp of when the voting period ends

votingEnds: BigInt!
duration in seconds of the grace period for this proposal in seconds

gracePeriod: BigInt!
duration in seconds of the grace and voting periods for this proposal in seconds

votingPlusGraceDuration: BigInt!
unix timestamp of when the grace period ends

graceEnds: BigInt!
unix timestamp after which proposal should be considered invalid and skipped

expiration: BigInt!
estimated gas needed to execute the proposal actions

actionGasEstimate: BigInt!
string with human readable description of the proposal

details: String!
indicates if the proposal was automatically sponsored

selfSponsor: Boolean!
indicates if the proposal is sponsored

sponsored: Boolean!
address that sponsored the proposal

sponsor: Bytes
transaction hash of the proposal sponsor

sponsorTxHash: Bytes
unix timestamp of when the proposal was sponsored

sponsorTxAt: BigInt
indicates if the proposal is cancelled

cancelled: Boolean!
transaction hash of the cancelled proposal

cancelledTxHash: Bytes
unix timestamp of when the proposal was cancelled

cancelledTxAt: BigInt
the address that cancelled the proposal

cancelledBy: Bytes
indicates if the proposal is processed

processed: Boolean!
transaction hash of processing the proposal

processTxHash: Bytes
the unix timestamp of when the proposal was processed

processTxAt: BigInt
address that processed the proposal

processedBy: Bytes
indicates if the proposal is processed

actionFailed: Boolean!
indicates if the proposal passed

passed: Boolean!
amount of native token that was provided as tribute when the proposal was submitted

proposalOffering: BigInt!
number of current yes votes

yesVotes: BigInt!
number of current no votes

noVotes: BigInt!
amount of current shares that have voted yes

yesBalance: BigInt!
amount of current shares that have voted no

noBalance: BigInt!
is currently paasing quorum and has more yes votes than no votes

currentlyPassing: Boolean!
highest share+loot count during any individual yes vote

maxTotalSharesAndLootAtYesVote: BigInt!
The following tribute fields will only have values if the proposal was submitted through the trbute minion contract. token address in tribute proposals.

tributeToken: Bytes
amount of tribute token offered

tributeOffered: BigInt
symbol of the tribute token

tributeTokenSymbol: String
decimal places of the tribute token

tributeTokenDecimals: BigInt
applicant submitting the tribute proposal

tributeEscrowRecipient: Bytes
proposal type derived from the details field

proposalType: String!
proposal title derived from the details field

title: String
proposal description derived from the details field

description: String
proposal content URI derived from the details field

contentURI: String
proposal Content URI type (ipfs hash, url) derived from the details field

contentURIType: String
votes scoped to this proposal

votes: [Vote!]
```

##### Vote

Every time a member votes it the process gets attached to the proposal entity.
```
unique identifier and primary key of the entity

id: ID!
transaction hash of the vote

txHash: Bytes!
block timestamp when the vote was submitted

createdAt: String!
contract address of the DAO related to this vote

daoAddress: Bytes!
indicates yes vote/no vote

approved: Boolean!
shares balance of the voting member at the time of the vote

balance: BigInt!
related proposal

proposal: Proposal!
related/voting member

member: Member!
```

##### Record
This is what we call the DAO database. We use Poster contracts to track. We have begun defining various schemas for other tables that DAOs might want to manage. This represents off-chain data, so not representing function calls to the contract. Instead we make calls to the Poster contract to generate json that is standardized and mapped into our subgraph to maintain that data. This allows us to validate to ensure alignment our schema, ensure that the individual sending a transaction is a member of the DAO, and verify that the call is made through a DAO vote (ratification). This can be used for any type of table! Pretty exciting stuff.
```
id: ID!
createdAt: String!
createdBy: Bytes!
dao: Dao!
tag: Bytes!
table: String!
contentType: String!
content: String!
```

##### Member
Every time an address receives loots or shares in the DAO a member entity is created. A member is composed on an address and the amount of shares they hold, as well as events like burning and transferring shares.
```
unique identifier and primary key of the entity

id: ID!
block timestamp when the member entity was created (when the address first recieved shares or loot)

createdAt: String!
transaction where the member was created

txHash: Bytes!
related dao

dao: Dao!
address of the member

memberAddress: Bytes!
current shares held by the member

shares: BigInt!
current loot held by the member

loot: BigInt!
address the member is delegating to

delegatingTo: Bytes!
subgraph id of member the address is delegating to

delegatingToMember: Member
the transaction hash when the delegate was last updated

lastDelegateUpdateTxHash: Bytes
total amount of shares this address votes with (thier own plus delegated shares)

delegateShares: BigInt!
members this member is delegating too

delegateOf: [Member!]
related votes

delegateOfCount: BigInt!
votes: [Vote!]
```

##### RageQuit
Upon executing the RageQuit event, this data represents the updates loot and shares.
```
unique identifier and primary key of the entity

id: ID!
block timestamp when the member rage quit

createdAt: String!
the transaction where the RageQuit occurred

txHash: Bytes!
related DAO

dao: Dao!
related member

member: Member!
address the tokens where rage quit to

to: Bytes!
number of shares rage quit

shares: BigInt!
number of loot rage quit

loot: BigInt!
list of treasury token addresses requested in the rage quit

tokens: [Bytes!]!
```

##### Shaman
Every time a Shaman is added to the DAO, the event is recorded here. A DAO can have many Shamans. This simple entity conveys the Shaman's contract address, its related DAO, and permission level.
```
unique identifier and primary key of the entity

id: ID!
block timestamp when the shaman was added

createdAt: String!
related DAO

dao: Dao!
address of the shaman

shamanAddress: Bytes!
permission level of the shaman (0-7)

permissions: BigInt!
```

##### EventTransaction
This entity conveys ways to query the subgraph after transactions are submitted to see when they are completed or failed. All interactions with DAO contracts are recorded here.
```
unique identifier and primary key of the entity

id: ID!
block timestamp of the transaction

createdAt: String!
related DAO

dao: Dao
daoAddress: Bytes
```

##### TokenLookup
This entity connects the token, share, and loot addresses to the DAO. It allows us to record the state changes of these variables.
```
unique identifier and primary key of the entity (share or loot token address)

id: ID!
related DAO

dao: Bytes!
```