Ctrlk
For the complete documentation index, see llms.txt. This page is also available as Markdown.

Flags

Herein flags and configs they enter are given.

Flag checking

Since configs are made and passed in binary form with the flags occupying nonoverlapping bits, the truth of any flag can be obtained by taking bitwise AND with the specially configured indicator byte. Say, for instance, that we have a certain flag be the last bit of the byte

0x00011010

And wish to see if it is True. Obviously, bitwise AND with the byte

0x00000001

Produces the desired result, as it is nonzero iff the last bits of both bytes are nonzero.

Flag setting

When a config is created anew, any flag can be set by taking bitwise OR thereof with the flag constant.

Execution calldata config

Recall that the execution calldata possesses a set binary representation.

The calldata layout is presented below:

Calldata layout
0x                       |        name       | size int  | bytes |   bits    |
00000000                 | selector          |  uint32   |   4   |  0-31     |
0000...0000 x40          | address           |  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  |

The config field here is one byte which the keeper constructs anew at each execution attempt from two flags he may set as he pleases. This byte is used to configure behaviour of the execution function with respect to reward computation and disbursement.

The config byte layout is presented below

The flag FLAG_ACCEPT_MAX_BASE_FEE_LIMIT has the purpose of overriding the exception throwing in cases of the block gas basefee being in excess of the cap imposed for the purposes of calculating dynamic job rewards by the Job being executed. When this exception throwing is overridden, however, the Keeper in essence assents to receiving less reward for this execution than he could expect if no such cap was in place, since in such a case the gas fee used for computation of rewards is taken to be the minimum between the maximal Job fee and the block basefee.

The flag FLAG_ACCRUE_REWARD has to do with the payout mechanisms. If this flag is True, the Keeper's reward is accrued in the mapping mapping(uint256 => uint256) internal compensations, with his ID serving as a key, and can be manually withdrawn at a later date, thereby decreasing the total amount of necessary transactions. If this flag is False, however, the reward is directly paid to the Keeper's worker (via msg.sender) in the payout block of execute_44g58pv.

Job config

Recall that the job also possesses a set binary representation.

The job binary layout is presented below:

The config field here is one byte which the job owner constructs from four flags he may set as he pleases at registration or update of the Job. This byte is used to configure behaviour of the Job.

The config byte layout is presented below

The flag CFG_CHECK_KEEPER_MIN_CVP_DEPOSIT lets the contract know that the stake of the keeper scoped for execution should be checked to see whether it satisfies the Job's minimal-stake condition. The job owner, in actuality, cannot both set a nonzero minimal stake and allow this flag to be False: if he tries to do this with updateJob, the config byte will be automatically changed so that the flag reads True. Conversely, if no minimal stake is specified, then the flag will be made False if necessary. At Job registration the job owner does not specify this flag at all, and it is initially set automatically in accordance with the minimal demanded stake being nonzero.

The flag CFG_ASSERT_RESOLVER_SELECTOR lets the contract know that at execution the Resolver selector passed by the Keeper in calldata matches the expected ground-truth Resolver selector supplied in the binary job representation.

The flag CFG_USE_JOB_OWNER_CREDITS specifies that the credits of the job owner and not the Job itself are to be used to pay for this specific Job's execution. When it is True, Job credits are not used under any circumstances, and lack of credits at the job owner's account will lead to a revert even if funds are plentiful at the Job's account.

The flag CFG_ACTIVE signifies that the Job is active and may be considered for execution. Inactive Jobs are not executed.

Technical flags. Clearing binary data.

Three technical flags are extant.

BM_CLEAR_CONFIG

This flag in a binary form has 1 in every position except the trailing byte. It is used to update the job binary data with the new config byte, since bitwise AND with it preserves everything but the config byte (set in a trailing position by design) and zeroes the latter. A new config byte may then be added by means of a bitwise OR.

BM_CLEAR_CREDITS

This flag in a binary form has 1 in every position except those 11 bytes that correspond to the Job's nativeCredits property (the Job's balance in native tokens). It is used to update the job binary data with the new balance data in a gas-efficient manner within the execute_44g58pv function, since bitwise AND with it preserves everything but the nativeCredits data and zeroes the latter. A new credit value may then be added by means of a bitwise OR.

BM_CLEAR_LAST_UPDATE_AT

This flag in a binary form has 1 in every position except those leading 4 bytes that correspond to the Job's lastExecAt property (the Job's last execution timestamp). It is used to update the job binary data with the new last execution timestamp in a gas-efficient manner within the execute_44g58pv function, since bitwise AND with it preserves everything but the lastExecAt data and zeroes the latter. A last execution timestamp value may then be added by means of a bitwise OR.

PreviousModifiersNextJob Registration Guide (Old)

Last updated

Was this helpful?