Key operational elements of Plenny are community driven. Administrative action items are shared through the decentralized design of the system with periodic public calls to action. Cash management operations that are centralized in traditional apps have been implemented as open-access triggers, allowing Plenny to divide administrative tasks among community members. These tasks can be performed by any Ethereum-user who is free to trigger the event manually. As a result, users compete on triggering specific economic events that have the following characteristics:
- They need to happen periodically.
- They arte potentially gas-intensive.
To foster decentralization and keep the cost of operating low, those actions are defined as functions any user can call at a specific frequency.
Community-trigger functions and their respective parameters include the following:
- RePLENishment Trigger: Triggering the replenishment of the Treasury HODL by re-distributing the fees collected by Plenny as well as performing burning and buybacks over the liquidity contract on the Sushi V2 DEX using Arbitrum One (Ethereum L2).
- Oracle Election Trigger: Triggering the election of new validators from qualified candidates.
As for the RePLENishment Trigger, the user who calls the function is rewarded a percentage of the monetary value the trigger facilitates. In this way, if the cost for triggering the event is higher than the reward, users might opt not to call the trigger. However, since the reward is cumulative and the cost is fairly fixed, calling the same function at a later point in time results in a reward that is higher than the cost. This implementation ensures there is always a time in which calling a trigger function is economically viable.
In terms of the Oracle Election Trigger, the user who calls the function is rewarded with a fixed amount.