deps: Bump the nethereum group with 2 updates

[dependabot]

Updated Nethereum.Contracts from 5.0.0 to 6.1.0.

Release notes

Sourced from Nethereum.Contracts's releases.

6.1.0

Nethereum 6.1.0

Nethereum 6.1.0 introduces a complete zero-knowledge proof infrastructure with native and browser-based Groth16 proof generation, the Privacy Pools SDK for private deposits and withdrawals with Association Set Provider support, new Merkle tree libraries (EIP-7864 Binary Trie, Sparse Merkle Trees with Poseidon hashing), SSZ model improvements, cross-platform BLS runtime updates, and demo applications showcasing the full ZK proof pipeline.

Full Changelog

Nethereum.ZkProofs — ZK Proof Abstractions

New provider-agnostic package defining the core interfaces and models for zero-knowledge proof generation in .NET. All proof providers (browser, native, HTTP) implement these abstractions, making them interchangeable.

• IZkProofProvider — central interface with FullProveAsync(ZkProofRequest, CancellationToken) and Scheme property
• ZkProofRequest — input model carrying circuit WASM, zkey, input JSON, witness bytes, and circuit graph data
• ZkProofResult — output model with ProofJson, PublicSignalsJson, and parsed BigInteger[] PublicSignals
• ZkProofScheme enum — Groth16, Plonk, Fflonk, Stark
• ICircuitArtifactSource — pluggable circuit artifact loading (WASM, zkey)
• ICircuitGraphSource — circuit graph data for native witness generation
• FileCircuitArtifactSource and EmbeddedCircuitArtifactSource — filesystem and in-memory artifact loading
• CircuitArtifactLocator — standard directory layout resolver for circuit artifacts
• HttpZkProofProvider — delegates proof generation to a remote HTTP prover endpoint
• Groth16ProofConverter — parse snarkjs JSON proofs and convert to Solidity-compatible format for on-chain verification

Commits: e28026f2

Nethereum.ZkProofsVerifier — Pure C# Groth16 Verification

New package providing Groth16 proof verification using BN128 elliptic curve pairing — entirely in managed C# with no native dependencies. Directly consumes snarkjs/Circom JSON output for one-liner verification.

• CircomGroth16Adapter.Verify(proofJson, vkJson, publicInputsJson) — high-level verification API
• Groth16Verifier — BN128 pairing check implementation using BouncyCastle
• Snarkjs JSON parsers for proofs, verification keys, and public signals
• Returns structured ZkVerificationResult with IsValid and Error properties

Commits: 22fe04a6, 6b3858e8

Nethereum.ZkProofs.Snarkjs — Node.js Proof Backend

New IZkProofProvider implementation that generates Groth16 proofs by invoking snarkjs via a Node.js child process. Suitable for server-side applications where Node.js is available.

Commits: 6d998f5b

Nethereum.ZkProofs.Snarkjs.Blazor — Browser-Based Proof Generation

New IZkProofProvider implementation for Blazor WebAssembly applications. Calls snarkjs via JavaScript interop, enabling client-side proof generation entirely in the browser — private inputs never leave the user's machine.

• SnarkjsBlazorProvider — implements IZkProofProvider and IAsyncDisposable
• Loads snarkjs via <script> tag (UMD bundle) for broad compatibility
• Sends circuit WASM and zkey as base64 to JavaScript, returns proof JSON
• Configurable snarkjs URL (self-hosted or CDN)

Commits: 074a8576, e2a6a738
... (truncated)

6.0.4

Nethereum 6.0.4

