25. net_ and web3_ Methods (4 Methods)

The net_ and web3_ JSON-RPC namespaces provide foundational networking telemetry, protocol versioning, and client software identification adhering to the standard Ethereum JSON-RPC specification (§27.2). Implemented in rpc/methods_eth.cpp and registered alongside the eth_ method suite in rpc/methods.hpp, these endpoints serve as the mandatory handshake interface for Web3 developer tooling, wallet providers, and automated infrastructure health monitors.

When Web3 client libraries (such as MetaMask, Ethers.js, Viem, Web3.js, Foundry Cast, and Hardhat) establish a connection to an RPC gateway, their initialization protocol executes an immediate discovery handshake. Before issuing transaction queries or calling contract view methods, client frameworks probe web3_clientVersion and net_version to detect network capabilities, chain ID alignment, and protocol compatibility. If an RPC node omits or misformats responses to these standard discovery methods, Web3 providers immediately treat the endpoint as an unreachable or broken gateway, terminating the connection before higher-level eth_ methods can execute. To guarantee zero-friction compatibility with the global Ethereum developer ecosystem, kortana-node provides instantaneous, lock-free responses for all net_ and web3_ methods directly from the in-memory NodeAccess state snapshot, ensuring maximum responsiveness and zero latency jitter during provider handshakes.

25.1 Network Identification (net_version)

The net_version method returns the decimal numeric string identifier of the active Kortana network configuration (§27.2). Internally, rpc/methods_eth.cpp resolves the network identifier via chain_id_to_numeric(access.status().chain_id), transforming the protocol's canonical UTF-8 network name (such as "kortana-testnet-1" or "kortana-mainnet") into its standardized decimal integer representation: "72511" for the Poseidon Testnet and "9002" for the Kortana Mainnet.

// Request
{
  "jsonrpc": "2.0",
  "method": "net_version",
  "params": [],
  "id": 1
}

// Response
{
  "jsonrpc": "2.0",
  "result": "72511",
  "id": 1
}

While modern EIP-155 transaction signing and wallet networks rely on eth_chainId (which outputs a hexadecimal quantity such as 0x11b3f), legacy Web3 tooling and early Ethereum client libraries specifically require net_version in unquoted decimal format to configure network routing tables, gas estimators, and block explorer URL resolvers. Returning a strictly decimal numeric string prevents JSON parsing exceptions in legacy middleware while maintaining parity with modern dual-stack RPC requirements. Furthermore, automated test suites and continuous integration pipelines query net_version to verify that local ephemeral test harnesses are operating against the expected chain environment before executing deployment scripts.

25.2 P2P Network Telemetry (net_listening & net_peerCount)

The net_listening and net_peerCount methods provide real-time visibility into the operational state of the node daemon's peer-to-peer networking fabric (p2p/ and KortanaNet):

• net_listening: Returns a boolean value (true) indicating that the node daemon's P2P networking subsystem has successfully initialized its socket subsystems, bound to its configured external listening ports (TCP and UDP Port 30303), and is actively accepting inbound peer connections. If the network socket fails to bind or the daemon is configured in offline diagnostic mode, the dispatcher returns false, signaling to load balancers that the instance is disconnected from the global gossip layer.
• net_peerCount: Returns the total count of authenticated, scored, and active P2P peers currently connected in the node's Kademlia routing table, formatted as a standard hexadecimal quantity (e.g. 0x1c for 28 peers). The value is extracted directly from access.status().peer_count under relaxed atomic memory ordering.

// Request: net_peerCount
{
  "jsonrpc": "2.0",
  "method": "net_peerCount",
  "params": [],
  "id": 2
}

// Response
{
  "jsonrpc": "2.0",
  "result": "0x1c",
  "id": 2
}

Load balancers, Kubernetes ingress controllers, and validator orchestration daemons routinely probe net_peerCount to detect peer network isolation. If a node's peer count drops below the minimum fault-tolerance threshold, automated orchestrators can temporarily remove the node from active RPC rotation until healthy peer gossip is re-established.

25.3 Client Software Identification (web3_clientVersion & web3_sha3)

The web3_clientVersion and web3_sha3 methods expose client environment diagnostics and cryptographic utility primitives:

• web3_clientVersion: Returns the authoritative client identification string identifying the node daemon's software version, operating system architecture, and C++ compiler release (for example: "Kortana/v1.0.0/x86_64-linux/gcc-13" or "Kortana/v1.0.0/x86_64-windows/msvc-19"). This string is populated directly from access.status().client_version and is logged by Ethereum node crawlers (such as Ethernodes and custom network analytics dashboards) to monitor network-wide client distribution, hard fork readiness, and software upgrade adoption across validator fleets.
• web3_sha3: Accepts a single arbitrary hexadecimal data string as an argument and computes its 32-byte cryptographic digest using the Ethereum-standard Keccak-256 hashing algorithm, returning the result as a 64-character 0x-prefixed hex string.

// Request: web3_clientVersion
{
  "jsonrpc": "2.0",
  "method": "web3_clientVersion",
  "params": [],
  "id": 3
}

// Response
{
  "jsonrpc": "2.0",
  "result": "Kortana/v1.0.0/x86_64-linux/gcc-13",
  "id": 3
}

This utility method allows lightweight frontends, hardware wallets, and smart contract developer scripts to compute function selectors (e.g. Keccak-256("transfer(address,uint256)")[0..3]) and storage slot mapping keys directly through the node's optimized C++ crypto backend without requiring local cryptographic dependencies.

---