The block-lattice: one chain per account
A conventional blockchain is a single shared chain: every transaction must be included in a block that everyone agrees on, in order. That shared sequence is what creates competition for block space, and competition for block space is what makes a fee market.
A block-lattice restructures this. Each account keeps its own chain, and only its owner can add to it. A transfer is recorded as two separate operations, a send on the sender's chain and a receive on the recipient's, rather than as one entry in a global sequence. Because accounts do not contend for the same space, the mechanism that produces fees is absent by construction rather than by subsidy.
The asynchronous consequence
Splitting a transfer into two operations makes it asynchronous. A send can be recorded and settled on the sender's chain while the corresponding receive sits unclaimed until the recipient acts. Funds are committed and irreversible from the sender's side, and not yet reflected in the recipient's balance.
This is coherent and it does surprise people arriving from a single-chain model, where a transaction is one atomic event. It also means wallet software has to handle pending receivables explicitly, and a balance shown may or may not include unclaimed sends depending on the implementation.
Why double-spends still need resolvingOnly the account owner can write to their own chain, so the remaining attack is publishing two conflicting blocks at the same position. That is what the consensus layer exists to resolve, and it is the reason a feeless ledger still needs one: the fee was never what prevented double-spending.
Where the spam cost moved
With no fee, the natural defense against flooding the network is to make each transaction cost something other than money. The usual answer is a small proof-of-work computation attached to every block, expensive enough to make mass generation impractical and cheap enough to be invisible for ordinary use.
That is the trade being made. The cost of processing has moved from the sender's wallet to the sender's processor, and from a market price to a fixed technical requirement. Its weakness is that a fixed difficulty is a fixed barrier: an adversary with substantial compute can pay it at scale, which is why such systems typically add dynamic difficulty or prioritization by account balance once flooding is attempted in earnest.
Reading a design rather than a token
The reason this sits in an execution section is that it is a settlement design, and the questions to ask are settlement questions. What has to be true for a transfer to be final? Who can write to the record? What happens when two conflicting instructions appear? What stops the record being flooded? Every ledger answers those four, and the answers are what distinguish them.
None of this concerns what any token is worth. A design can be elegant and the asset built on it can fail, and an unremarkable design can carry an enormously valuable one. Keeping those two assessments separate is the same discipline the equity pages apply when they describe a mechanism without recommending the security it applies to.