WEMIX RPC: Building on a Gaming-First EVM Chain

The essentials

WEMIX3.0 mainnet is chain ID 1111, an EVM Layer 1 with:

• WEMIX as the gas token (18 decimals) - also used for staking.
• ~1-second blocks - short block times suited to game transaction volume.
• Stake-based Proof-of-Authority - blocks are produced and the network governed by a council of up to 40 Node Council Partners, with a path toward a fuller staked-PoS model.
• EVM-compatible - Solidity contracts and standard Ethereum tooling apply directly.

Connecting

Connecting is boringly standard:

import { createPublicClient, http, defineChain } from "viem";

const wemix = defineChain({
  id: 1111,
  name: "WEMIX3.0",
  nativeCurrency: { name: "WEMIX", symbol: "WEMIX", decimals: 18 },
  rpcUrls: {
    default: { http: ["https://rpc.swiftnodes.io/rpc/wemix?key=YOUR_API_KEY"] },
  },
});

const client = createPublicClient({ chain: wemix, transport: http() });
await client.getBlockNumber(); // just works

WEMIX shares its heritage with another Korean EVM chain we've covered: Wemade originally ran its tokens and games on Ethereum and Klaytn before migrating to its own chain in 2022. If you've built on Kaia (the Klaytn-Finschia merger), the ecosystem and tooling conventions will feel familiar.

Design choice #1: PoA council → instant finality, no reorgs

WEMIX doesn't use permissionless proof-of-stake or proof-of-work - it uses a stake-based Proof-of-Authority council of known validators. That's a genuine trade-off to be honest about (a curated validator set is more centralized than a permissionless one), but it buys a property developers care about: fast, deterministic finality.

The practical payoff for you:

• No reorgs to defend against. With a known council producing blocks under BFT-style finality, a confirmed block stays confirmed. The whole class of reorg-handling defenses - waiting N confirmations, keying on (txHash, logIndex), tolerating tip rollbacks - mostly collapses to "confirm once." You can index at the head and trust it.
• Immediate UX confirmation. For a game, "did my item mint land?" resolves in about a second and won't reverse. You don't have to build the "pending → maybe-reorged" state machine that probabilistic chains force on you. Code written for Ethereum that waits 12 confirmations before treating a transaction as final is just adding a dozen seconds of pointless latency here.

Design choice #2: it's a gaming chain, so plan for game-shaped traffic

WEMIX's reason to exist is its game ecosystem - WEMIX PLAY (the game platform), NILE (DeFi and NFTs), WEMIX Pay (payments), and a stablecoin product. The consequence for an RPC consumer is a traffic profile dominated by high-frequency, asset-centric transactions: item mints, in-game economy transfers, NFT activity - often in bursts around game events or drops.

That shapes your indexing more than your write path (much like the mint-heavy pattern we covered on Zora):

• Filter for asset events. Game items and rewards are ERC-721/1155 mints and transfers. Filter eth_getLogs on the event signature (topics[0]) plus from = 0x0 to isolate mints from ordinary transfers.
• Page dense blocks. At ~1s blocks with burst traffic, a wide block range can return a lot of logs - page by block range and respect the endpoint's log/range limits.
• Stream over WebSocket. For live game state, subscribe to logs / newHeads over wss:// rather than tight polling; at one-second blocks, polling lags fast.

// Stream ERC-721 item mints (Transfer from the zero address) live
const ws = new WebSocket("wss://rpc.swiftnodes.io/ws/wemix?key=YOUR_API_KEY");
ws.onopen = () =>
  ws.send(
    JSON.stringify({
      jsonrpc: "2.0",
      id: 1,
      method: "eth_subscribe",
      params: [
        "logs",
        {
          topics: [
            "0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef", // Transfer
            "0x0000000000000000000000000000000000000000000000000000000000000000", // from 0x0 = mint
          ],
        },
      ],
    })
  );

What carries over unchanged

Past those two considerations, WEMIX is standard EVM:

• eth_call, eth_getBalance, eth_getLogs, eth_getTransactionReceipt, eth_estimateGas, eth_sendRawTransaction, eth_subscribe all behave normally - see reading receipts and gas estimation.
• Solidity contracts, ABIs, and the viem/ethers/hardhat/foundry toolchain deploy and run as-is.
• WEMIX is the gas token with 18 decimals - no exotic fee handling.

The short version

WEMIX3.0 (chain ID 1111) is a gaming-first EVM L1 from Wemade: WEMIX gas, ~1-second blocks, and a stake-based PoA council of up to 40 validators. viem/ethers/foundry work unchanged. The two things that shape building on it: the PoA council gives deterministic finality with no reorgs (drop the confirmation-counting and reorg defenses - confirm once), and the game-heavy traffic means your indexing should be tuned for bursty ERC-721/1155 mint and transfer activity, streamed over WebSocket.

Building a game, a marketplace, or a WEMIX PLAY integration? A flat-rate WEMIX RPC endpoint gives you chain 1111 with WebSocket support alongside 75+ other chains under one key. Grab a free key and point your stack at:
https://rpc.swiftnodes.io/rpc/wemix?key=YOUR_API_KEY

Originally published on the SwiftNodes blog. SwiftNodes provides flat-rate multi-chain RPC endpoints - HTTP + WebSocket, 75+ chains, no per-request metering. Grab a free key.