Web3 development, and the part that is just distributed systems
Most web3 development is ordinary engineering, and the genuinely different parts are three constraints: state changes are slow and can fail after you thought they succeeded, everything you write is public and permanent, and there is no support line when a user loses access.
Web3 development gets discussed as though it were a separate discipline. Most of it is ordinary software engineering with three constraints that are unfamiliar rather than difficult.
Start from a working app
Aetherium
a multichain wallet dashboard showing your real on-chain balance across Ethereum and Base, with a live prices board.
Open the template
Constraint one: writes are slow and provisional
A transaction is submitted, not completed. It may confirm in seconds, sit pending for minutes, or fail after your interface has already congratulated the user. Anything that assumes a write succeeded because it did not error is wrong here, and the correct pattern is closer to a payment processor than a database.
Constraint two: your code and your mistakes are public
Deployed contract code is readable by everyone, and so is every transaction. There is no quietly patching a bug before anyone notices, and there is a standing audience with a financial reason to look. That changes how much care the money-touching parts deserve relative to everything else.
Constraint three: there is no password reset
A user who loses a key has lost the asset, and no amount of support can undo it. That single fact should shape every interface decision involving keys, and it is the reason a web page that shows someone a recovery phrase is a bad idea no matter how convenient it feels.
What is not actually different
The interface, the state management, the fetching, the caching, the deployment. That is ordinary front-end work and the ecosystem's tendency to treat it as exotic mostly adds friction. If a web3 tutorial makes routing sound novel, it is padding.
Where reading is easy and writing is hard
Reading chain state is a solved, cheap problem, and most useful applications are mostly reads. Our public endpoints are read-only and need no key for exactly that reason: it is the half that can be given away safely, and it is the half most projects need. Writing is where the care goes.
Live, right now, on this page
| Market | Price | Funding | 24h volume |
|---|---|---|---|
| BTC | $82,022.50 | 0.0013% | $196,426,400 |
| ETH | $2,416.75 | 0.0013% | $161,245,022 |
| SOL | $104.22 | 0.0013% | $36,550,973 |
| HYPE | $79.21 | 0.0013% | $6,527,522 |
Read from a live market as this page rendered, through a public endpoint that needs no key. Read at 2026-10-18 12:28 UTC; accurate as of that time and not afterwards.
Start from a working app
Open, change it, publish your own
Delta Neutral - Multi Dex
scans perpetual exchanges for funding rate mispricings, then opens and manages the positions.
Open the template
Working templates built around what this page covers. Open one, change it, and publish your own.
- Aetherium
a multichain wallet dashboard showing your real on-chain balance across Ethereum and Base, with a live prices board.
- Family Office
watches any set of public addresses and shows real on-chain balances, priced and rolled up per person, read-only with no custody.
- Delta Neutral - Multi Dex
scans perpetual exchanges for funding rate mispricings, then opens and manages the positions.
Common questions
Is web3 development a different discipline?
Mostly not. Interface, state management, fetching, caching and deployment are ordinary front-end work. What is genuinely different is three constraints: writes are slow and provisional, everything you write is public, and there is no password reset.
Why is a blockchain transaction not finished when it is sent?
A transaction is submitted, not completed. It may confirm in seconds, sit pending for minutes, or fail after your interface has already told the user it worked, so the right pattern is closer to a payment processor than a database.
Is reading blockchain data hard?
No. Reading chain state is a solved, cheap problem, and most useful applications are mostly reads. Writing is where the care goes.
See the number itself
Pages that read a live market and show what they read, updated while you look at them.
- Solana price today, on-chain data read without a key, the point this page makes.
- Ethereum price today, the same read on the other chain.
- Stablecoin lending rates, live, live protocol rates, read from the chains themselves.
- Apple stock price, live, through the tokenised share, a real world asset on chain, priced continuously, with the float that backs it.
- Amazon stock price, live, through the tokenised share, the same pattern on a second name, for comparing how thin these markets actually are.
- Uber stock, live, through the tokenised share, a real world asset settling on Solana, priced continuously with the float that backs it.
- Coinbase stock, live, through the tokenised share, the most self referential asset here: an exchange's share, as a token, on a chain.
- Eli Lilly stock, live, through the tokenised share, a real world asset with a published float, priced around the clock.
Related reading
All guides · Live market pages · Components · Make Mithril a preferred source in Google