* change reward program from epoch module to block time
* submit
* start time
* continuous distribution, in upgrade handler
* interval and start time but no end date
* has time doesn't matter if time is past
* intervals type (day/week) and number to run
* check date range is valid an not expired on propsal end
* expire over a set amount of block time program intervals
* user needs needs to claim reward expire (name something other than shares)

## Terms

- Share - a unit of a reward pool used to determine the distribution of funds
- Earned by completing a qualifying action
- Qualifing-Action - a task completed on chain that earns shares
- associated with a specific account address
- detected by reviewing events that occur in a gibven block
- Constraint - a precodition that must be satisfied before shares are granted by a qualifying action (Eligibility Criteria)
- Reward Program - a collection of configured constraints, qualifying actions, and rewards funded from a pool

## Questions
- Can we kill / stop / pause a Reward Program?
- What are all the types of Eligibility Criteria?
- Account balance?
- Sequence Number above certain level (not as important as others)
- Voting
- How much do they have in their account
-
- Should RewardProgram Minimum/Maximum be part of an Eligibility Criteria?
- Maybe down the line
- Consider adding a limit on the amount per period per address
- Should MaxRewardByAddress be Eligibility Criteria?
- Yes
- Does it make sense to put timing logic in separate module?
- Maybe it's overkill initially?
- Can we use epoching module?
- I don't think so because it uses block height and we are using times.
- Programs can use their own start date times and intervals. These do not always align with fixed epochs
- How do we check times? Just on block end?
- Begin Block context BlockTime is after expected period end _and_ period has not been processed yet.

## Redesign of Rewards Module
- Logic
- User creates a reward program by...
- They create a transaction for the reward program with its configuration and funding source
- When a block *starts* we...
- We go through each reward program
- Start each reward program that is inactive and has a start time >= block time
- Update all active reward programs
- Create a EpochRewardDistribution if a program is starting or a new iteration is started
- Retain and copy over the active shares that are unclaimed.
- Create a RewardClaim if one does not exist and attach the computed shares to it
- Remove all RewardPrograms, RewardClaims, and Shares that are expired.
- When a block *ends* we...
- Process actions that have occured in a given block and compute shares earned.
- We detect an action by...
- reviewing events from a block in the end block function
- We give a share(s) when...
- when a qualifying action has been performed and the account meets the eligibility criteria
- This is handled when a block ends
- When a reward program ends we...
- Remove it because previous heights have the history
- Users can get a reward by...
- Running a transaction with the reward claim
- We detect expired shares when...
- They are automatically detected because of the time
- Can compute the valid shares at the end of a period ... delete those share records that expired, total those earned, limit to the max allowed in a period ... total all of these amounts for the share count to distribute against.
- We check the expiration time on a reward claim when...
- They are automatically detected because of the time
- We check against the criteria types when...
- There is a qualifying action from a user
- We need to cleanup / remove structures when...
- We no longer need them. We can look back on previous blocks for history
- CLI
- Transactions
- Create Reward Program
- Receive Reward Claim
- Queries
- All Reward Programs
- All Active Reward Programs
- Reward Program by ID
- All Reward Claims
- Reward Claim by ID
- Shares by address
- Unclaimed shares by address
- Expired shared by address
- All Eligibility Criteria
- Eligibility Criteria
- Structures
- Reward Program - Defines an incentive program
- A unique id
- Name
- Address to distribute reward from
- Coins / Reward
- Start time
- Duration
- Iterations (0 iterations could be infinite)
- Criteria

- Share - A portion of a reward claim
- Address of user granted share
- Expiration time
- Claimed
- Reward claim id

- Reward Claim -
- Reward program id
- Shares
- Expiration time

- Eligibility Criteria Types
- Maximum amount of shares
- Minimum amount of shares
- Maximum Reward for an address

- EpochRewardDistribution -> RewardProgramDistribution?
- A unique id
- Reward program id
- Attributes for the epoch/iteration
- Do we still need this?
- Currently it tracks everything about a reward for an epoch
- So it has the total number of shares given out during an epoch
- Maybe we want this for each Iteration of a RewardProgram?

## Monday Meeting Questions

- Do we want an "umbrella object" / "epoch state" to track metadata about an epoch?
- Sum of shares
- Addresses who participated
- Types of actions
- etc...
- This would be helpful for Constraints.
- Will Constraints be applicable to every Qualifying Action?
- If they are, then we will need to make them generic
- If they aren't, then how will users know which constraints go with what actions?
- Would anyone ever want to claim only partial shares for an epoch