# Full Specification ## Job data structure ### Job config To achieve efficiency and save on gas during execution, all manipulations with the Job structure are performed in assembly inserts. The binary representation of `struct Job` is as follows: ```scheme 0x | name | size int | bytes | bits 00000000 | lastExecAt | uint32 | 4 | 0-31 000000 | interval | uint24 | 3 | 32-55 00 | calldataSource | uint8 | 1 | 56-63 00000000 | fixedReward | uint32 | 4 | 64-95 0000 | rewardPct | uint16 | 2 | 96-111 0000000000000000000000 | nativeCredits | uint88 | 11 | 112-199 0000 | maxBaseFeeGwei | uint16 | 2 | 200-215 00000000 | selector | uint32 | 4 | 216-247 00 | config | uint8 | 1 | 248-255 ``` ### Job with calldata config When the job is invoked with some calldata (even if it is just the selector), it is always padded with a few fields, yielding a special binary representation of the calldata as well; the structure is given below. ```scheme 0x | name | size int | bytes | bits | 00000000 | selector | uint32 | 4 | 0-31 | 0000...0000 x40 | JobContractAddress| uint160 | 20 | 32-191 | 000000 | jobId | uint24 | 3 | 192-215 | 00 | config | uint8 | 1 | 216-225 | 000000 | keeperId | uint24 | 3 | 226-249 | 0000... >=1 | executionCalldata | bytes | >=1 | 250-any | ``` Here the `executionCalldata` field contains the calldata proper that is forwarded to the target contract; for `Selector` jobs, for instance, this field is occupied solely by the four bytes of the target method selector, for `Resolver` jobs it contains the **ad hoc** calldata to pass to the target contract, and for the `Predefined Calldata` jobs, it is absent since the fixed calldata is fetched from the job properties inside the execution call. ### Config byte The Job configuration, expanded as a nested struct in the short specification, is a single byte inside the Job structure and defines the properties of the Job. The bits are allocated consecutively in the `uint8 config`. The structure of this byte is given below. ```scheme 0x | name | binary 01 | CFG_ACTIVE | 00000001 02 | CFG_USE_JOB_OWNER_CREDITS | 00000010 04 | CFG_ASSERT_RESOLVER_SELECTOR | 00000100 08 | CFG_CHECK_KEEPER_MIN_CVP_DEPOSIT | 00001000 ``` * `CFG_ACTIVE`Flag of a job being active (i.e., admissible for execution given satisfaction of specified logic). * `CFG_USE_JOB_OWNER_CREDITS`Whether to use job owner credits in native tokens for payment. This makes a hard switch from using job credits to using job owner credits and not just enables it as an option. * `CFG_ASSERT_RESOLVER_SELECTOR`Indicates whether to enforce the selector of a resolver job function matching between the calldata passed by the Keeper and the job binary representation. This may be desirable because under the hood, resolver jobs work like `PRE_DEFINED` jobs, except the calldata is provided by the Keeper. It would therefore be possible for a malicious Keeper to supply a different selector, which is not checkable unless this flag is set to `True`. Has no bearing on interval jobs, since for them, the `calldata` is fixed. * `CFG_CHECK_KEEPER_MIN_CVP_DEPOSIT`Whether to enforce conformance of the stake of keepers and slashers to the minimum required stake of the job. ### --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.powerpool.finance/powerpool-and-poweragent-network/power-agent/architecture/job/full-specification.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.