Attribute Consumption Rewards

Created by

Remus Golgot

Last updated Jan 31, 2019

The following document details the chosen design of the reward mechanism ( that redistributes attribute consumption amounts back to the validators of the consumed attribute ) and the drawbacks of alternative approaches.


  • Attribute owner (O)

    • The owner of the attribute, the only actor that is allowed to consume his attribute A.
  • Validator (V)

    • Entitled to receive a portion of the attribute consumption amount, as reward for the attribute validation effort.

    • The attribute validation process is not described in this document

  • Reward Faucet (RF)

    • Is the only actor allowed to trigger the reward redistribution mechanism

      • Run Reward Round (RRRTx) transaction
    • Is the sender of all the Reward (RTx) transactions

    • Is the recipient of all the Consume Attribute (CATx) transactions

      • CATx with other recipient values will be invalid, and thus not confirmed in the main chain


  • Attribute validation

    • The Action performed by V as part of the validation process
  • Attribute consumption

    • The Action performed by O, to use his attribute in a scenario required by some outside party.
  • Run Reward Round

    • The Action can only be performed by RF

    • Calculates all the rewards that must be redistributed, which belong to unrewarded attribute consumptions made before the current reward round timestamp

      • for each validator that must receive rewards, a new RTx will be generated.
    • There is a fixed amount of time (RRT) that must pass between reward rounds

      • calculated as difference between the current timestamp and the last round timestamp


  1. V validates some attribute A, which becomes active

  2. O consumes A in some real life scenario

    1. a subsequent CATx is triggered

    2. the amount of the consumption goes to RF

  3. RF runs a Reward Round

    1. if not enough time has passed since the last reward round was created, return an error message

    2. if enough time has passed, perform the unrewarded consumptions calculation (UCC)

      1. take into consideration only consumptions made after the timestamp of the last COMPLETED round (or 0 if no COMPLETED round exists) and before the current round timestamp

      2. take into consideration only validations made in the last calendar year, and after the last attribute update

      3. if rewards have to be given and the round is successfully created ( RRRTx is confirmed ) a new reward round entry is created in the DB

    3. if enough time has passed, but no rewards have to be given based on UCC

      1. if the last reward round is INCOMPLETE, update it to COMPLETE (a new RRRTx will be created)

      2. if the last reward round is COMPLETE, return success message stating this ( no RRRTx required )

      3. no new reward round entry is created in the DB


  • CATx

    • the fee of this transaction is supported by the owner of the consumed attribute

    • the entire amount goes to RF

  • RTx

    • the fee of this transaction is supported by RF

    • the entire amount goes to V ( the amount is the sum of all the individual rewards in the current reward round minus the fee of the RTx)

    • RF can never have less than 2 times the fee required for RRRTx ( one for running the next round and one for a possible update of the last round )

    • Each RTx asset will contain information as to what were the actual consumptions that are part of that reward

      • to be used during UCC
  • RRRTx

    • the fee of this transaction is supported by RF

    • the amount is 0

    • for the first ever reward round, RF will not be empty, because the first ever round will only be triggered if at least one CATx exists.


  • Only RF can run a reward round ( RRRTx will fail during the verification stage if someone tries to impersonate), so there is no way of an attacker to hijack the triggering mechanism

  • UCC will consider only existing transactions in the blockchain, and not locally saved data from the DB.

Other approaches and their drawbacks

  1. Each CATx triggers an individual RTx for each validator ( no UCC and no reward rounds )

    1. the number of RTx is very large ( each CATx triggers a minimum of 1 RTx, but potentially a lot, lot more )

    2. instead of the RTx fee being subtracted once, the validator will "lose" the RTx fee for each such transaction

  2. Ad hoc calculation of rewards ( UCC with no rounds  )

    1. each UCC would require going through the entire blockchain

      1. considering all the CATx and RTx and all their timestamps

      2. UCC will eventually be too exhaustive, especially after lots of CATx and RTx are made.

    2. so there has to be a way to limit the UCC ( like using a last completed round timestamp )