Thanks for raising these points. Let me clarify how Igra addresses them:
-
EVM Compatibility – we’re using Reth with modifications for Kaspa’s reorgs. Our data component handles L1 → L2 translation, while maintaining standard Ethereum RPC interfaces. Users interact normally through MetaMask, so everything else is compatible. In terms of known temporary limitations, there is 20 kBytes limit for payloads.
-
Reorgs. Kaspa’s frequent shallow reorgs are handled by following L1’s canonical chain. When L1 reorgs, L2 follows. We’ve implemented this in our Reth fork to handle Kaspa’s specific DAG structure.
-
RPC Decentralization. Anyone can run an Igra node and provide RPC endpoints. There’s no centralized relayer – reading from L1 and serve RPC requests are two independent processes.
Handling congestion is a very valid concern. It would be a good problem to have thought. 
L2 fees naturally flow to L1 miners since all sequencing happens on Kaspa. High-priority transactions pay higher L1 fees, maintaining proper incentives. In line with Fees and throughput regulation dynamics - #4 by hashdag