Nethereum 6.0.4 adds the new nethereum-dapp Aspire template for full-stack dApp development (Solidity + C# + Blazor + EIP-6963 wallet), fixes Explorer ABI auto-discovery from Foundry artifacts, resolves blazor.web.js compatibility with .NET 10 NuGet-packaged Razor components, improves EIP-6963 wallet CSS and interop, adds a parallel NuGet build script, and introduces GitHub Actions CI with prerelease publishing.

Full Changelog

Nethereum.Aspire.TemplatePack — New nethereum-dapp Template

New full-stack dApp template creating a complete development environment with 9 projects — Solidity contracts (Foundry), C# typed services (code generation), Blazor WebApp with EIP-6963 wallet integration, embedded TDD and E2E tests, and the full DevChain + Indexer + Explorer infrastructure, all orchestrated by .NET Aspire.

• WebApp with EIP-6963 wallet discovery, chain validation, and wallet_addEthereumChain switching
• Three UI states: not connected → wrong chain → correct chain (deploy/mint/transfer/balance)
• Light-themed CSS with card-based layout, form styling, and wallet CSS custom properties
• Foundry contracts project with starter ERC-20 (MyToken + mint), Forge tests, and deploy scripts
• ContractServices with pre-generated C# typed contract access from Solidity ABI
• Tests project with fast TDD using embedded DevChain (no Docker needed)
• IntegrationTests project for E2E testing against the running AppHost
• LoadGenerator with random mint/transfer/ETH send operations
• Code generation scripts (generate-csharp.ps1 / .sh) invoking Nethereum.Generator.Console
• AppHost configures Explorer ABI auto-discovery from contracts/out/ Foundry artifacts
• Local Explorer App.razor override to fix blazor.web.js compatibility with NuGet-packaged Razor components on .NET 10

Commits: f500fcc0, 818cc8af, 9c68e081, 4828ebda

Nethereum.Aspire.TemplatePack — DevChain Template Fixes

• Fixed project references from old NethereumDevChain_ prefixed names to clean Projects.DevChain, Projects.Indexer, Projects.Explorer
• Updated to async MapDevChainEndpointsAsync() matching library API changes
• Added local Explorer App.razor override for blazor.web.js .NET 10 compatibility
• Updated Aspire version to 13.1.1 in README examples
• Updated default Nethereum version to 6.0.4

Commits: 76c796ef, d348e405, 60e76cc3

Nethereum.Explorer — Runtime Bytecode ABI Matching

The Explorer now automatically discovers contract ABIs by matching on-chain runtime bytecode against locally loaded Foundry/Hardhat artifacts. Previously, FileSystemABIInfoStorage loaded artifacts but only matched by contract address (which required prior registration). Now the AbiStorageService falls back to bytecode-based matching:

1. Fetch on-chain bytecode via eth_getCode
2. Compare against all loaded Foundry artifacts (stripping metadata suffixes)
3. On match: bind the ABI to the contract address, persist to the database, and serve decoded function calls

This means: deploy a contract from the dApp WebApp or via forge script, navigate to its address in the Explorer, and the ABI is available immediately — no manual upload needed.

• Added FileSystemABIInfoStorage and IWeb3 dependencies to AbiStorageService
• New bytecode matching fallback in GetContractAbiAsync after address-based and external source lookups fail
• Registers matched contract address for future direct lookups via RegisterContractAddress
• Persists matched ABI to the Contracts database table

Commits: 6e1921f8
... (truncated)

6.0.0

Nethereum 6.0.0

Nethereum 6.0.0 is a major release introducing the CoreChain (full in-process Ethereum node), DevChain (development chain with SQLite persistence), AppChain (multi-node application chain stack), Account Abstraction (ERC-4337 bundler + ERC-7579 modular accounts), a Blazor Server blockchain Explorer, multi-provider blockchain storage (Postgres, SQL Server, SQLite), .NET Aspire orchestration, and significant EVM simulator improvements bringing it closer to full Ethereum specification compliance.

Full Changelog

Nethereum.CoreChain — In-Process Ethereum Node

New project providing a full in-process Ethereum execution layer node with JSON-RPC support, state management, block production, and transaction processing.

• Full JSON-RPC handler suite: eth_call, eth_estimateGas, eth_getBalance, eth_getCode, eth_getStorageAt, eth_sendRawTransaction, eth_getTransactionByHash, eth_getTransactionReceipt, eth_getBlockByHash, eth_getBlockByNumber, eth_getBlockReceipts, eth_getLogs, eth_newFilter, eth_getFilterChanges, eth_getFilterLogs, eth_feeHistory, eth_gasPrice, eth_createAccessList, eth_coinbase, eth_mining, eth_syncing, net_listening, net_peerCount, web3_sha3
• debug_traceTransaction and debug_traceCall with opcode and call tracers
• Historical state support with state diff tracking and pruning
• In-memory and persistent storage backends (via IBlockStore, ITransactionStore, IReceiptStore, ILogStore, IStateStore, IStateDiffStore, IFilterStore)
• Block producer with configurable block production options
• Transaction pool (TxPool) with gas price ordering
• Metrics instrumentation via System.Diagnostics.Metrics
• P2P interfaces for consensus and synchronisation
• WebSocket subscription support (eth_subscribe/eth_unsubscribe)
• State root calculation with Patricia Merkle Trie integration
• Consensus abstraction interfaces (pluggable PoA, Clique, etc.)

Commits: Nethereum/Nethereum@652b4b7, Nethereum/Nethereum@f6c0777, Nethereum/Nethereum@328672f, Nethereum/Nethereum@b040698

Nethereum.CoreChain.RocksDB — Persistent Storage

RocksDB-backed persistent storage for CoreChain including block, transaction, receipt, log, and state stores. Includes state diff store for historical state reconstruction, message result caching, and bloom filter-based log querying.

Commits: Nethereum/Nethereum@2dccead, Nethereum/Nethereum@2371cba

Nethereum.DevChain — Development Chain

Full-featured Ethereum development chain built on CoreChain, designed for local development and testing.

• SQLite persistent storage (default) — chain state survives restarts; in-memory mode also available
• Pre-funded dev accounts (10,000 ETH each)
• Auto-mine mode (block per transaction)
• EIP-1559 transaction support
• Thread-safe account impersonation
• evm_increaseTime and evm_setNextBlockTimestamp dev RPC methods
• Hosted service pattern for ASP.NET Core integration

Commits: Nethereum/Nethereum@652b4b7, Nethereum/Nethereum@3bc0939, Nethereum/Nethereum@90bce97

Nethereum.DevChain.Server — HTTP Server

ASP.NET Core HTTP server wrapper for DevChain with CORS, health checks, configurable chain ID, and dev account management. Provides the JSON-RPC POST endpoint compatible with MetaMask, Foundry, Hardhat, and any Ethereum tooling.

Commits: Nethereum/Nethereum@90bce97

... (truncated)

5.8.0

Nethereum 5.8.0 - 10 Year Anniversary Release

Celebrating 10 years of .NET Ethereum integration! (November 2015 - November 2025)

Nethereum was created to enable all .NET developers to build new applications and integrate existing ones with Ethereum.

From the beginning, the thought was simple: Ethereum would not succeed without developers. Not just blockchain specialists, but application developers of all kinds. If Ethereum was going to grow, every developer, regardless of skill set, needed to be able to build on top of it and integrate with it. The same ideas led to the creation of the VS Code Solidity extension… (obviously not just .NET. Java, PHP, Python, JavaScript, any IDE, any developer).

Helping .NET developers was not just about providing an API. Understanding Ethereum was (and still is) complex, so it meant providing support when needed… the blockchain space requires a completely different way of thinking about applications and integration. Now with LLMs this has simplified dramatically the entry point for everyone, and we have seen now there is no much need for community support. Hopefully I have been able to help you all these years. Support to me, it has also meant providing examples and integrations across the entire .NET ecosystem, from backend and enterprise systems to web, mobile, desktop, and gaming, so Ethereum could be part of real applications rather than something separate. And leveraging new innovations… I still think it’s pretty amazing that we can have a Blazor server-side application interacting with the MetaMask extension, a playground compiling and executing in the browser through WASM and interacting with Ethereum that way… seeing those complex games built with MUD, or having full wallets in Blazor and dApp browsers. There are also some projects that never came to an end like the SAP integration examples, or the commerce examples.

When designing Nethereum, I knew developers would need everything a blockchain node client provides, and more. Not just RPC calls, but cryptography, encoding, execution, verification, wallets, indexing, data processing, and application tooling. All of this needed to be available so developers could work at whatever level made sense for their use case, from low-level primitives to high-level abstractions. This will never be finished, as new changes continue to arrive in the EVM, storage, Merkle structures, verification, transaction types, and in .NET itself.

Another goal was that developers fully understand how Ethereum works, while also having simple ways to get started, such as code generation and front-end integration, without needing to learn everything at once. You may have noticed that I have always been obsessed with code generators ... although LLMs might do a lot of work now, the deterministic side is still very important (and those will always be there). We experimented with living documentation (workbooks) but eventually the playground was (I think) the better option. I thought also that gaming, hence my love for Unity will teach anyone what blockchain can achieve, in sometimes much more complex scenarios that any financial DeFi application, creating complete and complex worlds that can simulate rea life without exposure to its dangers, I am pretty glad that Nethereum has helped build some of these fully on chain games.

A longer-term goal was that, once the architecture was in place, any application could stand on its own: using Ethereum primitives directly, acting as a small light client if needed, remaining decentralised, while still integrating easily with the real protocols and smart contracts that make up the Ethereum ecosystem. In this latest release, we now have those verification pieces in place… let’s see how this grows in the future.

Finally another thought was the need to provide another entry point to common smart contracts, to have a real "protocol" or standard, all common languages should be able to interact with it, hence making ENS or smart contract wallets like Gnosis Safe a real protocol and standard, but not just that, but ensuring that we can provide a real Exit or alternative integration (or ui) that provides that real decentralisation.

In the end, Nethereum is many things for many people (and myself :)) depending on how you are going to use it and what you need from it.

