---
# System prepended metadata

title: Untitled

---

* 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