Transaction filtering

The ZK Chain operators can filter both the transactions initiated from L1 and the ones submitted via API directly to L2.

L1->L2 Transactions

To filter L1→L2 transactions coming through the Diamond proxy, operators shall:

1. Implement & deploy the TransactionFilterer contract which implement the ITransactionFilterer
2. Have the TransactionFilterer address set in the state transition storage (by using this function).

If the filterer exists, it will be called by the Mailbox facet with the tx details, and will return whether the transaction can be executed. To disable L1→L2 filtering, the same function that registers the filtered to the storage can be used with 0x0 address.

L2 Transactions

To filter the transactions sent via the API, operators shall include filtering logic before txs get to the mempool.

To do this, an alternative TxSinkLayer must be implemented and used by the node framework by modifying the code here. For reference,

• See Node Framework example
• See example implementation

Note on Withdrawals

Imagine a case where a user deposited funds and then was added to the denylist or removed from the allowlist. In that scenario, the user may have their funds locked on the L2 or potentially even in a contract on the L2. Please think about handling such cases and ensuring that the user can still withdraw their funds.