Give each payment its own Row
A pool transaction pays at most one public account. So each recipient gets a Payout Row, and each Payout gets its own withdrawal and its own date. The first Row is always the Initial Deposit, which the depositor signs when they confirm the Plan.
Fix an underfunded Plan
Each Deposit funds the Payouts after it, up to the next Deposit. A Plan is underfunded when the Deposits before a Payout do not bring enough to pay it. The service refuses to confirm an underfunded Plan. The depositor does not have to bring every token up front. Add an intermediate Deposit before the Payout that is short, and the depositor signs it when it comes due.
Carry value forward with Remainders
A Step can create only a few notes. When a Deposit funds more Payouts than one Step can hold, the value that is not paid out yet becomes a Remainder. The next Step spends the Remainder and creates the next payout notes. A Remainder is locked to the notes the next Step creates. The service cannot spend it any other way. See Note accumulators.
Pay fees from Free tokens
Every Step reserves Free tokens. The fee is quoted only when the Step runs, so the Plan does not record a fee. The service pays the fee from the Step’s Free tokens and keeps what the fee did not use. When a quote is above a Step’s Free tokens, that Step does not run. The client raises Free tokens to the current quotes before the depositor signs a Deposit, and adds the increase to the Deposit that funds the Step.
Follow a Plan’s progress
A Step is executed once the pool shows that its notes were spent and the new notes were created. The service runs Steps in order, and each interval starts when the previous Step is executed. A Step is blocked when one of the notes it needs was spent by a different transaction. A blocked Plan cannot continue.Related
- Edit a Plan in your app — compose a draft, add a recipient or a Deposit, and check funding.
- Run Plans on your service — save a Plan, count executed Steps, and submit the next Step.