Nethereum after 10 years has:

Protocol foundations
Native implementations of RLP, SSZ, Ethereum tries, hashing, Merkle structures, and reusable cryptographic primitives used across execution, indexing, and consensus-related workflows.

Cryptography & verification
Transaction and message signing, EIP-712 typed data, signature recovery, receipt/log/state proof verification, Merkle and Patricia proofs, and execution validation utilities — enabling verification rather than blind trust.

Light client & trust-minimised reads
A .NET light-client direction focused on block, receipt, and state verification, supporting verifiable reads, audit systems, embedded clients, and partial-trust environments.

Execution layer & EVM
A native .NET EVM with opcode-level execution, execution simulation for testing, indexing, validation, and education.

Contracts & ABI tooling
ABI encoding/decoding, typed contract services, event decoding, multicall support, deployment helpers, reflection-based APIs, and code generation that produces real, editable code.

Wallets & identity (full stack)
A complete wallet offering out of the box: mnemonics, HD wallets, keystores, vault-based accounts, view-only accounts, hardware wallet support, external wallets (MetaMask, WalletConnect, EIP-6963, Azure Key Vault, AWS), SIWE, multisig, and Gnosis Safe integration.

Smart-contract ecosystem integration
Established integration patterns for ENS, Uniswap, Safe, ERC standards, x402 and others.

