Input & Output
The shared config-key pattern across every operation, and how errors surface
Shared Input Pattern
Every operation on this node takes the same three top-level config keys, plus its own operation-specific fields:
| Key | Required | Description |
|---|---|---|
resource | ✓ Yes | One of account, block, transaction, token, nft, contract, ens, gas, wallet, utility. |
operation | ✓ Yes | The operation within that resource, e.g. balance. |
network | No | Any key configured under Ethereum:Networks. Defaults to Ethereum:DefaultNetwork. Ignored by operations that don't call the network (most of utility, and wallet). |
Write operations additionally require a credentialID config key pointing at a vault
CRYPTO_WALLET credential — see Configuration.
Everything else is specific to the chosen resource + operation pair — see that resource's page for the
exact field list.
Shared Output Shape
A successful call returns a JSON object whose shape is documented on each operation's page. Every
result carries a success boolean plus the operation's own fields on success, or
errorCode/errorMessage on failure — there's no additional wrapper envelope
beyond what's shown on each resource page.
Numbers as Strings
Large integers travel as strings. Wei amounts, token amounts, gas units, and similar
values that can exceed what a JSON number/JavaScript double can represent precisely are always
returned (and expected as input) as integer strings — e.g.
"balanceWei": "5000000000000000000",
never a bare JSON number. Downstream steps that need arithmetic on these values should use a
big-integer-safe operation, not naive floating-point math.
How Errors Surface
| Situation | What happens |
|---|---|
Unknown/unconfigured network |
Node throws EthereumNetworkNotConfiguredException before any RPC call is made. |
Missing/invalid required field (e.g. malformed abi JSON) |
Fails fast with a VAL_* error code (e.g. VAL_MISSING_CONTRACT_ADDRESS, VAL_INVALID_ABI) before any network call — see each operation's validation rules on its resource page. |
Write operation with no usable credentialID |
Fails before broadcasting, with a clear "No signing credential configured" message. |
| Contract call reverts | Surfaces as a node-level error with the revert reason where the RPC provider returns one. |
| RPC provider rate limiting (HTTP 429) | EthereumRateLimitHandler retries automatically. See Troubleshooting if it persists. |
contract.multicall — one call in the batch fails |
Partial success — the overall operation still returns success: true; check each entry's own success field. See Contract Operations. |
Writes are not idempotent. Unlike a pure read, calling
transaction.send,
token.transfer, or any other write operation twice with the same input broadcasts two
separate transactions — there's no dedupe. Use account.nonce and explicit
nonce values if a workflow might retry a write step, or guard retries with
transaction.wait/transaction.receipt checks first.