Why We Run Our Own Full Nodes on Five Chains (Instead of Renting Someone Else's)
Every payment platform promises fast detection and reliable settlement. Whether they can keep that promise depends on infrastructure most never mention: whose nodes are watching the chain. Why Finality runs its own on all five chains — the speed reason, the dependency reason, and the privacy reason.
The short answer: when a customer pays, something has to notice — and whose machine notices determines how fast your checkout confirms, what happens when a third-party API has a bad day, and who else gets to observe your payment traffic. Most payment platforms rent that layer from RPC providers and never mention it. Finality runs its own full nodes on all five chains it settles on. It's expensive, it's operationally unglamorous, and it's one of the least visible decisions we've made — which is exactly why it's worth explaining: sub-second detection, promises without asterisks, and payment data that never flows through a third party's logs.
The question behind the question
"Why not just use a node provider?" is really asking: what does a payment gateway actually do all day? Strip the dashboards away and the irreducible core is: watch every new block on every supported chain, the instant it exists, forever. Detection is the heartbeat — the moment the checkout flips to "paid", the input to settlement, the trigger for the webhook your store ships against.
Rent that heartbeat and three things follow. None is a scandal; all are structural.
Reason one: the physics of "paid while they're still looking"
Our detection promise is concrete: a transfer is spotted the moment it enters a block — sub-second on Solana. That number isn't a tuning achievement; it's what happens when the machine doing the watching is yours, subscribed to the chain itself rather than polling someone's API through rate limits, shared queues, and an extra network hop.
Third-party RPC is built for a different customer: the median dapp, for whom 500ms extra latency is irrelevant. For a checkout, that latency is the product. A customer staring at "waiting for payment" doesn't experience your provider's p95 — they experience doubt, at the exact moment doubt costs conversion. Exchange-withdrawal payers, already off-app waiting for confirmation, feel it double.
Reason two: you can't outsource a promise
Every infrastructure provider has incidents — that's not a criticism, it's a fact of distributed systems. The question is what an incident means. If a rented RPC layer degrades, a payment platform built on it starts missing detections: checkouts hang, webhooks stall, merchants ship late or not at all. The platform's status page will say, honestly, "a vendor issue." The merchant's customer doesn't care whose logo was on the failing API.
We didn't want a sentence in our terms that says "detection may be delayed by third-party outages." The only way to delete the asterisk is to own the layer: our nodes, our redundancy, our pager going off at 3 a.m. Non-custodial settlement removed the platform as a custody risk; running our own nodes removes the vendor between us and the chain as a detection risk. Same instinct, different layer: a promise you can't enforce end-to-end is a hope with a logo.
Reason three: your payment traffic is nobody's telemetry
Here's the part rarely said out loud: routing detection through a third-party API means a third party observes the queries — which addresses you watch, when payments land, volume rhythms across your merchant base. Legitimate providers have policies about this; policies are exactly the kind of promise this company was founded to replace with structure.
Our nodes read the public chain like anyone can — but which addresses we're watching and why never leaves our infrastructure. For merchants whose revenue patterns are competitive information, that's not paranoia; it's hygiene.
The honest cost column
Running full nodes on five chains means disk that grows forever, chain upgrades that land on holidays, one chain's consensus quirks bleeding into your ops calendar, and redundancy because single nodes fail. It is real money and real engineering time that a rented API would make somebody else's problem.
We pay it because of what it buys beyond the three reasons above: operational intimacy with the rails we settle on. Running Solana and four EVM chains at full-node depth means we feel fee markets shift, see confirmation behavior change, and notice anomalies as operators — not as readers of a vendor's postmortem. That intimacy is also becoming content: the per-chain cost and speed numbers we publish come from our own machines, measured, not quoted — a living dataset from infrastructure we operate is on its way.
The pattern, again
Regular readers will recognize the shape: settlement rules welded into addresses instead of promised by policy; commissions that can't be withheld instead of paid monthly; rent deposits refunded because ownership doesn't scale with amount. Owning our nodes is the same decision wearing infrastructure clothes: wherever a promise matters, replace "trust us" with "we removed the party you'd have to trust." Sometimes that party is us. Sometimes it's our would-be vendor.
FAQ
Does "your own nodes" mean you can see more than anyone else?
No — full nodes read the same public chain anyone can. What changes is speed (no intermediary), reliability (no vendor dependency), and privacy (our queries stay ours).
What happens if one of your nodes fails?
Redundancy is the boring answer: multiple nodes per chain, because hardware fails and chains hiccup. The design goal is that merchants never learn about our infrastructure days from a missed payment.
Is this why detection is sub-second on Solana?
It's the precondition. Sub-second detection requires being subscribed to block production directly; polling a shared API gets you "fast, usually" — a phrase that has no place in a checkout.
Will you publish data from these nodes?
Yes — measured per-chain payment costs and confirmation behavior, as a living page updated from production infrastructure. Independent numbers, not vendor quotes — the fee dataset and the speed dataset are that promise, kept.
What is a full node, for a non-engineer?
A machine holding its own complete copy of the chain, hearing every new block firsthand — versus renting glimpses of someone else's copy through an API. Owning the copy is the difference between watching the ledger and being told about it.
Why not just use a commercial RPC provider like everyone else?
For most apps, providers are the right call. Payments are the exception: detection is the product — an outage at a vendor becomes missed payments at your checkout, and "our provider was down" is not a sentence a merchant should ever hear.
Does running nodes make payments faster for my customers?
It makes detection faster — the checkout flips to paid the moment the chain says so, sub-second on Solana. The chain's own speed is the ceiling; owned infrastructure is how you actually reach it.
Which chains do you run nodes for?
All five we settle on — Solana, Ethereum, Base, BNB Chain, Robinhood Chain. The acceptance list and the infrastructure list are the same list, by policy; we don't publish measurements for rails we don't run.
How does node ownership affect customer privacy?
Query patterns are business intelligence: which addresses you watch says who your customers are. On owned nodes, those queries never leave the building — a privacy property no vendor contract quite replaces.
Is this why exchange-withdrawal payments work reliably?
It's a precondition — dedicated-address detection means watching for transfers that can arrive minutes late from an exchange's queue, and catching every one. Reliability there is an infrastructure property wearing a feature's name.
What does this mean for merchants comparing gateways?
Add one due-diligence question: whose nodes fire your webhooks? A gateway on third-party RPCs inherits their availability — and so do you. Structural answers beat SLA pages.
Do I need to run my own node as a merchant?
No — that's the division of labor: infrastructure is the gateway's job, your wallet is yours. You inherit the reliability without the machine-room.
Isn't running nodes expensive? Who pays for it?
It's real cost, absorbed in the flat 1% — deliberately: infrastructure baked into the fee beats infrastructure as a surcharge, and the alternative (renting detection) just moves the cost somewhere less honest.
Infrastructure is the part of a payments company you're supposed to never think about — and the part that decides whether everything else was true. Run a sandbox payment and watch the detection timestamp: that speed is a machine we own, keeping a promise we didn't outsource.