4 ms·
What's the client interoperability story look like in practice for EVM? Ie how much work if any is required to start using an existing Eth wallet implementation
by 3np 1y ago
What's the client interoperability story look like in practice for EVM? Ie how much work if any is required to start using an existing Eth wallet implementation with [name-redacted] (using the "compatibility ECC layer" I assume?) besides pointing an RPC URL with the right networkID? Are semantics and API for smart contracts similar enough that this would even make sense?
- _9u0i 1y agoGreat question — we're still in the pre-MVP phase, but client interoperability is a key part of our architecture. [name-redacted] includes a compatibility ECC layer designed specifically to support existing Ethereum wallet infrastructure (like MetaMask) with minimal friction. In practice, the idea is that users can connect via standard RPC by setting the appropriate networkID, just as they would for an Ethereum testnet or L2. Under the hood, [name-redacted] uses a hybrid cryptographic design: post-quantum signatures (e.g., Dilithium) are primary, but ECDSA remains fully supported for compatibility. This ensures existing wallet libraries, signing tools, and dApp frameworks can interact with our chain during the transition phase. Regarding smart contract compatibility: our VM is not EVM, but the API design is meant to be semantically close. We're aiming for Solidity-like interoperability via WASM (Ink! / CosmWasm compatible), so existing contracts would need light adaptation, but core logic and interfaces can be reused. We're releasing more details on our architecture soon — your interest means a lot!