compute_unit_floor

Six constants. The first three are the standard sysvar input-region offsets (same as fee_ceiling and program_allowlist): account 0's pubkey at 0x10, its data length at 0x58, its data block at 0x60. See balance_floor for why those specific numbers fall out of the per-account header layout.

Why EXPECTED_IX_DATA_LEN = 4? Our ix data is one u32 holding the floor (4 bytes). We use a u32 instead of a u64 because SetComputeUnitLimit's units field is itself a u32, there is no point storing a floor that ComputeBudget cannot represent. 1 u32 = 4 bytes.

Why CB_LIMIT_IX_LEN = 5? A ComputeBudget SetComputeUnitLimit instruction's data is 1 discriminator byte + 1 u32 units = 5 bytes total.

Why SET_CU_LIMIT_DISC = 2? ComputeBudget's discriminator table: RequestHeapFrame = 1, SetComputeUnitLimit = 2, SetComputeUnitPrice = 3, SetLoadedAccountsDataSizeLimit = 4. We want variant 2 (distinct from fee_ceiling, which wanted variant 3).

Same four-chunk sysvar pubkey compare as the other two sysvar-walking guards. Any mismatch exits 3 with 'bad account'. See fee_ceiling for the full explanation.

Same sysvar walk as fee_ceiling. r3 = pointer to the sysvar's serialized data. r5 = current_instruction_index, read from the LAST 2 bytes of the sysvar data (where the runtime stamps it). r9 = offsets[current_idx] (the byte offset of our own ix's serialization within the sysvar data).

r4 = r3 + r9 = base of our own ix's serialized form. Every byte we read from here is relative to r4.

Same num_accounts * 33 + 34 hop as fee_ceiling to skip past num_accounts (2 bytes) + the account metas (33 bytes each) + the program_id (32 bytes), landing on our ix_data_len.

Validate ix_data_len == 4. Mismatch exits 2.

ldxw r6, [r9 + 2] reads the u32 floor into r6. ldxw loads 4 bytes (vs ldxdw's 8), zero-extending the top 32 bits of r6. r6 now holds the floor for the rest of the program. The +2 is because ix_data_len is itself a u16 (2 bytes), so the actual ix data starts 2 bytes past the length field.

r8 = num_instructions. r7 = 0 (outer counter). r2 = 0 (the found flag).

Why a found flag? This guard has to enforce something subtler than fee_ceiling. It requires that AT LEAST ONE SetComputeUnitLimit greater than or equal to the floor exists in the tx, AND that no SetComputeUnitLimit is below the floor. Single pass through the ixs: set r2 = 1 when we see a valid one. After the loop, if r2 is still 0, no SetComputeUnitLimit was present at all, so we fail.

jge r7, r8, check_found exits the loop into the found-flag check (not directly into success). Even with no violation seen, we still need to verify we found at least one matching ix.

Same pattern as fee_ceiling for locating ix r7's program_id: offsets table, skip num_accounts * 33 + 2 bytes to land on the 32-byte program_id.

Load cb_program_id (the ComputeBudget program's 32-byte pubkey from rodata). Four-chunk u64 compare. First mismatch branches to next_ix (this ix is not a ComputeBudget call, move on).

ix_data_len at offset 32 (right after the 32-byte program_id) must equal 5. Discriminator at offset 34 (program_id + ix_data_len u16) must equal 2. A length of 5 plus a discriminator of 2 effectively narrows us to SetComputeUnitLimit, distinct from fee_ceiling's price check (length 9, disc 3).

If both match, ldxw r4, [r5 + 35] reads the u32 units (4 bytes after the discriminator). ldxw zero-extends so the top 32 bits of r4 are 0.

jlt r4, r6, cu_too_low is strict less-than: if units is less than the floor, exit 1 immediately. Even one undersized SetComputeUnitLimit fails the whole tx, there is no point continuing the walk after a violation.

Otherwise, mov64 r2, 1 marks 'found a valid SetComputeUnitLimit' and falls through to next_ix.

next_ix: add64 r7, 1; ja loop. Walk every ix.

check_found: jeq r2, 0, cu_too_low. If r2 is still 0 after the loop, no SetComputeUnitLimit was found anywhere in the tx. Fail with cu_too_low (exit 1).

This is the 'missing SetComputeUnitLimit also fails' contract. The guard treats 'no explicit limit declared' the same as 'limit below floor'. Solana would otherwise apply a default per-ix CU budget; we do not trust that default. The caller must declare what budget they expect.

ok: mov64 r0, 0; exit. At least one SetComputeUnitLimit was found and met the floor, and no SetComputeUnitLimit was below the floor. Success.

cu_too_low (exit 1): either no SetComputeUnitLimit was found at all, or one was below the floor. Log 'cu too low' (10 bytes). Same exit code for both cases because they mean the same thing semantically: the tx's compute budget does not meet the caller's minimum.

bad_ix_data (exit 2): our own ix data was not exactly 4 bytes. Log 'bad ix data' (11 bytes).

bad_account (exit 3): account 0 was not the Instructions sysvar. Log 'bad account' (11 bytes).

Two 32-byte pubkey constants (the Instructions sysvar key and the ComputeBudget program id) plus three log strings. Same shape as fee_ceiling because both guards walk the same sysvar looking for ComputeBudget instructions, just for different opcodes (and a different comparison direction).