The parts, and how they connect

Click a role to select it. You can pick more than one — a single machine happily runs storage and validation together. What each one asks of your computer is spelled out below, including the awkward part: several of them need an open port.

About that open port. A gateway and a probe both have to be reachable from the internet, which on a home connection usually means adding a port-forwarding rule on your router. If your provider uses carrier-grade NAT — common on mobile and some fibre plans — inbound connections are not possible at all and neither role will work, however good your connection is. Storage and validation have no such requirement: they reach the network over I2P and make only outbound connections.

What happens when you ask for a page

Five steps, of which only one involves trusting anybody. The gateway is carrying bytes it cannot alter without the reader noticing, which is what makes it safe to let a stranger do it.

What happens when the origin is down

Step 3 fails. Gateways already hold a signed, read-only snapshot of the site, so the answer is not an error page — it is the site, clearly labelled as a copy, with everything that writes turned off.

How a gateway is judged

A gateway that misbehaves has to be removed, and the power to remove one is the power to remove a competitor. So no single observer has it. A finding counts only when several independent ones agree — and independence is checked, not assumed, because signatures are cheap to manufacture and distinct operators are not.

Being honest about where this stands. Those thresholds are real and enforced, which means that today — with few independent operators — almost nothing reaches quorum. That is the correct behaviour and not a finished one: a rule that never fires is doing its job only until there are enough participants for it to matter. Running a probe is how that changes.

Why a stranger's machine can serve you safely

A gateway is transport, not authority. It never holds the network's signing key. Every page it serves carries a signature over the exact bytes, and your browser checks it without asking anyone's permission — so a gateway that alters a single byte is caught by the reader it tried to deceive, not by a moderator afterwards.

Lending your spare CPU — without lending your machine In development

Most volunteers have no usable GPU and four to sixteen idle cores, so compute here is CPU-first rather than GPU-first. That is not a consolation prize: two processors running the same code over the same input produce byte-identical output, so correctness can be checked by comparing hashes. Graphics cards do not offer that — different scheduling changes the order of additions, and the answers are all correct without being equal.

The hard problem is not speed. It is that running a stranger's program on your desktop is exactly the thing you should never do. The design assumes every submitted program is hostile and removes what malice needs, rather than trying to detect it:

How work turns into payment Design

Paying for each of these things on-chain does not work: a transaction fee dwarfs the value of serving one page. So work produces signed receipts instead, and receipts settle in bulk. The receipt part runs today — every rewarded action already carries provider and witness signatures. What follows is the design for settling them continuously rather than in epoch-sized batches.

Why an off-chain payment is still safe

The worry with paying outside a blockchain is obvious: if the payment is not recorded publicly, what stops the other side denying it? The answer is that a payment channel does not ask you to trust anyone. It gives you something you can take to the chain alone, at any time, whether or not the other side cooperates.

This is the design Bitcoin's Lightning Network proved at scale. Dendritic Network is not Lightning — Lightning is Bitcoin, and this settles on Ethereum — but the safety mechanism is the same one, and it is worth understanding because it is what your money actually rests on.

And the parts that are not magic

One channel with the network, not one per creator

The obvious way to do this is the wrong way: if every viewer had to open a payment channel with every streamer, storage node and gateway they ever touched, nobody would get past the first tip. Each channel costs a transaction to open and locks funds that then sit idle.

So a reader opens one channel — with the network — and tops it up like a prepaid card. Payments to everyone else are routed through it.

Who watches while you are asleep In development

A payment channel protects you by letting you post a newer signed state than the one a cheat submitted. That protection has a deadline. If someone closes your channel on a stale state at three in the morning and the challenge window expires before you wake up, the stale state becomes final and the difference is theirs.

So a watchtower holds your newest signed states and posts one if it ever sees an older one hit the chain. The important design decision is what it is not allowed to do.

It never holds a key that can move your money. Everything it stores is a state you already signed, and the only action it can take is handing one of those to the contract. A compromised watchtower can fail to defend you; it cannot rob you.

The waiting period is a measurement, not a guess

How long should the challenge window be? Too short and an honest person cannot react in time. Too long and everyone's money is slow to withdraw. The number is fixed permanently when the contract is deployed, so it was worked out by measuring every step of getting a newer state onto the chain, rather than by picking a round figure.

Each step has a generous budget, and each budget has to be backed by an actual measurement against real Ethereum before the contract can be deployed. Four are done. One is not, and the reason is worth being precise about: a reorganisation is a rare event, and watching for a long time without seeing one does not prove they are shallow. An absence of events cannot bound the size of one, so that budget stays unproven until a real reorganisation is observed and measured.

