S1C12: Give Me The Block! #

1. Problem #

You need to provide a correctly RLP-encoded block header to call mintFlag. The contract verifies fields such as the block header's timestamp and difficulty.

2. Cause #

The contract implements light-client-style block verification: it accepts an RLP-encoded block header, decodes it, and checks whether the block number falls within the allowed range (current block number - 256 to current block number - 2), as well as the validity of other fields.

3. Solution #

1. Wait for the current transaction to be mined (get block.number)
2. Wait at least 2 blocks
3. Use eth_getBlockByNumber to get the complete header of a historical block
4. RLP-encode that block header
5. Submit within the 256-block window

// Get block header and RLP-encode it
const block = await provider.getBlock(blockNumber);
const rlpEncoded = ethers.utils.RLP.encode([
    block.parentHash,
    block.sha3Uncles,
    block.miner,
    block.stateRoot,
    block.transactionsRoot,
    block.receiptsRoot,
    block.logsBloom,
    block.difficulty,
    block.number,
    block.gasLimit,
    block.gasUsed,
    block.timestamp,
    block.extraData,
    block.mixHash,
    block.nonce,
]);

4. Pitfalls Encountered #

RLP Encoding Format: OP Mainnet block header field encoding is the same as Ethereum mainnet but with subtle differences. The format output by cast block needs to be converted to an RLP-friendly numeric format.

5. Why the Pitfall Occurred #

RLP has strict encoding requirements for each field — numeric types must have leading zeros stripped. OP uses the post-Bedrock upgrade block format, and certain fields (such as difficulty) may differ from standard Ethereum.

6. How to Resolve #

Use cast rlp or JavaScript ethers.utils.RLP.encode for correct encoding. Note:

• difficulty may be 0 on OP
• baseFeePerGas is a required field after EIP-1559 (OP supports 1559)
• The block must be within the [block.number - 256, block.number - 2] range

7. Technical Takeaways #