MUD as a full backend
Complete support for MUD: typed Store access, systems, tables, indexing, code generation, and data-driven application backends — usable beyond games as a general on-chain backend model.

Indexing & deterministic data processing
Block, transaction, and log processors; reorg-safe pipelines; deterministic processing; change tracking; and support for multiple databases including PostgreSQL, SQL Server, Azure, and others — designed to integrate with existing systems.

UI & application frameworks
... (truncated)

Commits viewable in compare view.

Updated Nethereum.RPC from 5.0.0 to 6.1.0.

Release notes

Sourced from Nethereum.RPC's releases.

6.1.0

Nethereum 6.1.0

Nethereum 6.1.0 introduces a complete zero-knowledge proof infrastructure with native and browser-based Groth16 proof generation, the Privacy Pools SDK for private deposits and withdrawals with Association Set Provider support, new Merkle tree libraries (EIP-7864 Binary Trie, Sparse Merkle Trees with Poseidon hashing), SSZ model improvements, cross-platform BLS runtime updates, and demo applications showcasing the full ZK proof pipeline.

Full Changelog

Nethereum.ZkProofs — ZK Proof Abstractions

New provider-agnostic package defining the core interfaces and models for zero-knowledge proof generation in .NET. All proof providers (browser, native, HTTP) implement these abstractions, making them interchangeable.

