Millisatoshi (msat)

What Is a Millisatoshi?

A millisatoshi (abbreviated msat) is one-thousandth of a satoshi, the smallest unit of account used in the Lightning Network. While a satoshi (sat) is the smallest indivisible unit on the Bitcoin base layer (1 BTC = 100,000,000 sats), the Lightning Network extends precision by three additional decimal places. This means 1 satoshi = 1,000 millisatoshis, and 1 BTC = 100,000,000,000 msat.

The BOLT specification (Lightning's protocol standard) defines the millisatoshi in BOLT #0 as "a millisatoshi, often used as a field name." Every HTLC routed through the network is denominated in millisatoshis, making msat the fundamental atomic unit for all Lightning accounting. Without this sub-satoshi granularity, the economics of payment routing on small transactions would break down entirely.

How It Works

All Lightning Network operations use millisatoshis internally. When a sender creates a payment, the amount is specified in msat. When a routing node calculates its fee, the arithmetic happens in msat. When a channel tracks its balance, both sides are recorded in msat. This consistency avoids rounding errors that would accumulate across multi-hop routes.

Unit Conversions

Encoding in BOLT 11 Invoices

BOLT 11 invoices encode payment amounts in the human-readable part using Bitcoin as the base unit with multiplier suffixes. The four multipliers map to progressively smaller denominations:

The pico multiplier (p) has a special constraint: the last decimal digit of the amount must be zero. Since 1 pico-BTC equals 0.1 msat, this rule ensures the encoded amount always resolves to a whole number of millisatoshis. An invoice like lnbc10p (1 msat equivalent would be 0.1 msat, which is not whole) is invalid, while lnbc100p (10 pico-BTC = 1 msat) is valid.

BOLT 12 offers simplify this by specifying amounts directly in millisatoshis rather than using multiplier encoding, removing the need for suffix arithmetic entirely.

Routing Fee Calculations

The reason millisatoshis exist comes down to routing fee math. Each routing node advertises two fee parameters in its channel_update message (defined in BOLT #7):

• fee_base_msat: a flat fee in millisatoshis charged per forwarded HTLC, regardless of amount
• fee_proportional_millionths: a proportional fee expressed in parts per million (ppm) of the forwarded amount

The fee formula per hop is:

fee = fee_base_msat + (amount_msat * fee_proportional_millionths / 1,000,000)

Consider forwarding a 100-satoshi payment (100,000 msat) through a node with a base fee of 1,000 msat and a proportional rate of 1 ppm:

fee = 1,000 + (100,000 * 1 / 1,000,000)
fee = 1,000 + 0.1
fee = 1,000.1 msat

That 0.1 msat proportional component would round to zero without sub-satoshi precision. Across thousands of forwarded payments, these fractional fees accumulate into meaningful revenue for routing nodes. Without millisatoshis, operators forwarding small payments would earn nothing from proportional fees, making small-payment routing economically unviable.

On-Chain Settlement and Rounding

Bitcoin's UTXO model cannot represent fractional satoshis. When a Lightning channel closes and the commitment transaction is broadcast on-chain, BOLT #3 requires all output amounts to be "rounded down to whole satoshis." The sub-satoshi remainder is absorbed into the transaction fee paid to the miner.

For example, if a party's channel balance is 5,002,345 msat (5,002.345 sats), the on-chain output would be 5,002 satoshis. The remaining 345 msat (worth a fraction of a fraction of a cent) becomes part of the miner fee. This rounding is inconsequential in practice but represents a fundamental boundary: millisatoshis are a Lightning-only abstraction that cannot cross into the base layer.

Implementation Across Lightning Nodes

All major Lightning implementations use millisatoshis as their internal unit of account:

In LND, for instance, converting between units is straightforward:

// LND's MilliSatoshi type (lnwire/msat.go)
type MilliSatoshi uint64

// Convert satoshis to millisatoshis
func NewMSatFromSatoshis(sat btcutil.Amount) MilliSatoshi {
    return MilliSatoshi(uint64(sat) * 1000)
}

// Convert millisatoshis to satoshis (truncates)
func (m MilliSatoshi) ToSatoshis() btcutil.Amount {
    return btcutil.Amount(uint64(m) / 1000)
}

Use Cases

Streaming Payments

Streaming payments send continuous micro-flows of value in real time. Podcasting 2.0 and Value4Value protocols let listeners stream satoshis per minute of content consumed. With millisatoshi precision, a per-second payment rate can be expressed meaningfully: 1 sat per minute is roughly 16.7 msat per second. Without msat granularity, per-second streaming would require rounding to whole satoshis, either overpaying drastically or making the smallest possible stream 60x larger than intended.

Machine-to-Machine Transactions

IoT devices and autonomous agents can trade computing resources, bandwidth, storage, or API calls through continuous micropayments. A sensor network paying per data packet, an AI agent purchasing inference tokens, or a mesh network node selling bandwidth: all benefit from sub-satoshi precision that keeps individual transaction amounts economically meaningful. As agentic payment infrastructure matures, millisatoshi-denominated Lightning payments provide the granularity these systems require.

Pay-Per-Use API Metering

API providers can meter usage at sub-satoshi granularity, charging per request rather than requiring prepaid credits or monthly subscriptions. At current Bitcoin prices, a single millisatoshi is worth a tiny fraction of a cent, enabling pricing models where individual API calls cost less than a satoshi but aggregate into fair compensation over thousands of requests.

Multi-Path Payment Splitting

When a payment is split across multiple routes via multi-path payments, millisatoshi precision ensures amounts divide cleanly. A 1,001 msat payment can be split into 500 msat and 501 msat across two paths without losing value to rounding. This matters for pathfinding algorithms that need to balance channel utilization across routes.

Why It Matters

Millisatoshis are not just a technical curiosity: they are what make Lightning's fee market functional at small payment sizes. Traditional payment networks charge minimum fees (often $0.30 or more) that make micropayments impossible. Lightning breaks through this floor by expressing fees in millisatoshis, allowing routing costs that scale proportionally down to fractions of a cent.

This precision is also what enables Bitcoin micropayment use cases that were previously impractical: paying a fraction of a cent to read an article, tipping a social media post, or compensating a routing node for forwarding a tiny payment. Layer 2 protocols like Spark and Lightning inherit this sub-satoshi accounting, ensuring that even the smallest value transfers remain economically coherent from sender to recipient.

Risks and Considerations

Rounding Loss on Settlement

When channels close, sub-satoshi balances are lost to rounding. For individual users, this is negligible: the maximum loss per channel close is 999 msat (less than one satoshi). However, for high-volume routing nodes processing thousands of channel closures, these rounding losses can accumulate. The protocol accepts this tradeoff because the on-chain cost of representing sub-satoshi values would far exceed the value lost.

No On-Chain Representation

Millisatoshis exist only within Lightning (and other off-chain protocols). They cannot be sent on-chain, stored in a UTXO, or represented in a Bitcoin Script. This means that any system bridging between on-chain and off-chain must handle the precision boundary carefully, particularly submarine swaps and splicing operations.

Integer Overflow in Large Amounts

Since millisatoshis multiply the satoshi value by 1,000, the maximum representable amount in a 64-bit unsigned integer is approximately 18.4 quintillion msat (about 184 billion BTC). This exceeds Bitcoin's 21 million BTC cap by orders of magnitude, so overflow is not a practical concern for honest implementations. However, implementations must still validate that msat amounts do not exceed the total Bitcoin supply to prevent manipulation.

Precision Confusion

Developers new to Lightning sometimes confuse satoshis and millisatoshis, leading to bugs where amounts are 1,000x too large or too small. The varied encoding in BOLT 11 invoices (with milli, micro, nano, and pico multipliers all relative to BTC rather than sats) adds further opportunity for mistakes. Careful unit testing and use of strongly typed msat values (as most implementations provide) help prevent these errors.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.