Liquid payments (streams)
A liquid payment streams money from a payer to a recipient over a chosen number of minutes. The whole amount is locked at the start and vests evenly as time passes, so the recipient can see that the money is there, and the payer pays only for the time that has actually gone by. Liquid payments suit pay-per-minute services, pay for a shift, or rentals.
Starting a stream
A LiquidPayment transaction (type 6) names a recipient, an amount and complete_minutes, the length of the stream in minutes. It can stream a token instead of ZBC by naming the token's id. When a block includes it:
- the amount leaves the payer's balance at once and is locked;
- it vests evenly over the stated minutes;
- when the time is up, the chain pays the whole amount to the recipient by itself, with no further transaction.
Completion is checked block by block against the previous block's timestamp, so a producer cannot stamp a block ahead of time to bring the final payout forward (see expiry and timestamps).
Stopping a stream
Either side can end a stream early with a LiquidPaymentStop (type 262). The chain then splits the amount by the time that passed between the two transactions' timestamps: the recipient receives the part that has vested, and the rest returns to the payer. The recipient's part is rounded up to the next atomic unit, so rounding never shorts the recipient.
Neither side can take more than the clock allows. The payer cannot take back what has already vested, and the recipient cannot take what has not.
With other features
- Split policies. A stream's payouts are incoming credits, so they pass through the recipient's split policy (see split and transact policies).
- Transact policies. A transact policy is checked only against the recipient named in the LiquidPayment itself. The stream's payouts still reach a recipient that opts out of payments later.
- Token streams. If a streamed token expires, its ZBC backing is shared among the holders, and the units in a stream count for each side by how much has vested (see token upkeep (persistence)).
A stream pays once, continuously, over its minutes. For a series of separate payments, such as a monthly allowance, use scheduled transfers; for one payment at a future block height or after an event, use triggers and attestations.