# sumple signal tcr

here is the 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

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)

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.

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)

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 balance.here is the 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

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)

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.

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)

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 balance.