TX1 is the payment โ one transaction, one step. The moment it enters the mempool, the sender's funds belong permanently to the recipient, at zero fee. TX2 is how the recipient later spends what's theirs, also at zero fee. Two transaction types, one hard boundary between them: 1 MEM.
The standard transaction is fee-bearing, immediately spendable, general-purpose โ for transfers of any size. TX1/TX2 is built for a different job: zero-fee, irrevocable payments bounded at 1 MEM. Both coexist under the same consensus.
Fee-bearing, spendable as soon as it confirms. The right tool for transfers with no cap and no lock.
TX1 is the payment โ final the instant it reaches the network. TX2 is the recipient spending their own unlocked balance, not a second half of the payment.
TX1 carries no fee. TX2 carries no fee. A recipient can consolidate many unlocked outputs into one TX2 and split the total across up to three addresses, at no cost.
The 3-day lock doesn't build certainty over time โ it transfers certainty forward from the moment TX1 is broadcast. The payment is already final; the lock is a property of the output, not of the payment.
Once broadcast, the sender permanently loses control. There's no expiry on the recipient's claim โ if TX2 is never broadcast, the funds stay locked to the recipient indefinitely. A refund requires the recipient to voluntarily send it back.
TX1/TX2 is bounded at 1 MEM per payment by consensus. Anything larger uses a standard fee-bearing transaction โ settled immediately, no lock period.
TX1 is the only way to create a CLTV+P2PKH output. TX2 is the only way to spend one โ and it always produces plain P2PKH outputs. Locked outputs can't chain or nest; the payment graph stays flat.
An ordinary spendable output โ the sender's funds before any payment is made.
Locked to the recipient. Visible and attributed to them immediately โ spendable only once the lock expires.
Ordinary spendable output again โ no restrictions, usable like any other balance.
Spends a single P2PKH output, locks the payment amount to the recipient, with an optional change output back to the sender. Final โ and the sender's control ends โ the moment it enters the mempool.
The locked output sits on-chain for ~3 days (432 blocks), visible and already attributed to the recipient, but not yet spendable. The payment is settled; the lock is just the gap before availability.
Once unlocked, the recipient broadcasts TX2 โ consolidating up to 1,000 unlocked outputs from any number of past TX1s, split across up to three P2PKH addresses, at zero fee.
Enforced by every node on every block, unconditionally. A block that violates one is rejected by the entire network regardless of who mined it โ the structural shape of TX1/TX2, the lock period, the value ceiling, and the output floor all live here.
Enforced at mempool admission, defending against abuse within the bounds consensus already sets. Operators tighten or relax them as conditions change โ the consensus output floor is the hard backstop beneath any policy value.
R0, R1, R2, R3, R3b, R5 are consensus ยท R4, R5b are policy
TX2 spends unlocked CLTV+P2PKH outputs exclusively. It cannot spend standard P2PKH outputs, and CLTV and P2PKH inputs can never mix in one transaction.
R6, R7, R10, R10b are consensus ยท R7b, R8, R9 are policy
MIN_OUTPUT_VALUE (consensus) โ every output of every transaction must carry at least 10 kbit, without exception, checked before TX1/TX2 classification even occurs.
TX1 and TX2 carry no fee โ miner income from these transactions comes entirely from the block reward, permanently fixed at 7 MEM after block 472,500.
Yesmem runs without displacing normal computer use. Miners are ordinary users โ the same people making and receiving these payments โ so they include zero-fee transactions because the transactions are their own.
Each mining thread needs a dedicated, non-shareable 8 GiB โ large pools are structurally unviable. Miners are distributed individuals, not a coordinated few who could choose to exclude zero-fee transactions.
The payment is final. The sender's funds are locked into a CLTV output only the recipient can spend once the lock expires. Any block that tries to spend it early violates OP_CLTV and is rejected by the entire network. The payment timeline moves only forward โ a reorg deep enough to displace a confirmed TX1 is highly unlikely, and even then TX1 simply re-enters the mempool and reconfirms, since the P2PKH output it spent remains unspent on the new chain.
The lock period (R2) and the value ceiling (R5) are checked by every node on every block โ a TX1 with an invalid locktime or an out-of-range value is rejected outright, and no miner can bypass that.
R3, R7, and R10b together guarantee CLTV+P2PKH outputs are created only by TX1 and spent only by TX2, and that TX2 outputs are always plain P2PKH. Locked outputs never chain or nest โ the payment graph stays flat, entirely by consensus.
No. Setting nLockTime > 0 on an ordinary P2PKH transaction isn't permitted โ it gets classified as TX2 and rejected at mempool entry by R7. Standard transactions and TX1/TX2 are structurally separate paths that never combine.