The Two Worlds Problem
The Cosmos and Ethereum ecosystems evolved independently for years. Cosmos built a modular SDK, Byzantine-fault-tolerant consensus, and IBC — a protocol for sovereign chains to communicate. Ethereum built the EVM, Solidity, MetaMask, and a massive developer ecosystem. The two worlds were largely separate until Ethermint (now maintained as cosmos/evm) demonstrated that you could run both on the same chain simultaneously.
Sanect is built on this foundation. Every block contains both Cosmos-native messages — staking delegations, governance votes, IBC transfers — and EVM transactions: contract deployments, token swaps, privacy deposits. Both are finalized together by CometBFT. There is no bridge, no lock-and-mint, no separate confirmation window. One chain, one consensus, two execution environments.
How the EVM Module Works
The x/evm module in Cosmos SDK is an ABCI application module that embeds a Go-Ethereum (go-ethereum) EVM instance. When a transaction arrives at the node, the module determines whether it is a Cosmos message or an Ethereum transaction by inspecting the message type. EVM transactions are wrapped in a MsgEthereumTx Cosmos message and routed through the EVM module's AnteHandler, which performs Ethereum-style signature verification (secp256k1, EIP-155 replay protection) before execution.
Inside the module, the EVM runs against a state adapter that translates between the Cosmos multistore (an IAVL+ Merkle tree) and the StateDB interface that go-ethereum expects. Account balances, contract storage, and bytecode all live in the Cosmos store but are accessed through an EthStateDB wrapper that speaks the go-ethereum interface.
The EVM doesn't have its own state. It writes into the Cosmos store through an adapter. When you call a Solidity contract on Sanect, the storage slots end up in the same Merkle tree as the staking module's validator records.
Transaction Mapping: EVM Calls as Cosmos Messages
Every EVM transaction that reaches the chain is ultimately a MsgEthereumTx — a Cosmos SDK message that wraps the raw Ethereum transaction bytes. This means the EVM has access to all the guarantees Cosmos provides: ordered delivery, deterministic execution, and finality on commit.
The reverse is also true in a limited sense: Cosmos SDK precompiles expose Cosmos modules as EVM contracts at fixed addresses. Calling the staking precompile at 0x0000000000000000000000000000000000000800 from a Solidity contract or MetaMask generates a real Cosmos SDK MsgDelegate — processed by the staking module, reflected in the validator's delegation records, and eligible for staking rewards.
The Precompile Layer
Precompiles are the primary seam between the two worlds. Sanect exposes the following precompile addresses:
0x0800— Staking:delegate,undelegate,redelegate,createValidator,delegation(read). This is how MetaMask users interact with the DPoS layer without touching a Cosmos wallet.0x0801— Distribution:withdrawDelegatorRewards,delegationTotalRewards,claimRewards. Staking rewards are accrued in the Cosmos distribution module and claimed through this precompile.0x0802— IBC Transfer: Initiates cross-chain asset transfers from a Solidity call. Enables future DeFi contracts on Sanect to move assets to Osmosis or Cosmos Hub without leaving the EVM execution context.0x0806— Slashing:unjail(validatorAddr). A jailed validator can unjail themselves by calling this precompile from the operator address in MetaMask.
Precompiles behave identically to regular contracts from the caller's perspective. eth_call, eth_estimateGas, and ABI encoding all work normally. The implementation is a Go function registered at the address — there is no bytecode, no storage, and no deployment transaction.
Address Mapping: Bech32 and 0x
Every account on Sanect has two representations of the same address. The underlying key material is identical — a compressed secp256k1 public key. The EVM representation is the standard Ethereum 0x-prefixed 20-byte address derived from keccak256(pubkey)[12:]. The Cosmos representation is the same 20 bytes encoded as Bech32 with the snct human-readable prefix.
Converting between them is deterministic and reversible. The staking dApp resolves both automatically: when you connect MetaMask, your 0x... address is decoded to the underlying bytes and re-encoded as snct1... for display in Cosmos-facing contexts. No second key pair, no second seed phrase.
CometBFT Consensus for Both
Both Cosmos messages and EVM transactions go through exactly the same consensus path. CometBFT proposes blocks containing []Tx, where each Tx may contain any combination of message types. The proposer builds the block, validators vote in two rounds (prevote + precommit), and the block commits when 2/3+ of stake weight has signed. Finality is immediate and absolute — there are no probabilistic confirmations, no reorgs.
This is one of the most practically useful properties of the architecture for privacy. When a user deposits into the shielded pool (an EVM contract call), the deposit note is final the moment the block commits — typically within 800ms to 1.2 seconds. The user does not have to wait for additional block confirmations before the note is safe to spend.
IBC Readiness
The IBC module is compiled into the Sanect binary from genesis. The infrastructure for cross-chain communication — light client state, connection handshakes, channel lifecycle — is available as soon as relayers are pointed at the chain. Sanect mainnet also supports cross-chain bridging via Hyperlane, with bridge routers deployed for SNCT and 14 bridged ERC-20 assets between Sanect and Ethereum.
From a privacy standpoint, cross-chain interoperability enables scenarios where assets from other chains can be shielded directly on Sanect without first acquiring SNCT: a user bridges USDC from Ethereum via the bridge, deposits into the shielded pool, transacts privately, and withdraws back. The EVM precompile at 0x0802 means IBC-based flows can be scripted in a single Solidity contract.
Why This Architecture for Privacy
Running Cosmos and EVM on the same chain is not purely an engineering convenience — it is a deliberate privacy-infrastructure choice. The EVM side provides the smart contract platform for the shielded pool: the deposit/withdraw contract is plain Solidity, auditable by any EVM security firm, and compatible with standard Ethereum tooling. The Cosmos side provides the staking and governance layer that makes the chain credibly decentralized: validator coordination, slashing, on-chain governance of the privacy parameters.
Privacy without decentralization is a single point of failure. The dual architecture ensures that neither side is sacrificed for the other.