Decentralized automation of on-chain operations: a mechanism design example

A deep dive into PowerAgent automation network design

The idea of automating on-chain actions is not novel. Protocols and ordinary users tend to automate routine actions (rewards claims, yield compounding, payment streaming, etc.) and complicated ones (Uniswap v3 positions shifting, liquidation protection, complex yield farming strategies). Our vision is that more than 40% of mainnet txs in 3 years will be done automatically without users' manual signing.

The simplest solution is to launch a bot, listen to on-chain events from an RPC, and automatically sign transactions using scripts. However, such an approach requires certain skills for launch & ongoing maintenance (since the user needs to run an RPC endpoint and the bot itself) and poses certain risks, especially if it is used to maintain some protocol operation (and not just independent user tasks).

The alternative is an automation-as-a-service tool, ideally a decentralized network of keeper bots, powered by stable standalone RPCs and running on properly tested software. To operate stably, protect users from Keeper misbehavior, and perform all necessary operations (such as accounting between users and Keepers, gas compensation, and penalties applied in case of failure), the network should be built on top of specific mechanism design and cryptoeconomic principles, plugged into the algorithms of its operation.

In building PowerPool, we have applied and continually tested certain mechanistic design approaches to ensure the robust operation of such a network of Keeper bots, focusing on decentralization and algorithmic approaches rather than “manual” measures such as Keeper whitelisting or other restrictions. In our view, it should work as an autonomous and self-organizing network.

In this article, we will explore the decentralized Keeper bot network's mechanism design and basic cryptoeconomic rules. This concept works in Gnosis, Ethereum, Arbitrum, and Sepolia, and any curious reader can run a Keeper bot and participate in signing transactions or automate their on-chain actions. Check out our Explorer for Keeper/Job/execution statistics.

Let’s dive into the details!

PowerAgent V2 architecture

The network works with three primary types of entities:

• The Agent
• The Jobs
• The Keepers

The Agent is the smart contract that stores all network state information and mechanism design/cryptoeconomic rules. It includes Keeper/Job registries, executes resulting transactions, and manages underlying components.

This contract is responsible for all the operations within the PowerAgent network:

• Job/Keeper registration and activation
• Random Keeper assignment
• Transaction execution
• Settlements between Job owners and Keepers, which include the gas compensation and execution fee payment
• Keeper security deposit (staking) mechanics and penalties (slashing)

Jobs are the tasks that need to be executed (a sequence of on-chain actions and conditions to trigger them) created by users. Jobs information includes the target contract address, execution logic, eligibility requirements for Keepers such as the minimal CVP stake, and job-specific reward details (such as the stake limiter for reward/slashing amount computation).

Jobs are classified into two categories:

• Interval Jobs that are executed periodically at given time intervals (do something every dT)
• Resolver Jobs' execution is based on arbitrary on-chain logic rather than on time intervals (ex., if x>y, do this; if y<x, do that; if y=x, do nothing).

Keepers are network nodes that execute Jobs according to their execution conditions and triggers. The Keeper software is a lightweight node that listens to network events via Websockets and executes transactions when conditions are met.

Each Keeper is an off-chain bot and contains two addresses: an Admin address for management and a Worker address for execution. The worker address is tightly coupled with the node: the node uses this address to sign and send the transactions related to executing Jobs to the Agent contract.

The Agent, Keepers, and Jobs operate together to execute Jobs correctly and receive rewards/penalties from these executions according to the network rules.

Below, we specify the interrelations of Agent/Jobs/Keepers and typical actions occurring during the network operation:

How do users set up the automatic execution of on-chain actions?

1. A user (a Job Owner) specifies (or deploys) a Smart Contract on an EVM chain. This contract contains a function (target function) that needs to be executed either based on a specific time interval (interval Job) or according to a predefined logic (resolver Job).
2. In the case of a resolver job, an additional function (resolver function) is required to define the executability of the target function at each block. This function is typically deployed within a Smart Contract designed by the user. The user then registers the job using the PowerAgent dApp UI, configures all essential parameters, and deposits tokens to cover keeper compensation. The deposit is made using native tokens, such as ETH for Ethereum and Ethereum rollups, xDAI for Gnosis, or BNB for BNB Chain.
3. When the Job is registered, the PowerAgent network autonomously and randomly assigns a Keeper from the pool of available Keepers to execute the Job, based on the minimal stake specified by the Job owner.
4. Once the condition for target function execution is met, the assigned Keeper signs and sends the transaction to the Agent contract. In case of successful execution, the Keeper receives gas compensation + execution fee; if the transaction is reverted, only the execution fee is received. The network then randomly assigns the next Keeper to handle the next execution.
5. If the assigned Keeper fails to execute the Job within the specified timeframe or according to the condition, another Keeper selected by the network will carry out the task and penalize the failed Keeper by slashing a share of the staked tokens.

This mechanism design offers a synergistic blend of cryptoeconomic incentives that motivate Keepers to participate honestly in the network and execute all transactions when the conditions are met.

Now, let’s dive into the details and explain each step of this process.

Keeper Selection and Assignment

PowerAgent network utilizes random keeper selection to increase the system's robustness towards malicious actions and attacks by making the next assigned keeper unpredictable. By assigning Keepers randomly, the network also alleviates the need for expensive bidding wars between Keepers.

The random selection may be complicated by weighting the probability of a certain keeper being chosen by, for example, its stake size.

On networks with Ethereum POS consensus the pseudorandom number required for Keeper selection is extracted from the block.prevrandao parameter, on other networks the VRF (Verifiable Random Function) is used.

The algorithm for assigning the next Keeper is as follows: https://docs.powerpool.finance/powerpool-and-poweragent-network/power-agent/scenarios#keeper-selection

