Roadmap | Ethereum — BizFirstAI

Unlike many community nodes, this one already ships writes. 64 operations across 10 resources are implemented, including signed transactions, ERC-20/ERC-721 transfers, contract deployment, and off-chain message signing. This page covers the specific, narrow gaps that remain — not "everything is read-only," which is not true of this node.

1. account/history — needs an indexer

Standard JSON-RPC has no method to list an address's historical transactions; Ethereum nodes simply don't index by address. This operation fails clearly with INDEXER_NOT_CONFIGURED rather than pretending to work with a partial or misleading result.

What's needed	Notes
An Etherscan-compatible indexer API integration	Etherscan, or a similar block-explorer API, for the target network. Would need its own API key/config, separate from the RPC provider.

2. contract/logs — implemented, not routed

The feature is fully built (a historical eth_getLogs query taking contractAddress, eventAbi, fromBlock/toBlock, topics) and its underlying service method exists — but its case in the executor's operation-routing switch is currently commented out, so resource=contract, operation=logs isn't reachable through the node today. This is a wiring gap, not a missing feature.

3. Live event subscriptions / triggers

This node is an action node only — every operation runs when the workflow step executes. Block/transaction/contract-event/interval listeners that would fire a workflow when something happens on-chain are explicitly out of scope for this build.

Open architectural question, not just unbuilt: trigger-node architecture (how a long-running listener node should work in this platform) is flagged in the design docs as an open question — none of the current platform guidelines cover it, and it needs research against whatever trigger-capable node pattern already exists elsewhere in the codebase before it's built here.

4. ENS beyond plain-ASCII .eth names on mainnet

The ENS implementation is manual (namehash + Registry/Resolver lookups) rather than the dedicated Nethereum.ENS package, to avoid an unreviewed dependency. It's cross-checked against the EIP-137 namehash test vector and known ENS function selectors, but is explicitly flagged for further verification against real ENS test vectors — particularly non-ASCII names (internationalized domain names) and non-.eth TLDs — before being fully trusted in production.

5. Deployment database sync

All 64 operations already have their workflow-designer plumbing authored — Template_DataTemplates (64 files), Process_ProcessElementTypes (the ethereum node type row), and Atlas_Forms (64 files) — but none of it has been synced to a live database yet. That's a separate DbSynch deployment step, not a code gap.

Also required for this node to be discoverable at runtime at all: a ProjectReference alone is not enough in this codebase's plugin-loading mechanism. The explicit line new EthereumDependency().RegisterDefaults(services); must be present in Plugins_RegisterAllNodes(...) in ServiceCollectionExtensionsForAI.cs on the host application. See Configuration.

What's Deliberately Not a Gap

A few things that might look unfinished are actually intentional design decisions, not missing work:

Area	Why it's fine as-is
`token.mint` / `token.burn` / `nft.mint` assuming non-standard extensions	Minting isn't part of ERC-20/ERC-721 at all — there's no "standard" shape to assume. The chosen OpenZeppelin-style convention is the most common in practice, with a `functionName` override for anything else.
`contract.deploy` returning only a transaction hash, not the deployed address	Resolving the address needs the mined receipt — a separate, heavier step by design, kept out of the fast one-shot broadcast pattern every other write follows.
`gas.optimize`'s heuristic multipliers	Clearly labeled in code as a heuristic, not an empirically validated model — treat it as a sensible starting point, not a guarantee.