Hyperledger Fabric Now Supports Native Solidity Smart Contracts via fabric-x-evm
ledger has published fabric-x-evm on GitHub — an EVM execution layer embedded inside Hyperledger Fabric.
Caleb North·updated August 28, 2026

The gateway speaks standard Ethereum JSON-RPC. Solidity contracts deploy unchanged. Hardhat, Foundry, and MetaMask point at it without modification. Chain ID 4011. The EVM runs; Fabric still owns consensus, ordering, and access control.
Runtime structure
The architecture is layered, not replaced. JSON-RPC requests hit a gateway process. The gateway builds read/write sets from EVM transactions. Those sets commit through Fabric's existing pipeline — committer nodes, application namespace, deterministic ordering.
Result: EVM semantics for contract authors. Fabric guarantees for operators. The EVM does not see the network topology. Fabric does not see the EVM execution path beyond the read/write set interface.
Access control is Fabric's. Private data collections, channel isolation, and identity-based permissions apply before transactions reach the EVM. This is not a public chain with permissioning added. It is a permissioned chain with EVM bytecode execution grafted onto it.
Local development uses the samples repository. It ships a complete Fabric-X network, a block explorer, and a token deploy-and-transfer demo. No source build required.
For development against locally built code, the requirements are Go and Docker or Podman. The network comes up via make targets. The sample configuration lives in integration/, so commands run from that directory. The gateway serves JSON-RPC at localhost.
Rootless Podman is supported. Pass DOCKER=podman COMPOSE="podman compose" to the relevant targets. Relevant where the Docker daemon is restricted or unavailable.
Configuration is YAML, passed with -c. Full annotated example at integration/fabx.yaml. Any field is overridable at runtime through environment variables: GATEWAY_<SECTION>_<FIELD>, uppercased, with dots and hyphens replaced by underscores. The pattern fits containerized deployment without config file mutations.
Compatibility surface
The project runs the Ethereum conformance suite — make eth-tests, TestEthereumTests — against ethereum/execution-specs state-test fixtures at Osaka+. Fixtures download on demand and verify against checksums into a gitignored testdata/execution-specs-tests/ directory. Coverage of this suite is the real measure of EVM parity, more than the headline feature list.
Gas and fee fields are stubbed. Code that reads gasPrice, maxFeePerGas, or baseFee will receive Fabric-side values, not Ethereum mainnet semantics. Contracts with hardcoded gas margins need review before deployment. The project documentation flags this explicitly as a divergence from public chains.
The integration tests come in two flavors. The first exercises read/write set construction without requiring a Fabric network. The second spins up a Fabric-X testcontainer, creates the namespace, and validates the full path. Both should pass before any production deployment.
What to verify before adoption
State machine behavior. The EVM executes deterministically. Fabric's ordering is deterministic. The composition should preserve this. Test it.
Permission mapping. Which Fabric identities map to which EVM addresses. How private data collections translate into EVM-visible state. The documentation flags access control as Fabric-native, not EVM-native.
Fee semantics. Since gas fields are stubbed, the standard EVM fee market does not apply. Ordering follows Fabric's model, not gas-price auction.
License terms. The repository splits licensing by component. Review per-component before enterprise deployment.
Treat this as a new execution environment. EVM-compatible at the contract interface. Permissioned at the trust boundary. Not a public testnet substitute.