• IZkProofProvider — central interface with FullProveAsync(ZkProofRequest, CancellationToken) and Scheme property
• ZkProofRequest — input model carrying circuit WASM, zkey, input JSON, witness bytes, and circuit graph data
• ZkProofResult — output model with ProofJson, PublicSignalsJson, and parsed BigInteger[] PublicSignals
• ZkProofScheme enum — Groth16, Plonk, Fflonk, Stark
• ICircuitArtifactSource — pluggable circuit artifact loading (WASM, zkey)
• ICircuitGraphSource — circuit graph data for native witness generation
• FileCircuitArtifactSource and EmbeddedCircuitArtifactSource — filesystem and in-memory artifact loading
• CircuitArtifactLocator — standard directory layout resolver for circuit artifacts
• HttpZkProofProvider — delegates proof generation to a remote HTTP prover endpoint
• Groth16ProofConverter — parse snarkjs JSON proofs and convert to Solidity-compatible format for on-chain verification

Commits: e28026f2

Nethereum.ZkProofsVerifier — Pure C# Groth16 Verification

New package providing Groth16 proof verification using BN128 elliptic curve pairing — entirely in managed C# with no native dependencies. Directly consumes snarkjs/Circom JSON output for one-liner verification.

• CircomGroth16Adapter.Verify(proofJson, vkJson, publicInputsJson) — high-level verification API
• Groth16Verifier — BN128 pairing check implementation using BouncyCastle
• Snarkjs JSON parsers for proofs, verification keys, and public signals
• Returns structured ZkVerificationResult with IsValid and Error properties

Commits: 22fe04a6, 6b3858e8

Nethereum.ZkProofs.Snarkjs — Node.js Proof Backend

New IZkProofProvider implementation that generates Groth16 proofs by invoking snarkjs via a Node.js child process. Suitable for server-side applications where Node.js is available.

Commits: 6d998f5b

Nethereum.ZkProofs.Snarkjs.Blazor — Browser-Based Proof Generation

New IZkProofProvider implementation for Blazor WebAssembly applications. Calls snarkjs via JavaScript interop, enabling client-side proof generation entirely in the browser — private inputs never leave the user's machine.

• SnarkjsBlazorProvider — implements IZkProofProvider and IAsyncDisposable
• Loads snarkjs via <script> tag (UMD bundle) for broad compatibility
• Sends circuit WASM and zkey as base64 to JavaScript, returns proof JSON
• Configurable snarkjs URL (self-hosted or CDN)

Commits: 074a8576, e2a6a738
... (truncated)

6.0.4

Nethereum 6.0.4

