## Simple signal tcr

## Base Contract
here is the spike on signal tcr contract
https://github.com/HausDAO/baal-shamans/tree/feat/tcr/contracts/tcr

it’s based off something from scafold.eth and here is an example subgraph from that

https://github.com/DanieleSalatti/gitcoin-grants-conviction/tree/master/packages/subgraph

## intro
The idea is that a dao uses a proposal to create the token snapshots and deploy this new proposal. (contract is a single signal proposal/contest)

the signal proposal takes as many “grants” as people want to create and staking into one or another is liquid (vote stake into grant id or release votes from grant id).

users can claim their balance (snapshot of current loot and shares) and then make a vote with some amount of their balance.

## votes
the main element is a Vote, a vote has a grant id (hash) that could be mapped to an off chain db or onchain dhdb maybe? there can be multiple votes from a single user to different or the same grant id, as long as they have a balance (this is where the subgraph will be really helpful)

### grant id hashes
a id hash can be mapped to a submission to the onchain dhdb or really any storage, on/off chain. would be cool to require it on chain though and submitted by a share/loot holder. Extra elements of curration could be added on finally tally of winners (staked by verified delegate, thresholds,etc)

## subgraph notes
the main difference here from the example subgraph is we need to track users balances, because we use a snapshot and not a new erc20 balance. VoteCasted event will deduct from a users balance and ClaimTokens or TokensReleased will add to a users