Web3
A chain is not a database, and nothing talks to it directly.
Between your application and the network sits a stack somebody has to operate: a wallet, an endpoint, a node, an index. Most of the hard problems in this work are consequences of that stack rather than of the contract underneath it. This page is about the layer, not about any product built on top of it.
The layer
What actually sits in between.
Named plainly, because a design that treats any of these as invisible plumbing tends to discover all of them at once, in production.
The application
Holds no keys and can prove nothing on its own. Everything it asserts about the chain it learned from something below it.
The wallet
Where the keys live and where a signature is authorised. Not yours to control, and not always present.
The endpoint
An HTTP service, operated by somebody, that your requests go through. It has limits, an owner and an outage history.
The node
What the endpoint is in front of. Its configuration decides which questions can be answered at all.
The index
A database you build and maintain, because the chain itself cannot answer the questions an application asks.
The chain
The only part that is actually shared, and the only part nobody operates on your behalf.
Every layer above the chain is somebody’s operational responsibility. Deciding whose, for each one, is most of the architecture.
Wallets and signing
The part you do not control.
A wallet is a dependency with its own release cycle, its own quirks and its own opinion about what it will sign. Treating it as a component you own is where a lot of this goes wrong.
Connection is not authentication
Knowing an address is not proof that anyone controls it. Proof requires a signature over something your server issued and will only accept once. A session built on a connected address alone can be claimed by anyone who knows the address.
A signature request has to be readable
Structured, typed data rather than an opaque blob, so what is being approved can be shown in terms a person can check. An approval nobody can read is an approval nobody has meaningfully given.
Custody is a decision with consequences
Whether keys sit with the holder, with a service, or split across a threshold changes recovery, compliance and what happens when someone leaves. It is decided before the interface work, not alongside it.
Account abstraction changes the assumptions
Where accounts are themselves contracts, a signature may be validated by arbitrary logic, fees may be paid by someone else, and several actions may be batched. Code that assumes every account is a simple keypair breaks against them.
Disconnection and network switching are normal
Wallets lock, change account, change network and disappear mid-flow. Each of those is an ordinary state to be handled rather than an error, and none of them should leave the application asserting something it can no longer verify.
Access
Somebody operates the endpoint you depend on.
Reaching a chain means sending requests to a service with an owner, a rate limit and an availability record. Architecture that assumes otherwise is architecture with a single point of failure it has not acknowledged.
More than one provider, with failover
Endpoints go down, fall behind, and silently return stale results. Multiple providers with health checks, and a policy for what happens when they disagree, turns an outage into a degradation.
Rate limits shape the design
Naive polling exhausts an allowance quickly and expensively. Batching, caching what cannot change, and subscribing rather than asking repeatedly are design decisions made early, not a rescue applied after the first bill.
Run your own, or be clear that you did not
Operating a node buys independence and costs real attention. Using a provider is a legitimate choice and a disclosed dependency. What does not work is depending on one without having decided to.
Archive access is a separate question
Historical state at an old block is not something every node can answer. Whether that capability is needed is settled while the data model is being designed, because retrofitting it means changing where the data comes from.
Keys never reach the browser
Anything holding a private key or a privileged provider credential runs on a server you control. A credential shipped to a client is public the moment it ships.
Indexing
You cannot query a chain.
A chain answers narrow questions about specific things. Applications ask broad ones — everything belonging to this person, ordered by time, filtered and paged. That gap is closed by a database you build and maintain.
The index is a real system
It has a schema, migrations, monitoring, a backfill process and an on-call story. Treating it as a cache is how it becomes the least reliable part of the stack.
Reorganisations are expected, not exceptional
Recent blocks can be replaced. An indexer has to be able to undo what it recorded and reprocess, which means recording enough to reverse a decision rather than only its result.
Backfill is not an afterthought
Rebuilding history from the beginning is something you will do — after a schema change, after a bug, after adding a field. How long that takes is a design constraint, and discovering it is measured in days is usually too late.
Events are an interface
What a contract emits determines what can ever be indexed cheaply. This is why indexing is discussed while the contract is being specified rather than after it is deployed, when the only fix is to reconstruct state the hard way.
The index can be wrong, so it is checked
Its numbers are reconciled against the chain on a schedule. An index that has quietly drifted is worse than no index, because everything above it now reports with confidence.
Transactions
Submitted, included, confirmed, final — four different things.
Collapsing these into a single success state is the most common error in this layer, and the one that produces support tickets about money.
Accepted is not included
A transaction sitting in the pending pool has been accepted for consideration and nothing more. It can be dropped, replaced or repriced, and until it is in a block nothing has happened.
Included is not final
How many blocks of depth count as settled depends on the network, and it is a stated policy rather than a feeling. Showing a result as done before that threshold is a promise the chain has not yet made.
Ordering is contested
What sits between submission and inclusion is a market. On a public chain, anything whose profitability depends on being ordered first should be designed on the assumption that someone is watching the pending pool.
Nonces are a shared resource
Two processes signing from one account will collide, and the second transaction waits behind the first forever. Sending from a shared account is serialised deliberately, or split across accounts on purpose.
Stuck transactions need an answer in advance
Underpriced transactions sit there. Whether the system replaces them, cancels them, or waits is decided while it is being built, because it will happen and someone will be asking.
Questions
The ones worth asking first.
Do we need to run our own nodes?
Often not at the start. A provider is a reasonable choice and much faster to stand up. The question worth answering early is what happens when that provider has an outage, changes its pricing, or rate-limits you at the worst moment — because the answer to that, not ideology, is what eventually justifies running your own.
Why is an indexer needed when the data is already on chain?
Because the chain can tell you the value of one thing at one moment, and an application needs to ask questions it has no way to answer: everything belonging to this person, sorted, filtered, paged, across a range of time. Reconstructing that from the chain on every request is slow, expensive and eventually rate-limited. The index is how that gap is closed.
Can users sign in with a wallet instead of a password?
Yes, and the important detail is that connecting a wallet proves nothing on its own. Authentication requires signing a message your server issued and will accept exactly once. Done properly it is a genuinely good sign-in mechanism; done as connection alone it is an account anyone can claim.
Which network should this be on?
Settled before this layer is built, on evidence about settlement guarantees, cost, tooling and where your counterparties already are. The blockchain page covers how that decision is made — including the case where the answer is that no chain is needed.
How do we handle a chain reorganisation?
By expecting it. Recent history can be replaced, so nothing irreversible happens until a stated depth is reached, and the indexer records enough to reverse what it wrote rather than only the result. A system that treats a reorganisation as an incident will treat an ordinary event as an emergency.
Who operates this after it launches?
Endpoints, indexers and any node are running systems with an on-call story, not artefacts handed over at the end. That is settled in the engagement rather than left implied, because an unindexed application looks broken to everyone using it while looking healthy on every dashboard.
Tell us what has to read from the chain.
Describe what your application needs to know, how fresh it has to be, and who is expected to sign for what. If a simpler arrangement answers it, that is what you will hear.
info@eorbitt.com · We reply within one business day.