📘
XCHandles Docs
  • XCHandles FAQ
  • Techincal Manual
    • Pricing Puzzles
    • State Scheduler
    • XCHandles
      • The Register Action
      • The Refund Action
      • The Extend Action
      • The Expire Action
      • The Oracle Action
      • The Update Action
    • DIG Reward Distributor
      • The Sync Action
      • The New Epoch Action
      • The Add Incentives Action
      • The Commit Incentives Action
      • The Add Mirror Action
      • The Remove Mirror Action
      • The Withdraw Incentives Action
      • The Initiate Payout Action
Powered by GitBook
On this page
  1. Techincal Manual
  2. DIG Reward Distributor

The Sync Action

Where the interesting math is found

PreviousDIG Reward DistributorNextThe New Epoch Action

Last updated 3 months ago

Note: The sync action code be found .

The sync action is used to distribute rewards since the last reward distribution. The cumulative payout grows by (/ (* remaining_rewards (- update_time last_update)) (* active_shares (- epoch_end last_update))) . In essence, (/ (- update_time last_update) (- epoch_end last_update)) represents the fraction of time passed compared to the remaining time in the round. Multiplying this by the remaining rewards amount yields the rewards to be distributed. Dividing the results by the number of active shares will return the change in cumulative payout, which is always defined for one share. Note that this result is 'rounded down' by division operations, and that the 'change' is stored in the new state's remaining_rewards.

Syncing can only be done for the current epoch - when the epoch ends (i.e., last_update = epoch_end), the 'new epoch' action must be called.

The action also creates a puzzle announcement that be asserted to ensure the dApp singleton is running the right action with the right parameters. For the sync action, the announcement prefix, s, is concatenated to (sha256tree (update_time . epoch_end)).

Written by from on Feb 16th, 2025.

here
yakuhito
FireAcademy.io