If your device dies In development

The signed states are what protect you, so losing them matters. Your latest states are backed up encrypted, split into pieces, and spread across the same distributed storage that holds the site's content — so recovering them does not depend on any one machine still being alive, including ours.

How we know the blockchain is telling the truth In development

Almost every application that talks to Ethereum asks a company's server what the chain says and believes the answer. That is a strange thing to do with a system whose entire point is not needing to trust anyone — and here it would be worse than strange, because a watchtower shown a fabricated chain would sit quietly while your channel was stolen.

It is worth being blunt about why the obvious defences do not work. Since Ethereum stopped using proof-of-work, fabricating a convincing chain of block headers costs nothing. An attacker who controls the server you ask can invent blocks that link together perfectly, contain any balances they like, and produce proofs that verify correctly against their own invented state. Checking that the blocks fit together proves nothing at all.

So the node checks the validator signatures itself. It starts from a reference point obtained from three unrelated organisations who must agree exactly, then follows Ethereum's own signature chain forward from there. The server we read blocks from is never allowed to supply that starting point, because using a provider to vouch for itself is not a check.

Giving an award without a transaction fee Design

Awards are the visible face of all of this. Sending one on-chain means paying a transaction fee that can exceed the award itself, which is why small tips do not work on most chains. Over a channel an award is a signed message: instant, free, and settled later in bulk with everything else.

One deliberate constraint shapes the design: clicking the award button does not decide that you paid. The click starts a payment; the payment completes only when both sides have signed a new channel state. If anything fails in between, the award does not silently exist. The awards you see and the money that moved are kept as separate machinery precisely so that a bug in one cannot invent the other.

Splitting one payment across several routes Not enabled

A larger payment can be cut into pieces that travel different routes and reassemble at the recipient. It helps when no single route has enough capacity, and it means no single intermediary sees the whole amount.

The planning half of this is built — fragments are sized unevenly on purpose, since three identical thirds arriving together reassemble on sight, and the routes chosen must share no operator, because splitting across two paths run by the same party gives that party two views and a partial sum rather than any privacy at all.

It is switched off, and it should be. What is missing is the half that coordinates the pieces once they are in flight: what happens when two of three arrive, how partial refunds reconcile, how a payment resumes if your machine restarts midway. Until that exists, splitting a payment would place real locks on real channels with no coordinated way to settle or unwind them — worse than not splitting. The security properties it must satisfy have been written down first, and the gaps are recorded as gaps rather than quietly designed around.

Pooled tipping — many people, one recipient Design

Splitting, above, takes one person's payment down several routes. Pooled tipping is the opposite direction: many independent people contributing toward one recipient, aggregated so a streamer draws down a single total rather than settling hundreds of separate tips.

The line this design will not cross is the obvious shortcut: a pool must never become a database that records Alice owes 1, Bob owes 5 and then promises to pay the streamer. That is a custodian with extra steps, and it would put every contributor's money behind one operator's honesty and solvency. Every contribution stays backed by cryptographic authorisation from the person who made it, so the pool is adding up things that are already true rather than asserting new ones.

This is a design, not a running feature. It is scheduled after the economic testing phase, and the questions that decide whether it can be built non-custodially — how a contribution is bound to its contributor, recipient, pool and amount at once — are still open questions rather than settled answers. They are written down as questions on purpose: guessing at them is precisely how a pool turns into the trusted database above.

What happens if the domain or the server is taken

An outage is the easy case — gateways serve their snapshot and the site stays readable. The hard cases are a seized domain and a dead server, because both break the thing everything else is looked up through. Neither is hypothetical, and the network is built so that neither ends it.

What none of this fixes. One wallet signs those directives, so whoever holds it can move the network. The delay, the freeze and the forward-only numbering narrow that window; they do not close it. The real answer is a second independent signer, and that needs a second operator to exist — which is one more reason to run something here.

Build your configuration

Everything below goes into a config.json packaged beside the program. Nothing here is permanent — every value can be edited afterwards, and the node has a management page for exactly that.

Download

The program is identical for everyone on a platform. Only the configuration differs, which is why the hash below is of the binary — a hash of your personal archive would match nobody else's and could not be checked against anything.

After it is running

Run it — one line

This fetches the installer, picks the right binary for the machine you run it on, writes a config.json for the roles you selected on the diagram, and starts the node. It changes as you change your selection. It is an ordinary shell script and you are welcome to read it first — open it in a browser before piping it into a shell.

curl -fsSL https://dendritic.network/install.sh | sh