When EasyLayer makes sense
Use EasyLayer when you need your own blockchain state, not another full dataset
EasyLayer helps you run a focused state service: track the contracts, wallets, events, or UTXOs that matter to your product, persist the state changes, and expose them through transports your application can use.
Custom state is the product
Your application needs a state model you control: a contract monitor, wallet activity feed, balance tracker, UTXO view, or protocol-specific state.
You do not want to store everything
If one contract or wallet set matters, your app should not need to archive and query unrelated chain data just to answer product-specific questions.
The state must integrate anywhere
Use transports for backend services, WebSocket clients, Node IPC, Electron desktop apps, or browser/shared worker environments.
You want replayable state changes
EventStore gives the model an ordered history so the service can support recovery, historical reads, and reorg-aware workflows.
Good fit
Smart-contract or protocol monitoring
You need to watch a narrow set of on-chain events and maintain your own business state instead of storing a full explorer-style dataset.
Desktop or browser-integrated apps
Your app needs blockchain state inside Electron, browser extensions, or frontend-adjacent runtime flows, not only a backend HTTP API.
Self-hosted indexing infrastructure
You want control over the node/provider, database, runtime, and schema, but you do not want to build EventStore, reorg handling, transports, and model wiring from zero.
Not the best first step
You only need one generic hosted lookup
A managed blockchain API can be faster if the product only needs a balance, transaction, or token lookup and does not need to own the state model.
You need a managed SaaS with SLA today
EasyLayer is currently best evaluated as self-hosted infrastructure and custom support, not as a finished managed cloud product.
Your required chain/runtime is not supported yet
Validate the package and transport support before committing. Unsupported networks should be treated as custom work or future roadmap, not current capability.
How to compare your options
| Option | Best when | What you give up | Storage/runtime shape |
|---|---|---|---|
| Hosted blockchain APIs | You need common data quickly. | Less control over schema, replay, runtime behavior, and long-term dependency. | Provider-owned infrastructure and generic datasets. |
| Build internally | Your team has time to own the full indexing stack. | You must implement persistence, reorg handling, transports, replay, tests, and ops. | Whatever your team designs and maintains. |
| Generic indexers | You want a broad query layer or ecosystem-specific indexing model. | May not match custom runtime, desktop/browser integration, or focused state ownership. | Often broader data first, product state second. |
| EasyLayer | You need focused custom state and self-hosted control. | You still operate the service and must validate the package fit for your workload. | Persist your model state/events; avoid storing unrelated chain data in the app DB. |