A buyer prepays a budget of bytes that lasts until a deadline, and picks a reserved speed. Every second, the node takes from the budget whichever is larger: what the buyer actually moved, or its reserved speed. That single rule gives "time at a speed", "pay for what you use", and anything in between.
The buyer is carried at least at its reserved speed, and faster only if the provider lets it burst, which is the provider's own setting, not part of the protocol. At zero budget, or at the deadline, the buyer is closed and anything left over expires.
Reserve the speed you want. Idle seconds cost the same as busy ones, because the reserved speed is always the larger number. This is how the LAN portal sells Wi-Fi today.
Reserve nothing. Only the bytes you move are taken, so an idle hour costs nothing. What's left at the deadline expires.
Reserve a small guaranteed speed, and burst faster when the provider has room to give. Quiet time costs the reserved speed; bursts cost the bytes they move.
Under the one rule there is one TopUp message, with one new field, reserved_rate. Each update raises a channel's running total; the grant is how much the totals went up, and it is added to the budget. The deadline becomes the later of the old one and now + window_ms. The node answers each TopUp; the buyer's three ways of buying differ only in the numbers it sends and how often.
A buyer renews a little before its deadline so it never goes dark. Before, a new grant replaced the old one, so the unused end of a "time at a speed" grant was thrown away at every renewal. Now it simply stays in the budget and drains next.
The 250 ms not yet drained at each renewal was forfeited: 2.5% of every 10 s grant.
The leftover carries into the next stretch. The node was still paid for every second of reserved speed.
| Before | Now | |
|---|---|---|
| How the budget shrinks | Two modes: a new grant replaced the old one, or added to it | Always max(moved, reserved × time) |
| Idle time costs | Because unused grant was forfeited | Because the reserved speed is taken anyway |
| Speed | grant ÷ window, or a cap | The reserved speed; faster only if the provider lets payers burst (its own setting) |
| Early renewal | Forfeited the rest | Carries it over |
| Guaranteed + burst | Not possible | A reserved speed, plus whatever burst the provider allows |
| Uploads | A received multiplier, paid back between both sides | The provider's from_payer_weight, default 1 |
| What the node sets | A mode per instance | In its Offer: a window range, a smallest reserved speed (0 allows pay-per-use), a shortest gap between top-ups, the from-payer weight. Bursts in its own config. |
Every sale has one payer, whose budget is drawn, and one provider, which sells. What flows each way is named from those roles, so it stays clear whatever is sold, and even when two routers sell to each other: peering is just two sales, each with its own payer.
| What's sold | Units to the payer units_to_payer | Units from the payer units_from_payer |
|---|---|---|
| Wi-Fi for a phone | the phone's download | the phone's upload |
| A beer tap | beer poured | nothing, always 0 |
| A charger | energy into the car | nothing, or energy fed back (vehicle-to-grid) |
from_payer_weightThe provider puts the weight in its Offer: how much one unit from the payer costs, compared with one unit to the payer. 1 (the default) means both directions cost the same, 10 makes a unit from the payer ten times dearer, and 0 makes it free. It can't go below 0, so a provider can never pay a customer a bonus for sending. The result feeds straight into the one rule: max(moved, reserved × time).
| Decided by | What | Where |
|---|---|---|
| Provider | What its vouchers sell for, from_payer_weight, smallest reserved rate, window range, shortest gap between top-ups | The price where it sells vouchers; the rest in its Offer. All before any money moves, and fixed for the session. |
| Customer | How much to buy, its reserved rate (speed), its window | Each TopUp. It can refuse terms it doesn't like, e.g. never buy above a weight of 2. |
The customer's reserved rate is a choice of speed, not of price. The provider honours it (or refuses it as over capacity); it doesn't change what a unit costs.
Only the customer buys. One channel. The provider never buys anything back, so a phone needs no mint of its own. This is the common case, and it covers every consume-only use: beer, charging, Wi-Fi.
Each router sells to the other, each with its own Offer. That's two sales, and with weight 0 the payer in each pays only for what flows towards it. "Mutual" isn't a setting: it's just both sides selling.
received_multiplier made the relay buy the phone's upload, then charged it back with a surcharge, so the net was m − 1: 11 for "10×". Two payments, two channels, and a mint on the phone.
It's the provider's pricing, like the voucher price. A link's own shape is the usual guide: on a 100/10 Mbit/s line the payer's upload is a tenth as plentiful, so a weight of 10 charges each direction the same share of its capacity. A symmetric link (fibre, a mesh link) is 1. Something only one way, like beer, never uses it.