Lock tokens once. They accrue to the recipient every second until they are gone.

1. 01

   created

   The sender locks the full deposit. Start, end, and cliff are fixed. So are three capability flags — cancellable, pausable, transferable — which can never change afterwards, so a recipient can verify what the sender is able to do before accepting.

2. 02

   cliff

   The cliff gates the payout; it does not delay accrual. At cliff_time the recipient becomes entitled to everything accrued since start_time, not merely what accrues after. Pass cliff_time == start_time for no cliff.

3. 03

   accruing

   Value accrues against ledger time and is computed on read. Nothing runs in the background — Stellar has no scheduler. The recipient calls withdraw and the contract works out what they have earned at that instant.

4. 04

   matured

   At end_time the whole deposit is vested. Accrual stops there and is clamped; no amount of elapsed time produces one stroop more than was deposited.

5. 05

   settled

   Either the recipient draws the balance to zero and the stream is depleted, or the sender cancels and the unvested remainder is refunded exactly. A cancelled stream stays cancelled even once drained, so the two endings stay distinguishable.

Contributor payroll

Salary that accrues per second instead of arriving monthly. A contributor draws whenever they like; a treasury commits once and stops running a payment schedule.

Token vesting with a cliff

A one-year cliff followed by linear vesting is the default grant shape. Set cliff_time and the contract enforces it; nothing releases before the date.

Milestone and grant disbursement

Fund a grant up front and let it stream. Pause when a milestone slips and the schedule stretches by exactly the paused duration rather than shortchanging anyone.

Subscription billing

A payer streams to a service continuously and stops by cancelling. The provider is paid for exactly the time consumed, to the stroop.

DAO compensation

Wrap create_stream in a policy contract so a smart account caps what can be committed per period. The core contract has no admin key to negotiate with.

The contract is deployed and callable now. There is no SDK yet, so this uses the Stellar CLI directly.

# Read a live stream from the deployed testnet contract.
# Requires stellar-cli 27.x — the CLI major must match the network protocol.

stellar contract invoke \
  --id CBCGTSCJXBMPPPE4BPDIPYZXPE2J5TQEKD2KCS7VQF533NKKEYGUTHXW \
  --source-account <your-key> \
  --network testnet \
  --send=no \
  -- get_stream --stream_id 0

# Returns the full Stream struct: deposited, withdrawn, start_time, end_time,
# cliff_time, the three capability flags, paused_at, paused_total, status.
#
# Derive vested, withdrawable and refundable from that single response rather
# than making three calls — a public RPC URL is an endpoint, not a node, and
# separate calls can land on different ledgers.

Contract CBCGTSCJXBMPPPE4BPDIPYZXPE2J5TQEKD2KCS7VQF533NKKEYGUTHXW on stellar.expert. Full function surface in theABI reference.

This is a summary. The full file is reproduced verbatim on theknown limitations page, and is maintained as KNOWN-LIMITATIONS.mdin the contracts repository.