Ethereum Compatibility and Known Constraints

Igra is EVM-compatible. Standard Ethereum tooling, wallets, and smart contracts work without modification. This page documents the differences that developers and integrators should be aware of.

What Works Exactly Like Ethereum

Feature	Status
Transaction signing	secp256k1 ECDSA, identical to Ethereum
Address format	0x-prefixed, 20 bytes
Smart contracts	Standard Solidity/Vyper, no modifications needed
EVM opcodes	Full support, no custom opcodes
Transaction types	Legacy, EIP-2930, EIP-1559, EIP-4844
JSON-RPC API	Standard Ethereum RPC
Wallets	MetaMask, Ledger, Tangem, any EVM wallet
Libraries	ethers.js, web3.js, viem work as-is

If you have deployed contracts on Ethereum or any EVM chain, they will work on Igra without changes.

---

Key Differences

1. Block Time and Confirmation Speed

Igra produces blocks at 1 block per second (1 BPS). Transactions typically confirm in under 1 second.

This is significantly faster than Ethereum's ~12 second block time.

2. Finality Model

Igra inherits security from Kaspa L1's Proof-of-Work BlockDAG. Unlike Ethereum's deterministic PoS finality, the finality in PoW is probabilistic: attack probability drops exponentially with confirmations, reaching negligible levels within seconds.

After 12 hours, Kaspa's finality protocol kicks in and provides deterministic finality.

Recommendations by use case:

Use Case	Recommended Confs	Recommended Wait
Low-value transfers	50	8.5 seconds
DEX swaps, DeFi	300	33 seconds
High-value transfers	2000	4 minutes
Exchange deposits	4000 (or use finalized block tag)	8 minutes
Formal compliance	--	12 hours

The finalized block tag in RPC returns blocks older than the 12-hour pruning window.

For the security math behind these numbers, see Igra Finality Explained.

3. Reorganizations (Reorgs)

Reorgs are an operational characteristic of the network, not exceptional events. When a reorg occurs:

• Transactions in the reverted blocks are discarded, not re-added to mempool

• Users must resubmit transactions manually (or wallet must handle this)

• The removed: true flag in eth_subscribe("logs") signals reverted events

Why transactions are discarded: This is a deliberate design choice for consistency. Re-injecting transactions after reorg can cause state conflicts in an L2 environment where L1 is the source of truth.

Practical impact: Reorgs deeper than a few blocks are extremely rare (see finality math above). Most users will never experience a reorg. Applications handling high-value transactions should implement reorg monitoring.

Detection methods:

Method	Explicit Signal	Real-time	Coverage
eth_subscribe("logs")	Yes (removed: true)	Yes	Only event-emitting txs
eth_subscribe("newHeads")	No (infer from parentHash)	Yes	All blocks
Poll eth_getTransactionReceipt	Yes (null = gone)	No	Specific transactions

For most applications, standard wallet behavior is sufficient. High-value applications should track transactions until the 12-hour finality window.

4. Mempool Behavior

Behavior	Ethereum	Igra
Transaction ordering	Gas price (MEV possible)	FIFO (MEV-resistant)
Reorged transactions	Re-injected to mempool	Discarded
Pool clearing	Async (background)	Synchronous (blocks until consistent)

MEV resistance: FIFO ordering means transactions are processed in arrival order, not by gas price. This eliminates most MEV extraction strategies but means you cannot "speed up" a pending transaction by increasing gas.

5. Synthetic Timestamps

Block timestamps on Igra are derived from Kaspa L1 DAA (Difficulty Adjustment Algorithm) scores, not wall-clock time.

Current behavior:

• Timestamps may lag behind real time (up to ~2 hours on testnet)

• block.timestamp in Solidity does not reflect actual time

Impact:

• Time-sensitive contracts (vesting, auctions, deadlines) should account for lag

• Oracles providing time-dependent data should use external time sources

Status: A timestamp correction mechanism will be deployed at mainnet launch. This will significantly reduce lag. Future Kaspa L1 upgrades may embed precise timestamps natively.

6. Transaction Size Limit

Maximum transaction size: ~21 KB

Transactions larger than this limit are rejected at the RPC layer. This constraint comes from Kaspa L1 data availability limits.

Impact: Most transactions are well under this limit. Complex contract deployments or transactions with large calldata may need to be split.

7. Gas Configuration

Parameter	Ethereum Mainnet	Igra
Block gas limit	30M	10B (10 billion)
Base fee	Variable (~10-50 Gwei)	1 wei
Fee cap protection	Yes	No (txfeecap: 0)

The high gas limit allows complex transactions that would fail on Ethereum. The low base fee means transaction costs are minimal. However, there is no maximum fee cap protection, so double-check gas settings before signing.

---

Network Parameters

Testnet (Caravel)

Parameter	Value
Network Name	IGRA Caravel Testnet
Chain ID	19416 (0x4BD8)
Currency Symbol	iKAS
Decimals	18
RPC URL	https://caravel.igralabs.com:8545
Block Explorer	https://explorer.caravel.igralabs.com

---

Summary

Aspect	Same as Ethereum?	Notes
Transaction signing	✅ Yes	secp256k1 ECDSA
Address format	✅ Yes	0x, 20 bytes
Smart contracts	✅ Yes	Standard EVM
Block time	⚡ Faster	1 BPS vs 12s
Finality	⚠️ Different	Probabilistic, ~10s users, ~30s practical / 12h formal
Reorg handling	⚠️ Different	Txs discarded, not re-injected
Mempool	⚠️ Different	FIFO ordering, MEV-resistant
Timestamps	⚠️ Different	Synthetic, lag possible (fix at mainnet)
Tx size	⚠️ Different	~21 KB limit
Gas limit	⚠️ Different	10B

For most developers deploying standard contracts, Igra works like any EVM chain. The differences primarily affect infrastructure providers, exchanges, and applications with strict timing or finality requirements.

---

Further Reading

• Igra Transaction Protocol - Entry/Exit bridge transactions

• Igra Attesting Protocol - ZK proof system

• Architecture Overview - How Igra works with Kaspa L1