Transaction execution

Execution is the essence of the network’s functions, so it is heavily optimized for gas savings.

When the execution conditions are met, the assigned Keeper calls the execute_44g58pv fallback function of the Agent contract, passing the required calldata, depending on the Job type and the execution config.

Check out the PPAgentV2 code to learn more about execute_44g58pv.

Upon receiving the execute_44g58pv call, the Agent checks the assertions, loads the call data, and tries to execute the target function (wrapping the call within an always-reverting function to prevent unwanted state changes). If successful, it emits the event and initiates compensation and fee payout, otherwise, it stores the failure response:

Compensations and fees

PowerAgent Keepers are fully compensated for their gas expenses and receive an additional reward for successful execution.

The rewards formula consists of 3 terms: a base (fixed) reward, a reward dependent on the gas used, and a reward dependent on the Keeper’s stake:

reward = fixedReward + min(baseFee, min(agentMaxBaseFee, jobMaxBaseFee)) * (gasUsed + gasOverhead) * rewardMultiplier + min(stake, min(agentMaxStake, jobMaxStake)) * stakeDivisor

Note, that the coefficients for calculating rewards are network-specific and are subject to change when optimizing PowerAgent’s cryptoeconomic model. The purpose of including gasOverhead is that payment computation is not the terminal action in the payout block; consequently, some overhead is needed because otherwise, we’d risk under-compensating some Keepers.

*For reverted transactions, only the gas-dependent part with no premium (min(baseFee, min(agentMaxBaseFee, jobMaxBaseFee)) * (gasUsed + gasOverhead)) is paid

Such an algorithm ensures cost-effectiveness and configurability for Job owners and that Keepers are well incentivized to remain active in the network.

The rewards are, by default, stored inside the Agent state to decrease gas costs; if a node runner wishes to receive them right away, it can be specified in the node configuration, and the rewards will be paid out immediately. Note, however, that transfer gas costs are not covered.

Slashing mechanism

PowerAgent V2 has a built-in automatic slashing mechanism to prevent Keepers from misbehaving and ensure that each transaction is executed correctly and exactly on time (or when conditions are met).

If a Keeper that is assigned to a Job fails to execute it properly, part of its stake will be automatically deducted by the current Slasher upon his execution of the Job**.

**Slashers are Keepers that are chosen for each slashingEpoch (in blocks) using the RoundRobin algorithm.

Slashing works as follows:

• Once execution has been made available, the assigned Keeper has a certain grace period to execute the Job
• After this grace period, he becomes fair game for the assigned Slasher
• If the Slasher executes the Job first, he gains the reward and in addition slashes the negligent Keeper’s stake (the amount slashed also depends on the slashed Keeper’s stake).

The slashing mechanic works similarly for both Interval and resolver Jobs, however, there are some differences in Slasher assignment:

• For Interval Jobs, the current block Slasher slashes underperforming Keepers. If he also fails to execute the Job within a slashingEpoch, a new Slasher will be assigned and try to execute
• For Resolver Jobs, the current block Slasher cannot slash immediately, as the executability condition onset is not known a priori and therefore cannot be immediately verified on-chain. Rather, he must initiate slashing when the Job becomes executable (in practice, sending of the corresponding tx is delayed by a short interval to conserve Slashers’ gas on Jobs that are executed promptly). Upon successful slashing initiation, he becomes locked in as this Job’s Slasher. If he fails to execute the Job, he is unassigned as the Slasher, and initiation occurs anew.

The slashing amount is calculated according to the following algorithms, depending on the Keeper’s stake:

totalSlashAmount = uint88(_rdConfig.slashingFeeFixedCVP * 1 ether + min(keeperStake, min(maxJobStake, maxAgentStake)) * uint256(_rdConfig.slashingFeeBps) / 10_000)

It must be noted that any Keeper whose stake falls below the required minimum (1000 CVP in the current implementation) is automatically disabled to protect Keepers against additional slashing.

The game of Keepers’ stakes

The network-wide minimal stake to become eligible for task execution is 1000 CVP. However, this does not guarantee that all existing Jobs will be available. As explained in the PowerAgent V2 Architecture and Compensation and Fees sections, Job owners configure the stake range for eligible Keepers.

In particular, they can increase the minimum required stake for the Keeper to be assigned to and execute their task. This may be necessary for Jobs with a high cost of no execution (i.e. hypothetical amount of funds lost in case the task is not executed; consider a liquidation protection task that was not executed on time as an example). The Job owner agrees to pay more for the execution to those Keepers who will lose more if they do not execute the Job.

In this perspective, the Keeper’s stake acts as an insurance and a demonstration of honest intents:

• the higher the stake, the more Jobs (which have a high lower bound on Keeper’s stake) are available for execution, but also
• the higher stake amount is slashed if the Keeper fails to execute the task.

The addition of the weighted random Keeper selection will leverage this cryptoeconomic mechanic, as the higher stake will also raise the probability of the Keeper being selected for the next execution, effectively raising the income of the Keepers with higher responsibility.

Conclusion

In this article, we presented a mechanism design for a decentralized network of Keeper bots that execute on-chain transactions according to Jobs submitted by users. It includes Keeper security rules (staking), Keeper penalty rules (slashing), Keeper selection, and Job owner <-> Keeper settlement logic (gas compensation, execution fee, and stake-dependent multiplier).

The network is live on Gnosis, Ethereum, Arbitrum, and Sepolia, and we invite both Keepers and Job owners to test its operation by submitting Jobs or running a Keeper.

Twitter | Discord | YouTube |Telegram | CMC Community | Debank | Medium