Bringing adoption scale

Whilst Bitcoin is a household name we're still not quite at global adoption level yet. Even though many people have heard of Bitcoin, we still have smaller less well known areas; such as Lightning. Even if most people have heard of bitcoin, nearly no one knows what Lightning is!

This could even be a blessing in itself. Lightning ,as much as our devs like to think, doesn't yet have the projects and ecosystem to provide a UX that is superior, or equivalent to current fiat payment tech. Nearly everyone on Lightning is still working on new ideas. That's great by all means, but your WebLN app won't take off unless people have fast, low-cost and most importantly reliable payments.

Everything being built is awesome and I've shown many apps off to my trad-fi dad & college friends however I can't get them onboard sufficiently because of limitations and how early ideas are still developing. I believe it's very important that we concrete our network before global adoption.

This is why I'm building Valera and as a result, Indra too.

What's Indra?

It's a Lightning node runtime (built in Rust 🦀), meaning it manages the running of Lightning nodes. And it's very, very good at doing so. About 3900x better than other platforms, if we compare by cost efficiency.

TLDR:

Nodes are run (with a lot of help) as LDK nodes. They're expected to connect for the most part to LSP routers (not part of Indra itself but also utilising LDK).
Any "always-on" features are handled by the runtime, mostly networking.
Keys are remotely held on remote hardware signers. Hardware keeps the software in check.
Runtime is very strict about memory management and won't turn on a node unless it's absolutely needed. Memory is the primary constraint as these nodes aren't routers and won't be processing 24/7.

Some bits of a technical overview are available at the end of this story!

It's named after the king of the devas and Svarga in Hindu mythology, associated with the sky, lightning, weather, thunder, storms, rains, river flows, and war.

Goals & plans

Lightning isn't advertised to reduce merchant fees by 2-3x to 1%, or require your phone to always be on. We're reducing it by an order of magnitude, and improving UX from sub-par (ironically the best UXs for LN are the fiat apps, i.e. Cash App).

Indra's production goal is to sustain up to 480,000 LN nodes per server. This gives a cost basis of around $0.003 per month, down from $12-31 a month for traditional hosting. Around 4,000 to 10,000x cheaper.

This incredible cost efficiency means we can profitably lower fees by an order of magnitude compared to other services. Valera's business model is making money by selling inbound liquidity from a custom engineered LSP network to both consumers and merchants alike. For a fresh take, we'll have very transparent financials too, as profits should be used to support less developed communities and bringing all 8 billion around the world onto the same, fair financial standard.

Fiat competitors: 2.5% to 3.5% + 30p. LN/"blockchain"/bitcoin competitors: 1%. Valera: 0.1%

Amount business receives: £1.534 for fiat, £1.881 for competitors and £1.898 from us.

Here's a visualisation of our fees versus others on that £1.90 coffee from earlier. Indra is what makes this possible.

Indra is what makes global adoption not just possible, but economically inevitable.

Technical bits

This is quite in-depth, so feel free to gloss over it if you'd like! I wanted to provide some technical detail (even if it's very little) as to how we achieve our goals.

P2P proxying

When running a lot of nodes on a single host, it's suboptimal to keep them all running simultanously. Indra intelligently proxies traffic to the nodes so it understands when a node needs to be on. A node is granted a single port to use as a listening address.

When connections are made to the node's peers, Indra communicates with the remote signer during the ECDH secret exchange so it receives the symmetric key used to encrypt traffic with that peer. Indra then can use this key to decrypt traffic from the peer (usually Valera's LSP router) to decide whether or not to turn on the node for the request. If a node's not being used, it can be quickly shutdown to save system resources.

For example, LN peers "ping" their channel partners often to see if they're online or not. Indra replies to these pings with pongs, but doesn't turn on the user's node to do it, because it's a stateless message. This enables nodes running in Indra to appear as regular full LN nodes, even letting others on the network open direct channels to it, even if most of the time it's not turned on.

Shared resources

Channels need to be monitored on-chain for any malicious activity. Instead of making each node do this separately, the runtime "owns" channel monitors for all of its nodes.

Pathfinding and route calculations also use a shared single instance, which has advantages such as probabilistic learning from much more payment data than just one node. Indra can link up to other instances too, so they can learn the most efficient and reliable payment paths.

Remote signers

Indra is non-custodial. It cannot spend users funds. Instead, it maintains long-term, end-to-end encrypted two-way connections with hardware signers (details in the plan section...).

When it needs a signature, Indra gets it from the signer. But the signer doesn't give signatures out blindly, it understands the current channel states and how much it owns. It also has advanced user-configurable access controls, multi-signer support and various other things.

The architecture looks a bit like this

Indra <> live signers <> client {hard/soft}ware <> Indra

Let's say the user wants to buy a coffee with our payment ring (details TBA) which is a very basic client device. We exclude the LN setup for the terminal as that's not fully planned out.

The point-of-sale terminal exchanges encryption keys with the ring over NFC
then sends a payment offer to the ring.
The ring gets user confirmation, and then signs (with a cold stored key on the ring) it, providing onion routing info.
The terminal sends the signed payment offer to the node over onion routing
Indra wakes the user's node on inbound network traffic
The user's node decrypts the payment offer, parsing it and sending it back to the runtime asking for the necessary signatures from the user's live signer
The live signer works out which device (the payment ring) the request was signed by, and then also parses the payment offer. It checks whether or not it should provide a signature by checking its access controls (is the client device frozen, is it within its hourly spending limit, etc). Everything is okay, so it sends the required channel update signature back to Indra. The actual key for the LN channel updates is again, cold-stored on the live signer.
The node completes the channel updates and makes the payment.
Terminal gives the 👍 acknowledgment to the user