Protocol support
Fukuii speaks the devp2p wire protocols, discv4 and discv5 discovery, and SNAP state sync, which is what lets it peer with any other client on the networks it runs. The table below names the versions; the prose deliberately does not, because wire protocol versions move with each network's upgrade schedule and a sentence that pins them dates itself.
Above that sits a consensus module rather than a fixed consensus implementation. On Proof-of-Work that means ETChash with ECIP-1099 epoch handling and the getWork surface a mining pool calls. On Proof-of-Stake it means Engine API V1 through V4, driven either by a consensus layer Fukuii runs itself or by an external consensus client. On Proof-of-Authority it means Clique, QBFT and Bor-style producer sets for permissioned networks.
The API surface is JSON-RPC over HTTP, WebSocket and IPC, with GraphQL alongside it and a built-in MCP server for agent tooling. Signing can be delegated to an external signer or an HSM, so the node does not have to hold a key.
| Capability | Support |
|---|---|
| Wire protocols | |
| Discovery | |
| State sync | |
| History | |
| Proof-of-Work | |
| Proof-of-Stake | |
| Proof-of-Authority | |
| Network families | |
| Consensus clients | |
| JSON-RPC transports | |
| Agent interfaces | |
| Other interfaces | |
| Network roles | |
| Storage | |
| Keys and signing | |
| Monitoring | |
| Supply chain |
What does not close
Some areas around that table are continuous rather than finite, and always will be, so treating either as a milestone to be reached would be the wrong shape for them.
Networks keep arriving. A network is a definition rather than a build, so support for a new one is configuration and a fork schedule rather than a fork of the client. That is what makes adding one ordinary work instead of a release event, and it is why the list of what Fukuii runs is expected to keep growing.
The EVM keeps changing. Each network sets its own upgrade schedule, and a client that stops tracking them stops being able to follow the chain at all. Staying current is therefore ongoing work rather than a feature that ships once: the interesting question is never whether a client has finished, but whether it is still keeping pace.
The MCP server
Model Context Protocol is an open standard for exposing structured tools to AI agents. Fukuii ships an MCP server alongside the JSON-RPC transports, so an agent can query a running node directly instead of going through a bespoke integration. A2A and ACP sit beside it for agent-to-agent work, with async tasks for anything that outlasts a single request and OAuth 2.1 for identity on the interface.
Node state, as tools
What the agent can ask for.
- Sync progress and chain height
- Peer counts and connection state
- Block and receipt data
No integration layer
The server is part of the node.
- Nothing to deploy beside the client
- Speaks to any MCP-compatible agent
- Same process, same lifecycle
Agent to agent, too
Not only a tool server.
- A2A for agent-to-agent coordination
- ACP alongside it
- Async tasks for work that outlasts a request
- OAuth 2.1 identity on the interface
What it is for
Operations, not trading.
- Infrastructure automation
- Anomaly detection against live state
- Runbook execution