# SiloHAUS - RDF - Spec Session

## Questions
- want to disable rage quit of the share token
- maybe custom share token
- restrict rage quit at the tba level - custom 6551
- custom crypto kittie custom claim contract
- nothing custom - they can do that
- Shares name = {DAO name}-vote
- hide token transfer form
- Summoner needs to query nft collection on summon
- get total supply to set the proportion of claim
- what about non-fixed supply? - we only support fixed supply
- summoner needs to check and validate
- totalSupply
- conforms 721 standard validation

## Contracts

**New loot contract + singleton**
- FixedLoot
- takes totalSupply on init
- takes initialHolder on init
- remove upgradability
- turn off mint
- turn off pause-ability
- adjust beforeTokenTransfer to check new mint/pause rules

**New HOS**
- Makes the baal, safe, sidecar safe
- adjust initparams and initactions
- takes loot template now
- initalSupply and initialHolder (if not safe the HOS creates)
- identify fixedloot in referrer field
- create and set the claim shaman in the baal init
- determine shaman address
- permission level 2 (manager I think)
- sends loot tokens to claim shaman and some to side vault

**Claim shaman contract**
- inits with
- nft contract address
- ratio of tokens to shares
- create tba (at least get address)
- Claim function
- batch option
- checks balanceOf on some nft contract to make a whitelist
- keeps track of tokenIds that have claimed (or have share)
- mints 1 share
- transfers some amount of loot
- * Q: from side vault?
- * Q: does all loot go into shaman? some amount for distro?
- * Q: shaman may need approval from token contract for transferFrom on Safe
- * Q: another option is roles/permissions

**DAO initial config**
- 0 shares, 0 loot
- 33% min retention
- voting period: 3days, grace 2 day
- quorum: 0
- sponsor threshold: 1
- offering: 0
- shares non transferable, loot transferable

**Other Considerations**
- ADMIN UI: daos with this token can't use mintloot proposals
- SUBGRAPH: no summoners provided in SILO - should be fine on the subgraph?

## Data delivery

- HOS will flow down to normal summoners
- main summoner
- sidecar vault
- identify nft dao by referrer?
- General nft holdings per address?
- TBA per nft token?
- Claim shaman
- claim status could be indexed maybe

## UI

**General**
- New custom apps
- Launcher is stand-alone
- Multi-tenent
- create multi-tenent starter
- just swap target_dao for useCurrentDaoContext
- needs a home page not scoped to dao if so
- simple search by name?

**Summon**
- Simple form w/ available fields
- HOC transaction
- Custom arg assembly functions for init params and actions
- Hidden default values
- could be a stepper form

**Claim**
- Connect wallet and find nfts per wallet
- get nfts per address
- get nft claim status from shaman
- Claim function
- takes a list of tokenIDs
- Complexity around data fetching/mashing
- New components
- help nft list
- nft card
- claim
- batch claim modal
- Note: somme older NFTs do not follow the standard

- future
- view all nfts
- maybe batch claim all?
- don't create tbas

**Profile**
- Highly customized version of current profile
- Overview data displays adjusted a bit
- total nfts held index somewhere?
- all meme tokens held by all tbas for the nfts held by the connected account
- held nft list
- claimed tbs that the connected address holds the nft for
- nft card
- profile state with delegate
- delegate single nft
- routes tx through the tba
- function on tba that takes an encoded delgate call function
- delegate many
- maybe a front end multicall library to batch the single delegates (wont work for multiple contracts)
- maybe a middleware contract that allows delegate call to many (needs custom 6551 implimentation)
- to do multi call on multiple contract probably requires calling from a contract and not an EOA. THis could be acomplished if 1 nft/tba owned all other nft/tbas and used a multi call library like the Safe one (still have to send all nfts to tba)
- make pfp
- changes profile image somehow
- use localStorage
- use poster - but requires adding a lot for profile management
- Manage view
- new table
- connect as nft flow??
- more exploration - in scope initially?
- lots of unknowns
- seems like it could identify the tba that will be voting/delegating/submitting proposals/rage quit
- how will that state run through the rest of the app for other functionality scoped to the connected wallet
- can we prioritize the delegation flow for viting/proposing ect...
- profile page doesn't make sense if connected as a tba through tokenbound account
- lots more unknowns

**Holders/Members**
- Doesn't pull data from member list, but from nft holders list somewhere
- Current member list components w/ some small changes

**DAO Info**
- Small component changes

**DAO Settings**
- DAO metadata needs to be updated by a tba
- what address comes through here and does our poster indexer pick that up?
- probably need to adjust how we index this - but we would then need to store

**Proposals**
- Lists/details and new prop forms
- New proposals

**Safes**

**Yeeter proposal** - future
- how to get the shaman address and have it for the setShaman
- better to integrate with yeeter

## Resources

[RDF PROTOTYPE](https://www.figma.com/proto/Bsy8YZDLvjowKBUOHf7yuP/Moloch-RDF?type=design&node-id=29-2195&t=AuHY55gTBaro249g-0&scaling=scale-down-width&page-id=0%3A1&starting-point-node-id=29%3A2195)

[RDF UI DESIGNS FIGMA (with notes)](https://www.figma.com/file/Bsy8YZDLvjowKBUOHf7yuP/Moloch-RDF?type=design&node-id=0%3A1&mode=design&t=AuHY55gTBaro249g-1)

[airstack](https://app.airstack.xyz/)

TokenBound SDK?

## Silo Core

Uses TBA DAOhaus, but has a different onboarding flow
- enables creataing new collections
- nft sale to seed the dao