Ethereum Solution Catalogue BETA

Directory Guided RFI builder Who's on Ethereum

{{ themeLabel }} Add your company →

Enterprise Ethereum Alliance

Ethereum and Web3 vendors with institutional track records, curated by the EEA

Browse the catalogue directly, or switch to the guided RFI builder to structure a business outcome into capabilities, controls and infrastructure — and prepare a better RFI.

{{ membersMark }} EEA members only · {{ memberCount }} {{ shownCount }} of {{ totalCount }} vendors · {{ memberCount }} EEA members

EEA member

{{ v.meta }}

◆ {{ ct }}

No vendors match your search. Clear filters

Enterprise adoption

Who chose Ethereum — and what they built

Banks, brokerages, asset managers and payment networks are already in production on Ethereum. Follow the headlines, then find the vendors who can get you there.

{{ a.org }} Read coverage →

{{ a.org }} News →

Building something similar?

Browse the vendor directory or run guided procurement to shortlist partners for your use case.

Browse directory Guided procurement

Architecture layers

{{ r.num }} {{ r.label }} ✓

↺ Start over

01 · Business outcome

What are you trying to achieve?

Built for regulated institutions, enterprises and the public sector. Start from the business objective; the tool structures it into capabilities, services, controls and infrastructure, and prepares an RFI starting point. It does not complete procurement — qualification and due diligence remain yours.

SELECT ONE Selecting an objective takes you straight to step 02 · institutional context — your constraints shape everything downstream.

{{ g.label }}

{{ o.name }} ●

Taxonomy informed by the EthSystems institutional use-case map and the EEA vendor catalogue.

02 · Institutional context

Your operating constraints

Six quick gating questions. Institutional procurement is constrained before it is designed — these answers can eliminate whole architecture categories and become the recorded assumptions in your RFI export. Skip any you cannot answer yet; unanswered questions are recorded as open assumptions.

GATING QUESTIONS Your answers constrain the infrastructure options in step 06 and generate the due-diligence questions in the final export.

Jurisdiction(s)

Optional — recorded in your assumptions and used to frame licensing and data-residency due diligence.

03 · Business capabilities

Capabilities required for {{ outcomeName }}

These are the capabilities this objective typically requires, all pre-selected.

MULTI-SELECT Deselect anything you have in-house or out of scope — your selection determines the application services in step 04.

04 · Application services

Services that deliver those capabilities

Derived from your selected capabilities — each card shows which capability it comes from.

MULTI-SELECT Your selection determines the required controls in step 05 and the provider options in the final blueprint.

← {{ m.from }}

05 · Controls

Risk & compliance controls

Grouped in institutional risk language; the Ethereum-native standard that implements each control sits underneath as a mapping (EEA EthTrust and enterprise security baselines).

MULTI-SELECT Selected controls appear in your blueprint and inform the infrastructure recommendation in step 06.

{{ m.name }} — {{ m.desc }}

↳ {{ m.map }}

Identity and access management, third-party and outsourcing risk, auditability and record retention, and exit, portability and recovery apply to every architecture — they are carried into the due-diligence questions in your RFI export rather than selected here.

06 · Infrastructure & operating model

Where does it run — and who operates it?

This is an operating-model decision, not just a hosting decision: execution posture, existing network versus institution-controlled deployment, and self-operated versus outsourced infrastructure. The same use case can be implemented differently depending on privacy, control, performance, cost and compliance requirements — the recommendation below is derived from your selections and your institutional context.

SELECT ONE Selecting a network generates your preliminary blueprint. Primary/backup providers, geographic deployment and settlement dependencies stay open — they carry into the RFI as unresolved decisions.

BEST WHEN {{ m.when }}

ENABLES {{ m.enables }}

TRADE-OFFS {{ m.trade }}

{{ m.rec }}

Managed nodes & RPC SLA-backed access via providers such as Infura, Alchemy or QuickNode instead of self-hosted clients. Included by default — click to remove.

07 · Preliminary blueprint & RFI starting point

Preliminary solution blueprint

A structured starting point for your RFI — not a completed procurement. It records what you selected, what was assumed, what remains unresolved, and which providers to take into formal qualification.

{{ b.label }}

Why this architecture

Assumptions made

Unresolved architecture decisions

Potential providers for further qualification

No single vendor delivers this end-to-end, and these lists are not a shortlist, endorsement or statement of suitability. They represent steps 1–2 of a four-step ladder: 1 catalogue inclusion · 2 evidence of relevant experience · 3 formal institutional due diligence · 4 final procurement qualification — steps 3 and 4 remain with your institution. Providers appear where there is evidence of a production deployment, documented commercial service, enterprise customer engagement, or formal network/operator designation; inclusion does not imply support for every network or configuration. The same provider can appear under more than one component. Providers marked EEA appear in the member directory.

01 Network infrastructure

The base layer on which the solution operates. Procurement typically covers two separate capabilities: operating the selected network or rollup infrastructure, and providing reliable node and RPC access for applications.

Available providers depend on the underlying network, rollup stack, deployment model and required service level. Some vendors provide multi-network RPC access; others specialize in operating particular rollup frameworks or network implementations. A single provider may cover both capabilities.

Illustrative qualified providers — verify current network coverage during procurement.

                    ProviderManaged network / rollupNodes & RPCCoverage note
                  

EEA

also under {{ v.also }}

Institution-specific due-diligence questions

Generated from your context and selections — the starting question set for step 3 of the qualification ladder.

Export RFI starting point → Start a new blueprint