Nethereum 6.0.4 adds the new nethereum-dapp Aspire template for full-stack dApp development (Solidity + C# + Blazor + EIP-6963 wallet), fixes Explorer ABI auto-discovery from Foundry artifacts, resolves blazor.web.js compatibility with .NET 10 NuGet-packaged Razor components, improves EIP-6963 wallet CSS and interop, adds a parallel NuGet build script, and introduces GitHub Actions CI with prerelease publishing.

Full Changelog

Nethereum.Aspire.TemplatePack — New nethereum-dapp Template

New full-stack dApp template creating a complete development environment with 9 projects — Solidity contracts (Foundry), C# typed services (code generation), Blazor WebApp with EIP-6963 wallet integration, embedded TDD and E2E tests, and the full DevChain + Indexer + Explorer infrastructure, all orchestrated by .NET Aspire.

• WebApp with EIP-6963 wallet discovery, chain validation, and wallet_addEthereumChain switching
• Three UI states: not connected → wrong chain → correct chain (deploy/mint/transfer/balance)
• Light-themed CSS with card-based layout, form styling, and wallet CSS custom properties
• Foundry contracts project with starter ERC-20 (MyToken + mint), Forge tests, and deploy scripts
• ContractServices with pre-generated C# typed contract access from Solidity ABI
• Tests project with fast TDD using embedded DevChain (no Docker needed)
• IntegrationTests project for E2E testing against the running AppHost
• LoadGenerator with random mint/transfer/ETH send operations
• Code generation scripts (generate-csharp.ps1 / .sh) invoking Nethereum.Generator.Console
• AppHost configures Explorer ABI auto-discovery from contracts/out/ Foundry artifacts
• Local Explorer App.razor override to fix blazor.web.js compatibility with NuGet-packaged Razor components on .NET 10

Commits: f500fcc0, 818cc8af, 9c68e081, 4828ebda

Nethereum.Aspire.TemplatePack — DevChain Template Fixes

• Fixed project references from old NethereumDevChain_ prefixed names to clean Projects.DevChain, Projects.Indexer, Projects.Explorer
• Updated to async MapDevChainEndpointsAsync() matching library API changes
• Added local Explorer App.razor override for blazor.web.js .NET 10 compatibility
• Updated Aspire version to 13.1.1 in README examples
• Updated default Nethereum version to 6.0.4

Commits: 76c796ef, d348e405, 60e76cc3

Nethereum.Explorer — Runtime Bytecode ABI Matching

The Explorer now automatically discovers contract ABIs by matching on-chain runtime bytecode against locally loaded Foundry/Hardhat artifacts. Previously, FileSystemABIInfoStorage loaded artifacts but only matched by contract address (which required prior registration). Now the AbiStorageService falls back to bytecode-based matching:

1. Fetch on-chain bytecode via eth_getCode
2. Compare against all loaded Foundry artifacts (stripping metadata suffixes)
3. On match: bind the ABI to the contract address, persist to the database, and serve decoded function calls

This means: deploy a contract from the dApp WebApp or via forge script, navigate to its address in the Explorer, and the ABI is available immediately — no manual upload needed.

• Added FileSystemABIInfoStorage and IWeb3 dependencies to AbiStorageService
• New bytecode matching fallback in GetContractAbiAsync after address-based and external source lookups fail
• Registers matched contract address for future direct lookups via RegisterContractAddress
• Persists matched ABI to the Contracts database table

Commits: 6e1921f8
... (truncated)

6.0.0

Nethereum 6.0.0

Nethereum 6.0.0 is a major release introducing the CoreChain (full in-process Ethereum node), DevChain (development chain with SQLite persistence), AppChain (multi-node application chain stack), Account Abstraction (ERC-4337 bundler + ERC-7579 modular accounts), a Blazor Server blockchain Explorer, multi-provider blockchain storage (Postgres, SQL Server, SQLite), .NET Aspire orchestration, and significant EVM simulator improvements bringing it closer to full Ethereum specification compliance.

Full Changelog

Nethereum.CoreChain — In-Process Ethereum Node

New project providing a full in-process Ethereum execution layer node with JSON-RPC support, state management, block production, and transaction processing.

• Full JSON-RPC handler suite: eth_call, eth_estimateGas, eth_getBalance, eth_getCode, eth_getStorageAt, eth_sendRawTransaction, eth_getTransactionByHash, eth_getTransactionReceipt, eth_getBlockByHash, eth_getBlockByNumber, eth_getBlockReceipts, eth_getLogs, eth_newFilter, eth_getFilterChanges, eth_getFilterLogs, eth_feeHistory, eth_gasPrice, eth_createAccessList, eth_coinbase, eth_mining, eth_syncing, net_listening, net_peerCount, web3_sha3
• debug_traceTransaction and debug_traceCall with opcode and call tracers
• Historical state support with state diff tracking and pruning
• In-memory and persistent storage backends (via IBlockStore, ITransactionStore, IReceiptStore, ILogStore, IStateStore, IStateDiffStore, IFilterStore)
• Block producer with configurable block production options
• Transaction pool (TxPool) with gas price ordering
• Metrics instrumentation via System.Diagnostics.Metrics
• P2P interfaces for consensus and synchronisation
• WebSocket subscription support (eth_subscribe/eth_unsubscribe)
• State root calculation with Patricia Merkle Trie integration
• Consensus abstraction interfaces (pluggable PoA, Clique, etc.)

Commits: Nethereum/Nethereum@652b4b7, Nethereum/Nethereum@f6c0777, Nethereum/Nethereum@328672f, Nethereum/Nethereum@b040698

Nethereum.CoreChain.RocksDB — Persistent Storage

RocksDB-backed persistent storage for CoreChain including block, transaction, receipt, log, and state stores. Includes state diff store for historical state reconstruction, message result caching, and bloom filter-based log querying.

Commits: Nethereum/Nethereum@2dccead, Nethereum/Nethereum@2371cba

Nethereum.DevChain — Development Chain

Full-featured Ethereum development chain built on CoreChain, designed for local development and testing.

• SQLite persistent storage (default) — chain state survives restarts; in-memory mode also available
• Pre-funded dev accounts (10,000 ETH each)
• Auto-mine mode (block per transaction)
• EIP-1559 transaction support
• Thread-safe account impersonation
• evm_increaseTime and evm_setNextBlockTimestamp dev RPC methods
• Hosted service pattern for ASP.NET Core integration

Commits: Nethereum/Nethereum@652b4b7, Nethereum/Nethereum@3bc0939, Nethereum/Nethereum@90bce97

Nethereum.DevChain.Server — HTTP Server

ASP.NET Core HTTP server wrapper for DevChain with CORS, health checks, configurable chain ID, and dev account management. Provides the JSON-RPC POST endpoint compatible with MetaMask, Foundry, Hardhat, and any Ethereum tooling.

Commits: Nethereum/Nethereum@90bce97

... (truncated)

5.8.0

Nethereum 5.8.0 - 10 Year Anniversary Release

Celebrating 10 years of .NET Ethereum integration! (November 2015 - November 2025)

Nethereum was created to enable all .NET developers to build new applications and integrate existing ones with Ethereum.

From the beginning, the thought was simple: Ethereum would not succeed without developers. Not just blockchain specialists, but application developers of all kinds. If Ethereum was going to grow, every developer, regardless of skill set, needed to be able to build on top of it and integrate with it. The same ideas led to the creation of the VS Code Solidity extension… (obviously not just .NET. Java, PHP, Python, JavaScript, any IDE, any developer).

Helping .NET developers was not just about providing an API. Understanding Ethereum was (and still is) complex, so it meant providing support when needed… the blockchain space requires a completely different way of thinking about applications and integration. Now with LLMs this has simplified dramatically the entry point for everyone, and we have seen now there is no much need for community support. Hopefully I have been able to help you all these years. Support to me, it has also meant providing examples and integrations across the entire .NET ecosystem, from backend and enterprise systems to web, mobile, desktop, and gaming, so Ethereum could be part of real applications rather than something separate. And leveraging new innovations… I still think it’s pretty amazing that we can have a Blazor server-side application interacting with the MetaMask extension, a playground compiling and executing in the browser through WASM and interacting with Ethereum that way… seeing those complex games built with MUD, or having full wallets in Blazor and dApp browsers. There are also some projects that never came to an end like the SAP integration examples, or the commerce examples.

When designing Nethereum, I knew developers would need everything a blockchain node client provides, and more. Not just RPC calls, but cryptography, encoding, execution, verification, wallets, indexing, data processing, and application tooling. All of this needed to be available so developers could work at whatever level made sense for their use case, from low-level primitives to high-level abstractions. This will never be finished, as new changes continue to arrive in the EVM, storage, Merkle structures, verification, transaction types, and in .NET itself.

Another goal was that developers fully understand how Ethereum works, while also having simple ways to get started, such as code generation and front-end integration, without needing to learn everything at once. You may have noticed that I have always been obsessed with code generators ... although LLMs might do a lot of work now, the deterministic side is still very important (and those will always be there). We experimented with living documentation (workbooks) but eventually the playground was (I think) the better option. I thought also that gaming, hence my love for Unity will teach anyone what blockchain can achieve, in sometimes much more complex scenarios that any financial DeFi application, creating complete and complex worlds that can simulate rea life without exposure to its dangers, I am pretty glad that Nethereum has helped build some of these fully on chain games.

A longer-term goal was that, once the architecture was in place, any application could stand on its own: using Ethereum primitives directly, acting as a small light client if needed, remaining decentralised, while still integrating easily with the real protocols and smart contracts that make up the Ethereum ecosystem. In this latest release, we now have those verification pieces in place… let’s see how this grows in the future.

Finally another thought was the need to provide another entry point to common smart contracts, to have a real "protocol" or standard, all common languages should be able to interact with it, hence making ENS or smart contract wallets like Gnosis Safe a real protocol and standard, but not just that, but ensuring that we can provide a real Exit or alternative integration (or ui) that provides that real decentralisation.

In the end, Nethereum is many things for many people (and myself :)) depending on how you are going to use it and what you need from it.

