Docs Download from Sync with Sam - July 26, 2022

--- ###### 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! ```