PowerPool
  • powerpool overview
    • PowerPool
      • PowerPool DAO Story
      • Value Proposition
      • Use Cases
      • CVP Token
      • Vision 2027
    • Blockchain Automation
      • Glossary
    • PowerAgent Stats
    • How to contribute
    • Contracts and Links
  • Power Agent
    • 🎯PowerAgent features
    • 🏛️Architecture
      • ℹ️Agent
      • ℹ️Keeper
      • ℹ️Job
        • Full Specification
    • 📜User Guides and Instructions
      • ❓I Want to Automate my Tasks
        • Job Registration Guide
      • ❓I Want to Become a Keeper
    • ℹ️Scenarios
    • ⌛Old Pages
      • Installation Guide (Old)
        • Prerequisites
        • DAppNode Installation
        • Registering in PowerAgent
        • Installing PowerAgent Package on DAppNode
        • Standalone Installation
        • Chain-specific configs
      • Keeper (Old)
        • Keeper Registration and Update
        • Keeper staking, withdrawal, and deactivation
          • Keeper activation and deactivation in PPAgentV2RANDAO
        • Keeper assignment and release in RanDAO realisation
      • Job (Old)
        • Job Registration & Update
        • Job funds deposition and withdrawal
      • Agent (old)
        • Page
        • Execution
      • Technical Implementation (Old)
        • Hooks and helper functions
        • Errors
        • Modifiers
          • Flags
      • Job Registration Guide (Old)
      • 📑Testnet Rules
      • Slashing
        • Copy of Slashing
      • Task Reward and Gas Compensation
        • Fees and income sources
        • Copy of Task Reward and Gas Compensation
  • PowerPool Incentives
    • PowerPool Points Program
  • Security
    • Bug Bounty
    • Security Audits
  • Research
    • Automation Networks Research
      • Approaches on Keeper Selection
      • On-chain Random Number Generation
      • Keeper Weighing
      • 🌊PowerPool & PowerAgent Automation Network
      • Value Proposition-PowerPool
    • PowerAgent v2.1
      • Keeper Selection
      • Hooks
  • Resources
    • Website
    • Twitter
    • Medium
    • Discord
    • Github
    • Telegram
    • Governance Voting
    • Governance Forum
  • Legacy & Deprecated
    • Index Products
      • $YLA: Yearn Lazy Ape
        • Invest (ZAP) in YLA with low fees
        • Instant YLA mint via USDC
        • $CVP Boost Program
        • Redeem YLA
        • YLA Onsen Liquidity Mining [deprecated]
      • $BSCDEFI: BSC DeFi Pool/Index
        • Guide: Mint $BSCDEFI with $BNB
        • Guide: Multi-Asset $BSCDEFI Mint
        • Guide: PancakeSwap LM Farming
        • Add $BSCDEFI to MetaMask.
        • Redeem $BSCDEFI
      • $ASSY: Aave, SushiSwap, Synthetix, and Yearn Index
        • $CVP Boost Program
        • Underlying Token Staking
      • $PIPT: PowerIndex Pool
      • $YETI: Yearn Ecosystem Index
      • Market Price vs Fair Value
      • About ZAP
    • CVP reward program
      • How to create a DCA flow in Partitura
Powered by GitBook
On this page
  • Overview
  • Job types
  • Interval
  • Resolver
  • Short Specification

Was this helpful?

  1. Power Agent
  2. Architecture

Job

Description of the Job entity in PowerAgent

PreviousKeeperNextFull Specification

Last updated 1 year ago

Was this helpful?

Overview

To automate their smart contract execution, a user must submit the task into the PowerAgent network. It is done via an intuitive UI in the PowerAgent dApp. The guide on how to submit your task is located .

The Job is basically comprised of two parts:

  • The target smart contract, complemented perhaps with a resolver smart contract (see below) and

  • The binary information about the execution properties (stored inside The Agent).


Job types

There may be two types of the Jobs: Interval-based and Resolver-based.

Interval

Interval-based job is the basic task that requires execution of a certain function in the smart contract periodically. To register this Job, you only provide the selector of the function to be called during execution and the execution interval.

For example, if there exists a helper contract which has a function of harvesting rewards from a vault necessarily with restake, such a job will be a Selector job; no parameter enters the target function, since it is fixed via the helper wrapper.

Predefined calldata

Alongside with the selector, you may set predefined calldata that must be passed to the function during execution.

If the reward harvest function is parameterized and invoked directly, this job will instead be a Predefined Calldata job: the harvest function is called with a boolean (True or False) argument to either restake or collect the reward.

Resolver

This job execution scenario is based on arbitrary logic rather than on time intervals.

A resolver is a function that defines the conditions of the target function execution. A resolver contains the logic to define if the job should be executed and returns the calldata to pass to the job function for execution. You have to configure and deploy the resolver before submitting your task for automation.

Finally, if you want that to harvest rewards only when a certain amount of them i accrued, and possibly their restaking is also dependent on some on-chain conditions, such a job will be a Resolver job, which relies upon on-chain logic (in the simplest case, a comparison of the accrued amount with a threshold value).


Short Specification

The Agent stores the job as a formatted binary string (see the full specification for the details). This binary string corresponds to essentially a nested struct with the following fields:

{
    "targetAddress": address, //the target address
    "id": uint256, //the number of this job among all jobs with the same target address
    "key": bytes32, //unique identifier; equals keccak256(targetAddress[96:]||id[232:])
    
    "config": {
        "isActive": bool, //job activity flag
        "usesJobOwnerCredits": bool, //whether to pay with job or job owner balance
        "assertResolverSelector": bool, //assert that the returned calldata matches the provided selector
        "checkAssignedKeeperMinCvpDeposit": bool //check that the keeper has no less than a job-specific amount staked
    },

    "selector": bytes4, //selector of the target method; valid only for Selector type
    "credits": uint88, //the job's balance for payment
    "maxBaseFeeGwei": uint16, // a cap on the block’s base gas fee for the purposes of computing rewards
    "rewardPct": uint16, //unused in the current implementation
    "fixedReward": uint32, //a cap on the keeper stake for the purposes of computing rewards
    "jobMinCvp": uint256, //the minimal stake the executor must possess
    "calldataSource": uint8, //enum of calldata sources; [SELECTOR, PREDEF_CDATA, RESOLVER]
    "intervalSeconds": uint24, //interval size in seconds; only for interval jobs
    "lastExecutionAt": uint32, // last execution timestamp; only for interval jobs
    "predefinedCalldata": bytes, //predefined calldata bytestring, for the appropriate source
    "resolverAddress": address, //resolver contract address for resolver jobs
    "resolverCalldata": bytes //calldata to pass to the resolver contract (for resolver jobs)
}

During registration, the user only provides the following data:

  • calldataSource

  • targetAddress

  • intervalSeconds

  • resolverAddress

  • resolverCalldata

  • predefinedCalldata

  • selector

  • jobMinCvp

  • credits

  • config

When registering a job via UI, most of the fields are implicitly set to default values (for instance, usesJobOwnerCredits and assertResolverSelector are automatically set to true).

🏛️
ℹ️
here
Resolver Jobs