Nethereum after 10 years has:

Protocol foundations
Native implementations of RLP, SSZ, Ethereum tries, hashing, Merkle structures, and reusable cryptographic primitives used across execution, indexing, and consensus-related workflows.

Cryptography & verification
Transaction and message signing, EIP-712 typed data, signature recovery, receipt/log/state proof verification, Merkle and Patricia proofs, and execution validation utilities — enabling verification rather than blind trust.

Light client & trust-minimised reads
A .NET light-client direction focused on block, receipt, and state verification, supporting verifiable reads, audit systems, embedded clients, and partial-trust environments.

Execution layer & EVM
A native .NET EVM with opcode-level execution, execution simulation for testing, indexing, validation, and education.

Contracts & ABI tooling
ABI encoding/decoding, typed contract services, event decoding, multicall support, deployment helpers, reflection-based APIs, and code generation that produces real, editable code.

Wallets & identity (full stack)
A complete wallet offering out of the box: mnemonics, HD wallets, keystores, vault-based accounts, view-only accounts, hardware wallet support, external wallets (MetaMask, WalletConnect, EIP-6963, Azure Key Vault, AWS), SIWE, multisig, and Gnosis Safe integration.

Smart-contract ecosystem integration
Established integration patterns for ENS, Uniswap, Safe, ERC standards, x402 and others.

MUD as a full backend
Complete support for MUD: typed Store access, systems, tables, indexing, code generation, and data-driven application backends — usable beyond games as a general on-chain backend model.

Indexing & deterministic data processing
Block, transaction, and log processors; reorg-safe pipelines; deterministic processing; change tracking; and support for multiple databases including PostgreSQL, SQL Server, Azure, and others — designed to integrate with existing systems.

UI & application frameworks
... (truncated)

Commits viewable in compare view.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore <dependency name> major version will close this group update PR and stop Dependabot creating any more for the specific dependency's major version (unless you unignore this specific dependency's major version or upgrade to it yourself)
• @dependabot ignore <dependency name> minor version will close this group update PR and stop Dependabot creating any more for the specific dependency's minor version (unless you unignore this specific dependency's minor version or upgrade to it yourself)
• @dependabot ignore <dependency name> will close this group update PR and stop Dependabot creating any more for the specific dependency (unless you unignore this specific dependency or upgrade to it yourself)
• @dependabot unignore <dependency name> will remove all of the ignore conditions of the specified dependency
• @dependabot unignore <dependency name> <ignore condition> will remove the ignore condition of the specified dependency and ignore conditions