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, Lightning is still relatively underground. 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) but they're fully fledged nodes.
Nodes are downloadable & portable. They can be migrated to fully self-hosted and open source hardware (designed & sold by Valera), without any lost features that the node's owner would notice. The hardware will be a more powerful version of our live signer hardware.
Any "always-on" features are handled by the runtime, mostly networking.
Keys are remotely held on remote hardware signers. Hardware-enforced, user-owned security keeps software in check.
The 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. Ironically the best UXs for LN are the fiat-based apps, like Cash App. We're reducing fees by an order of magnitude, and improving UX from sub-par to the best finance experience you'll ever have the pleasure of using (and we'll have creating).

Indra's production goal is to sustain up to 480,000 LN nodes per server over 10 clearnet IPs. 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 at 0.1% from a custom engineered LSP network to both consumers and merchants alike. We'll also act as a trustless exchange between assets, fees on which will also be 0.1%.

For a fresh take, we'll have transparent financials too. From investments to every sat of revenue we spend. Profits will be used to reinvest in the ecosystem, ourselves and support the less developed communities, bringing all 8 billion around the world onto the same, fair financial standard. Giving equal financial opportunity to absolutely everyone is our goal.

A fun fee comparison

Let's make a £1.90 payment for a coffee. You can see how this works on a more technical in the next section.

Fiat: 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 a £1.90 coffee. 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 hibernated 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 actually there.

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, guarding them from unwanted state broadcasts.

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 live signers: tiny (<$5-10) embedded devices that users plugin at their home (multi-user supported). Sharing is caring, so communities that don't have internet connectivity in each home can share a ring of live signers that look after the community's wealth.

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 everything that's going on (similar to VLS). 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.
1. The node likely only has a single channel with our LSP, so the payment will first head to the LSP router in the local datacenter
2. Assuming the shop is also on our LSP but on a different node, the local router will forward the payment over a virtual channel (i.e an infinitely sized channel that doesn't actually exist with funds in it) to the shop's router.
3. If the shop doesn't have enough inbound liquidity, our LSP will splice open its channel in real-time with the shop's node, removing the 0.1% fee. This channel update is broadcast onchain and will be able to continue to make payments while the update is confirming onchain.
Payment terminal gives the 👍 acknowledgment to the user

Security

There's a whole lot that goes into securing absolutely everything, using end-to-end encryption wherever possible.

I won't go into the full details of security in this article, but I thought it would be fun to mention I also built a custom encryption framework called xc220b3 for securing data, in-transit and on-disk.

It utilises XChaCha20 for the stream cipher and BLAKE3 for the MAC (message authentication code).

What's fun about this setup is that the MAC is calculated (with B3) from the plaintext and symmetric (32-byte) key. Instead of using a 16 byte MAC like Poly1305 does, we grow the MAC to 24 bytes so we can also use it as a deterministic nonce for XCC20 instead of relying on a stateful counter (ChaCha20) or secure random value (XChaCha20-Poly1305). Since it's deterministic, the risk of a collision is identical to if it was a random value.

It's fully open sourced here!

Thanks for taking the time to read this story! Enjoy your day 😄