A Frame Transaction specific definitions for alternative mempool rules, similar in structure and mostly backward compatible with the ERC-7562 validation rules for ERC-4337 UserOperations.
In the context of EIP-8141 serves as a more permissive, reputation-based system compared to the ‘canonical mempool’ defined as part of the core protocol.
Conceptually, the “reputation” system of ERC-8421/ERC-7562 is similar to that proposed as “MATCHA” with some implementation detail discrepancies - the main one being the unit of accounting (gas used vs transactions seen count).
@alex-forshtat-tbk LIFECYCLE-010 reads the 8250 nonce as one (key, sequence) pair per lane, but in 8250 a tx carries a set of nonce_keys with one shared nonce_seq, and the pool identity is (sender, nonce_keys, nonce_seq). which lane does a tx with keys {a, b} count against, and does “contiguous” apply per key?
also the privacy case 8250 is built for is one shared sender with a fresh key per user at seq 0. SAME_SENDER_MEMPOOL_COUNT = 64 caps that sender at 64 pending, staked or not. is that intended, or could a staked sender get a higher cap there?
Indeed, the LIFECYCLE-010 rule failed to take into account transactions with multiple keys set in nonce_keys. I have pushed a quickfix for this particular rule and will analyze if anything else needs to change throughout the ERC now. Thanks for your feedback!
Also true, updated the text to make sure the SAME_SENDER_MEMPOOL_COUNT does not apply for staked sender addresses. I believe this is the original intent for staked entities in good standing to have no transaction count limits.