Payments can be fast - really fast – if you don't require consensus.
That's the idea behind pod: validators don't coordinate, don't share blocks, and don't agree on a global ledger. Each one independently signs transactions based on its local view of the world. This design makes pod extremely efficient. Transactions can be executed at network speed, without waiting for global agreement. But it also means that validators might not all see the same transactions at the same time. Their views can diverge; temporarily and by design.
Which brings us to a fundamental question: "How do we decide which transactions should be accepted, and what users should pay when validators don't coordinate?"
In other words: How do you build a fee market without consensus?
The Wrong Way to Set Fees
Let's try some straw-man approaches for gas pricing on pod and see where they fail.
Fixed Fee
Suppose pod charges a fixed fee: say, $1 per transaction.
Alice submits a transaction and pays the fee. But the system is overloaded, and not every transaction can be processed. Instead of a confirmation, she gets: "Pending…" For seconds. Maybe longer. Maybe forever. This is a bad user experience. Alice might never use pod again.
Now, assume the fee is raised to $10. Transactions get through, but Alice overpays, and the network leaves money and throughput on the table.
Static fees can't adapt to load.
First-price Auction
Let's try a first-price auction on pod where users specify how much they're willing to pay, and validators prioritize transactions with higher fees. Remember, without blocks, consensus, or cross-validator communication, each validator must independently determine whether Alice's proposed fee is "enough."
Validators could run real-time online algorithms to maintain a moving fee threshold based on the highest recent bids, accepting only transactions whose fees exceed that threshold. However, because they observe different transactions and experience varying network delays, they'll each compute different thresholds. As a result, Alice's transaction might be accepted by some validators and rejected by others. She can't predict whether she'll get through. The network becomes indecisive about which transactions clear the bar, and as thousands of users guess, resubmit, and spam fees, the system collapses under the weight of its indecision.
Dynamic Base Fee (à la Ethereum)
In EIP-1559, Ethereum introduced a dynamic "base fee" that adjusts based on demand. It works by measuring how full the last block is and adjusting fees accordingly: if blocks are full, the base fee increases; if blocks are empty, the base fee decreases. The users pay the base fee plus a tip.
This works well in Ethereum, because it has blocks and consensus on those blocks. The network can agree on how full the last block was (consensus), and this shared context drives the next base fee.
But pod doesn't have blocks or consensus. So while EIP-1559 implements adaptive pricing in Ethereum, it's not directly applicable here. It turns out that pricing under pressure is a coordination problem. And consensus has a way of creeping back in when coordination gets hard.
So, what now?
The Correct Way to Set Fees
Fees aren't just about paying for execution. When things get busy, fees determine how the system prioritizes which transactions get in.
A good fee mechanism ensures that: (i) clients are given a clear, fair price that guarantees inclusion and (ii) validators are offered a simple rule to decide which transactions make it in when the load is high.
Thus, the pricing mechanism needs to be responsive under load to reach a market-clearing price, where users pay a fair price and validators process transactions at capacity. It should also be predictable to ensure a good user experience and avoid denial-of-service, and simple enough that users can understand it.
pod's Answer: The Heartbeat Construction
The idea behind pod's solution is simple: use quorums of fee estimates from validators over intervals of time.
Instead of blocks, pod introduces epochs: short, fixed-length intervals, such as one minute long. Each epoch gives validators a shared rhythm, a decentralized metronome.
At the start of each epoch, validators broadcast a message, known as a heartbeat, to the network. Each heartbeat includes the validator's estimate of the base fee, based on the number of transactions they processed in the previous epoch.
Similar to the Ethereum base fees, if a validator processes more than the target load, it increases the base fee based on a deterministic formula; conversely, if it processes less, the fee decreases. These heartbeat messages create a picture of current demand, without any validator needing to agree on a single global value.
However, here's the clever part: users and validators don't rely on a single heartbeat; instead, they look at a quorum.
How Alice Picks Her Fee
At the start of an epoch, Alice waits a short time (just enough for messages to get around—call it 2Δ). Then she collects all the heartbeat messages she sees for the current epoch.
She sorts them, picks the 2f + 1 highest base fee estimates (where f is the max number of faulty validators), and takes the median. That's the base fee she uses for all transactions in this epoch.
No bidding wars. No retry. Just one predictable number.
How Validators Decide What to Accept
Each validator does the same, but in reverse. They also collect heartbeat messages. However, instead of selecting the highest 2f + 1, they choose the lowest 2f + 1. Again, they take the median, and that becomes their local threshold. If Alice's transaction fee is at or above this number, they accept it.
This asymmetry is intentional: Alice uses the high end to ensure her fee clears every honest validator's threshold. Validators use the low end to ensure they don't reject honest users unnecessarily. This ensures that even if validators and users see a different set of heartbeat messages, they have a valid clearing price.
But let's play it out to be sure. Say there are four validators, and one is malicious.
- Sharing the local estimates. The honest ones report base fees of $99, $100, and $101. The malicious validator could have said anything or nothing at all. For the sake of the example, the malicious validator sends nothing to the first validator, $0 to the second one and ∞ to both the third one and the user.
- Alice’s gas price. Alice collects the three (2f +1) highest heartbeats [$100, $101, ∞] and computes the median value $101 as the price for the current epoch. Note here that if the malicious guy would have sent $0 to Alice, then she would have computed the gas price to be $100. We will see in the next step that any value greater or equal to $100 would have been valid.
- Validators gas price. The validators each take the three lowest values and compute their medians - $99, $100, and $99, respectively. Regardless of the estimate sent by the malicious guy, the gas price for the validators are lower than $100 and greater than $99.
- Alice uses $101 as the gas price for her transaction, which is greater than the local estimates of all the honest validators; therefore, she receives sufficient attestations to confirm her transaction.
What it Achieves
With the heartbeat construction, pod achieves what traditional systems rely on consensus to do:
- Honest users' transactions are accepted by all honest validators.
- Fees are predictable – users don't need to guess or overpay; they just include the base fee.
- The system stays responsive under load, balancing the throughput and price.
- The fee mechanism protects the system from denial-of-service attacks; validators follow simple rules to filter out low-paying transactions.
- Users pay a fair price; one that comes from, or lies between, honest validator estimates.
And it does all of this without consensus. It's the kind of design that makes consensusless systems not just fast, but usable.
TL;DR
Consensusless systems like pod can execute transactions efficiently, but setting fair transaction fees without coordination is challenging. Traditional approaches rely on global agreement to reflect load and adjust fees. pod's heartbeat construction solves this by (i) structuring time into epochs, (ii) sharing local load estimates, and (iii) letting users and validators coordinate on fees via quorums. The result is a transaction pricing mechanism that's fair and predictable, without compromising the performance gains that come from avoiding consensus in the first place.
